Wtyczka do finanse w LMS
Witam,
implementuję rozszerzenie wtyczki BillTech służącej do rozliczania opłat za internet z zewnętrznym systemem płatności. Wtyczka ma za zadanie przetworzyć dane z faktury w momencie ich tworzenia oraz na ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych. Z przeprowadzonej analizy dowiedziałem się, że opłaty są wystawiane przez frontend w sekcji Finanse (nowa faktura/nota odsetkowa/...) oraz przez skrypt lms-payments.php na podstawie subskrypcji.
Jako kandydatów na płatności rozpatrywałem rekordy z tabel cash, invoicecontents lub liabilities ale używając skryptu genfake w dwóch ostatnich nic się nie znajduje pomimo, że faktury się wygenerowały, więc skupiam się na tabeli cash.
W związku z powyższym zastanawiam się, w których miejscach w kodzie mógłbym się wpiąć, tak żeby złapać wystawianie wszystkich płatności, które pojawiają się w userpanelu i są do opłacenia przez użytkowników? Czy istnieje odpowiedni hook do takiego zastosowania czy będzie trzeba go stworzyć? Dla lms-payments.php mamy "payments_before_assignment_loop", który wydaje się być stworzony właśnie w tym celu ale dane nie są jeszcze dodane do bazy danych, więc to może generować problemy, gdy skrypt się wywali. Z drugiej strony zapisywanie w bazie faktur dodawanych przez frontend dzieje się w wielu miejscach i nie widzę jednego zbiorczego miejsca. Dotychczas szukałem najlepszego miejsca w kodzie poprzez wyszukiwania zapytań SQL na tabeli cash.
Pozdrawiam, Paweł
W dniu 13.07.2020 12:46, Paweł Sienkiewicz napisał(a):
Witam,
Witam,
implementuję rozszerzenie wtyczki BillTech służącej do rozliczania opłat za internet z zewnętrznym systemem płatności. Wtyczka ma za zadanie przetworzyć dane z faktury w momencie ich tworzenia oraz na ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych. Z przeprowadzonej analizy dowiedziałem się, że opłaty są wystawiane przez frontend w sekcji Finanse (nowa faktura/nota odsetkowa/...) oraz przez skrypt lms-payments.php na podstawie subskrypcji.
Jako kandydatów na płatności rozpatrywałem rekordy z tabel cash, invoicecontents lub liabilities ale używając skryptu genfake w dwóch ostatnich nic się nie znajduje pomimo, że faktury się wygenerowały, więc skupiam się na tabeli cash.
'cash' - operacje finansowe, 'invoicecontents' - pozycje faktur - mają pewne informacje, których nie posiadają powiązane z nimi rekordy w 'cash' np. liczba sztuk.
W związku z powyższym zastanawiam się, w których miejscach w kodzie mógłbym się wpiąć, tak żeby złapać wystawianie wszystkich płatności, które pojawiają się w userpanelu i są do opłacenia przez użytkowników? Czy istnieje odpowiedni hook do takiego zastosowania czy będzie trzeba go stworzyć? Dla lms-payments.php mamy "payments_before_assignment_loop", który wydaje
Ten hook służy raczej do tego, żeby móc dodać z zewnątrz nowe subskrypcje, które potem uwzględni główna pętla skryptu i wygeneruje na ich podstawie obciążenia.
się być stworzony właśnie w tym celu ale dane nie są jeszcze dodane do bazy danych, więc to może generować problemy, gdy skrypt się wywali. Z drugiej strony zapisywanie w bazie faktur dodawanych przez frontend dzieje się w wielu miejscach i nie widzę jednego zbiorczego miejsca. Dotychczas szukałem najlepszego miejsca w kodzie poprzez wyszukiwania zapytań SQL na tabeli cash.
Co chcesz dokładnie uzyskać? Ze strzępków informacji wyobraziłem sobie sytuację w której chcesz przechwytywać w jakimś celu wszystkie generowane obciążenia (?) i coś z nimi robić? Co za dane określone frazą "ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych".
Pozdrawiam, Paweł
Celem jest przechwytywanie tworzenia wszystkich sensownych obciążeń/faktur i generowanie dla nich linków, które będą zapisywane w bazie danych. Dzięki temu za każdym razem przy:
- tworzeniu płatności będzie generowany nowy link - próbie dokonania płatności przez użytkownika link będzie pobierany z bazy
Istotne jest żeby generowanie linku działo się podczas tworzenia obciążeń/faktur. Z tego powodu rozważam hook w lms-payments.php oraz wszędzie gdzie tworzone są faktury. Zastanawia mnie gdzie jest odpowiednie miejsce do takiego wpięcia? Do wygenerowania linka potrzebne są: numer konta bankowego, kwota płatności oraz jej tytuł.
śr., 15 lip 2020 o 16:48 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 13.07.2020 12:46, Paweł Sienkiewicz napisał(a):
Witam,
Witam,
implementuję rozszerzenie wtyczki BillTech służącej do rozliczania opłat za internet z zewnętrznym systemem płatności. Wtyczka ma za zadanie przetworzyć dane z faktury w momencie ich tworzenia oraz na ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych. Z przeprowadzonej analizy dowiedziałem się, że opłaty są wystawiane przez frontend w sekcji Finanse (nowa faktura/nota odsetkowa/...) oraz przez skrypt lms-payments.php na podstawie subskrypcji.
Jako kandydatów na płatności rozpatrywałem rekordy z tabel cash, invoicecontents lub liabilities ale używając skryptu genfake w dwóch ostatnich nic się nie znajduje pomimo, że faktury się wygenerowały, więc skupiam się na tabeli cash.
'cash' - operacje finansowe, 'invoicecontents' - pozycje faktur - mają pewne informacje, których nie posiadają powiązane z nimi rekordy w 'cash' np. liczba sztuk.
W związku z powyższym zastanawiam się, w których miejscach w kodzie mógłbym się wpiąć, tak żeby złapać wystawianie wszystkich płatności, które pojawiają się w userpanelu i są do opłacenia przez użytkowników? Czy istnieje odpowiedni hook do takiego zastosowania czy będzie trzeba go stworzyć? Dla lms-payments.php mamy "payments_before_assignment_loop", który wydaje
Ten hook służy raczej do tego, żeby móc dodać z zewnątrz nowe subskrypcje, które potem uwzględni główna pętla skryptu i wygeneruje na ich podstawie obciążenia.
się być stworzony właśnie w tym celu ale dane nie są jeszcze dodane do bazy danych, więc to może generować problemy, gdy skrypt się wywali. Z drugiej strony zapisywanie w bazie faktur dodawanych przez frontend dzieje się w wielu miejscach i nie widzę jednego zbiorczego miejsca. Dotychczas szukałem najlepszego miejsca w kodzie poprzez wyszukiwania zapytań SQL na tabeli cash.
Co chcesz dokładnie uzyskać? Ze strzępków informacji wyobraziłem sobie sytuację w której chcesz przechwytywać w jakimś celu wszystkie generowane obciążenia (?) i coś z nimi robić? Co za dane określone frazą "ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych".
Pozdrawiam, Paweł
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
W dniu 15.07.2020 19:52, Paweł Sienkiewicz napisał(a):
Celem jest przechwytywanie tworzenia wszystkich sensownych obciążeń/faktur i generowanie dla nich linków, które będą zapisywane w bazie danych. Dzięki temu za każdym razem przy:
- tworzeniu płatności będzie generowany nowy link
- próbie dokonania płatności przez użytkownika link będzie
pobierany z bazy
Istotne jest żeby generowanie linku działo się podczas tworzenia obciążeń/faktur. Z tego powodu rozważam hook w lms-payments.php oraz wszędzie gdzie tworzone są faktury. Zastanawia mnie gdzie jest odpowiednie miejsce do takiego wpięcia? Do wygenerowania linka potrzebne są: numer konta bankowego, kwota płatności oraz jej tytuł.
Witam,
dlaczego takiego linku dla płatności nie można generować na bieżąco, gdy klient chce coś opłacić (dopiero wtedy)?
śr., 15 lip 2020 o 16:48 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 13.07.2020 12:46, Paweł Sienkiewicz napisał(a):
Witam,
Witam,
implementuję rozszerzenie wtyczki BillTech służącej do
rozliczania
opłat za internet z zewnętrznym systemem płatności. Wtyczka ma
za
zadanie przetworzyć dane z faktury w momencie ich tworzenia oraz
na
ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych.
Z
przeprowadzonej analizy dowiedziałem się, że opłaty są
wystawiane
przez frontend w sekcji Finanse (nowa faktura/nota odsetkowa/...)
oraz
przez skrypt lms-payments.php na podstawie subskrypcji.
Jako kandydatów na płatności rozpatrywałem rekordy z tabel
cash,
invoicecontents lub liabilities ale używając skryptu genfake w dwóch ostatnich nic się nie znajduje pomimo, że faktury się wygenerowały, więc skupiam się na tabeli cash.
'cash' - operacje finansowe, 'invoicecontents' - pozycje faktur - mają pewne informacje, których nie posiadają powiązane z nimi rekordy w 'cash' np. liczba sztuk.
W związku z powyższym zastanawiam się, w których miejscach w kodzie mógłbym się wpiąć, tak żeby złapać wystawianie wszystkich płatności, które pojawiają się w userpanelu i są
do
opłacenia przez użytkowników? Czy istnieje odpowiedni hook do takiego zastosowania czy będzie trzeba go stworzyć? Dla lms-payments.php mamy "payments_before_assignment_loop", który
wydaje
Ten hook służy raczej do tego, żeby móc dodać z zewnątrz nowe subskrypcje, które potem uwzględni główna pętla skryptu i wygeneruje na ich podstawie obciążenia.
się być stworzony właśnie w tym celu ale dane nie są jeszcze dodane do bazy danych, więc to może generować problemy, gdy
skrypt
się wywali. Z drugiej strony zapisywanie w bazie faktur
dodawanych
przez frontend dzieje się w wielu miejscach i nie widzę jednego zbiorczego miejsca. Dotychczas szukałem najlepszego miejsca w
kodzie
poprzez wyszukiwania zapytań SQL na tabeli cash.
Co chcesz dokładnie uzyskać? Ze strzępków informacji wyobraziłem sobie sytuację w której chcesz przechwytywać w jakimś celu wszystkie generowane obciążenia (?) i coś z nimi robić? Co za dane określone frazą "ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych".
Pozdrawiam, Paweł
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego mechanizmu aby zapewnić lepszą synchronizację danych pomiędzy systemami. Przy obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie linków przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w trakcie tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila z fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i najlepiej jakby były one generowane w jednym miejscu. Ponadto jeśli linki będą wygenerowane tylko raz, po wystawieniu faktury, to ładowanie listy faktur w userpanelu będzie szybsze.
czw., 16 lip 2020 o 10:03 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 15.07.2020 19:52, Paweł Sienkiewicz napisał(a):
Celem jest przechwytywanie tworzenia wszystkich sensownych obciążeń/faktur i generowanie dla nich linków, które będą zapisywane w bazie danych. Dzięki temu za każdym razem przy:
* tworzeniu płatności będzie generowany nowy link * próbie dokonania płatności przez użytkownika link będziepobierany z bazy
Istotne jest żeby generowanie linku działo się podczas tworzenia obciążeń/faktur. Z tego powodu rozważam hook w lms-payments.php oraz wszędzie gdzie tworzone są faktury. Zastanawia mnie gdzie jest odpowiednie miejsce do takiego wpięcia? Do wygenerowania linka potrzebne są: numer konta bankowego, kwota płatności oraz jej tytuł.
Witam,
dlaczego takiego linku dla płatności nie można generować na bieżąco, gdy klient chce coś opłacić (dopiero wtedy)?
śr., 15 lip 2020 o 16:48 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 13.07.2020 12:46, Paweł Sienkiewicz napisał(a):
Witam,
Witam,
implementuję rozszerzenie wtyczki BillTech służącej do
rozliczania
opłat za internet z zewnętrznym systemem płatności. Wtyczka ma
za
zadanie przetworzyć dane z faktury w momencie ich tworzenia oraz
na
ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych.
Z
przeprowadzonej analizy dowiedziałem się, że opłaty są
wystawiane
przez frontend w sekcji Finanse (nowa faktura/nota odsetkowa/...)
oraz
przez skrypt lms-payments.php na podstawie subskrypcji.
Jako kandydatów na płatności rozpatrywałem rekordy z tabel
cash,
invoicecontents lub liabilities ale używając skryptu genfake w dwóch ostatnich nic się nie znajduje pomimo, że faktury się wygenerowały, więc skupiam się na tabeli cash.
'cash' - operacje finansowe, 'invoicecontents' - pozycje faktur - mają pewne informacje, których nie posiadają powiązane z nimi rekordy w 'cash' np. liczba sztuk.
W związku z powyższym zastanawiam się, w których miejscach w kodzie mógłbym się wpiąć, tak żeby złapać wystawianie wszystkich płatności, które pojawiają się w userpanelu i są
do
opłacenia przez użytkowników? Czy istnieje odpowiedni hook do takiego zastosowania czy będzie trzeba go stworzyć? Dla lms-payments.php mamy "payments_before_assignment_loop", który
wydaje
Ten hook służy raczej do tego, żeby móc dodać z zewnątrz nowe subskrypcje, które potem uwzględni główna pętla skryptu i wygeneruje na ich podstawie obciążenia.
się być stworzony właśnie w tym celu ale dane nie są jeszcze dodane do bazy danych, więc to może generować problemy, gdy
skrypt
się wywali. Z drugiej strony zapisywanie w bazie faktur
dodawanych
przez frontend dzieje się w wielu miejscach i nie widzę jednego zbiorczego miejsca. Dotychczas szukałem najlepszego miejsca w
kodzie
poprzez wyszukiwania zapytań SQL na tabeli cash.
Co chcesz dokładnie uzyskać? Ze strzępków informacji wyobraziłem sobie sytuację w której chcesz przechwytywać w jakimś celu wszystkie generowane obciążenia (?) i coś z nimi robić? Co za dane określone frazą "ich podstawie dokonać zapisu w specjalnej tabeli w bazie danych".
Pozdrawiam, Paweł
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a):
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego mechanizmu aby zapewnić lepszą synchronizację danych pomiędzy systemami. Przy obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie linków przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w trakcie tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila z fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i najlepiej jakby były one generowane w jednym miejscu. Ponadto jeśli linki będą wygenerowane tylko raz, po wystawieniu faktury, to ładowanie listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się pojawiać natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi się, że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma (oczywiście mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć jakieś rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania samego dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z: 1. Dokumentem (rekord w 'documents'). 2. Pozycją dokumentu (rekord w 'invoicecontents'). 3. Operacją finansową (rekord w 'cash'). ?
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej. Z jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu faktur i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców internetu?
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a):
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego mechanizmu aby zapewnić lepszą synchronizację danych pomiędzy systemami. Przy obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie linków przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w trakcie tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila z fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i najlepiej jakby były one generowane w jednym miejscu. Ponadto jeśli linki będą wygenerowane tylko raz, po wystawieniu faktury, to ładowanie listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się pojawiać natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi się, że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma (oczywiście mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć jakieś rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania samego dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej. Z jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu faktur i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć: 1. Faktury. 2. Faktury korygujące. 3. Faktury pro forma. 4. Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a):
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego
mechanizmu
aby zapewnić lepszą synchronizację danych pomiędzy systemami.
Przy
obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie
linków
przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w
trakcie
tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila z fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i najlepiej jakby były one generowane w jednym miejscu. Ponadto jeśli linki będą wygenerowane tylko raz, po wystawieniu faktury, to
ładowanie
listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się pojawiać natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi się, że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma (oczywiście mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć jakieś
rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania samego dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na podstawie rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała ale to wydaje się niespójne. W kwestii zapisywania we własnej tabeli, to jest to dobry pomysł.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej. Z jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu faktur i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a):
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego
mechanizmu
aby zapewnić lepszą synchronizację danych pomiędzy systemami.
Przy
obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie
linków
przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w
trakcie
tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila z fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i najlepiej jakby były one generowane w jednym miejscu. Ponadto jeśli linki będą wygenerowane tylko raz, po wystawieniu faktury, to
ładowanie
listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się pojawiać natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi się, że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma (oczywiście mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć jakieś
rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania samego dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
W dniu 17.07.2020 12:29, Paweł Sienkiewicz napisał(a):
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na podstawie rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała ale to wydaje się niespójne. W kwestii zapisywania we własnej tabeli, to jest to dobry pomysł.
Jeśli linki do płatności za dokumenty to tabela 'documents'. Tabela 'cash' nie będzie wówczas szczególnie istotna.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej.
Z
jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu
faktur
i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców
internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a):
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego
mechanizmu
aby zapewnić lepszą synchronizację danych pomiędzy
systemami.
Przy
obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie
linków
przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w
trakcie
tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila
z
fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i
najlepiej
jakby były one generowane w jednym miejscu. Ponadto jeśli
linki
będą wygenerowane tylko raz, po wystawieniu faktury, to
ładowanie
listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się
pojawiać
natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi
się,
że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma
(oczywiście
mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć
jakieś
rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania
samego
dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
Właśnie założenie czy linki do płatności to tabela 'documents' chcemy jeszcze zweryfikować. Widać oczywistą przewagę documents ale takie podejście uniemożliwi wygodne płacenie za opłaty subskrypcyjne, które są przechowywane w tabeli 'cash'. Wtedy pozostanie tylko możliwość opłacenia ich poprzez saldo. Wyobrażam sobie jednak sytuację, że użytkownik będzie wolał zapłacić na przykład zaległą opłatę subskrypcyjną, niż obie naraz przez saldo, na przykład z powodu braku środków.
Czemu dla opłat subskrypcyjnych nie mamy odpowiadających im faktur (rekordów w tabeli documents)? Czy są jeszcze jakieś inne zobowiązania użytkowników, które nie mają odpowiadających im rekordów w documents?
pt., 17 lip 2020 o 16:35 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 17.07.2020 12:29, Paweł Sienkiewicz napisał(a):
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na podstawie rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała ale to wydaje się niespójne. W kwestii zapisywania we własnej tabeli, to jest to dobry pomysł.
Jeśli linki do płatności za dokumenty to tabela 'documents'. Tabela 'cash' nie będzie wówczas szczególnie istotna.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej.
Z
jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu
faktur
i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców
internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a):
Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego
mechanizmu
aby zapewnić lepszą synchronizację danych pomiędzy
systemami.
Przy
obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład zdarzały się błędnie wygenerowane linki zgłaszane przez użytkowników, spowodowane edge case’ami w LMS. Generowanie
linków
przez API pozwoli wykrywać błędy na wcześniejszym etapie bez konieczności angażowania użytkowników. Obecnie jesteśmy w
trakcie
tworzenia nowego API, które dodatkowo będzie umożliwiało anulowanie linku po wykonaniu płatności innym źródłem. Teoretycznie moglibyśmy generować linki przed wysłaniem maila
z
fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. Ogólnie jest dużo sposobów dystrybucji tych linków i
najlepiej
jakby były one generowane w jednym miejscu. Ponadto jeśli
linki
będą wygenerowane tylko raz, po wystawieniu faktury, to
ładowanie
listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się
pojawiać
natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi
się,
że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma
(oczywiście
mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć
jakieś
rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania
samego
dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
Ale documents nie służy do trzymania faktur w ogóle.
-- Rafał Wójcik eDial Internet/AWB-NET ul. Lwowska 31/102, 56-400 Oleśnica 📧 rw@awbnet.pl 📞 71 606 6000 📠 71 606 6010
pon., 20 lip 2020 o 12:37 Paweł Sienkiewicz psienkiewicz@billtech.pl napisał(a):
Właśnie założenie czy linki do płatności to tabela 'documents' chcemy jeszcze zweryfikować. Widać oczywistą przewagę documents ale takie podejście uniemożliwi wygodne płacenie za opłaty subskrypcyjne, które są przechowywane w tabeli 'cash'. Wtedy pozostanie tylko możliwość opłacenia ich poprzez saldo. Wyobrażam sobie jednak sytuację, że użytkownik będzie wolał zapłacić na przykład zaległą opłatę subskrypcyjną, niż obie naraz przez saldo, na przykład z powodu braku środków.
Czemu dla opłat subskrypcyjnych nie mamy odpowiadających im faktur (rekordów w tabeli documents)? Czy są jeszcze jakieś inne zobowiązania użytkowników, które nie mają odpowiadających im rekordów w documents?
pt., 17 lip 2020 o 16:35 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 17.07.2020 12:29, Paweł Sienkiewicz napisał(a):
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na podstawie rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała ale to wydaje się niespójne. W kwestii zapisywania we własnej tabeli, to jest to dobry pomysł.
Jeśli linki do płatności za dokumenty to tabela 'documents'. Tabela 'cash' nie będzie wówczas szczególnie istotna.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej.
Z
jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu
faktur
i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców
internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a): > Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego mechanizmu > aby zapewnić lepszą synchronizację danych pomiędzy
systemami.
Przy > obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład > zdarzały się błędnie wygenerowane linki zgłaszane przez > użytkowników, spowodowane edge case’ami w LMS. Generowanie linków > przez API pozwoli wykrywać błędy na wcześniejszym etapie bez > konieczności angażowania użytkowników. Obecnie jesteśmy w trakcie > tworzenia nowego API, które dodatkowo będzie umożliwiało > anulowanie linku po wykonaniu płatności innym źródłem. > Teoretycznie moglibyśmy generować linki przed wysłaniem maila
z
> fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. > Ogólnie jest dużo sposobów dystrybucji tych linków i
najlepiej
> jakby były one generowane w jednym miejscu. Ponadto jeśli
linki
> będą wygenerowane tylko raz, po wystawieniu faktury, to ładowanie > listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się
pojawiać
natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi
się,
że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma
(oczywiście
mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć
jakieś
rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania
samego
dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
W dniu 20.07.2020 15:31, Rafał Wójcik napisał(a):
Ale documents nie służy do trzymania faktur w ogóle.
Służy m.in. do faktur, faktur pro forma i not obciążeniowych.
-- Rafał Wójcik eDial Internet/AWB-NET ul. Lwowska 31/102, 56-400 Oleśnica 📧 rw@awbnet.pl 📞 71 606 6000 📠 71 606 6010
pon., 20 lip 2020 o 12:37 Paweł Sienkiewicz psienkiewicz@billtech.pl napisał(a):
Właśnie założenie czy linki do płatności to tabela 'documents' chcemy jeszcze zweryfikować. Widać oczywistą przewagę documents ale takie podejście uniemożliwi wygodne płacenie za opłaty subskrypcyjne, które są przechowywane w tabeli 'cash'. Wtedy pozostanie tylko możliwość opłacenia ich poprzez saldo. Wyobrażam sobie jednak sytuację, że użytkownik będzie wolał zapłacić na przykład zaległą opłatę subskrypcyjną, niż obie naraz przez saldo, na przykład z powodu braku środków.
Czemu dla opłat subskrypcyjnych nie mamy odpowiadających im faktur (rekordów w tabeli documents)? Czy są jeszcze jakieś inne zobowiązania użytkowników, które nie mają odpowiadających im rekordów w documents?
pt., 17 lip 2020 o 16:35 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 17.07.2020 12:29, Paweł Sienkiewicz napisał(a):
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na podstawie rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała ale to wydaje się niespójne. W kwestii zapisywania we własnej tabeli, to jest to dobry pomysł.
Jeśli linki do płatności za dokumenty to tabela 'documents'. Tabela 'cash' nie będzie wówczas szczególnie istotna.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej.
Z
jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie przypisanych subskrypcji), które są tylko w tabeli cash oraz sumują się do salda, z drugiej documents wydają się być bliższe pojęciu
faktur
i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców
internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
> W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a): >> Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego > mechanizmu >> aby zapewnić lepszą synchronizację danych pomiędzy
systemami.
> Przy >> obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład >> zdarzały się błędnie wygenerowane linki zgłaszane przez >> użytkowników, spowodowane edge case’ami w LMS. Generowanie > linków >> przez API pozwoli wykrywać błędy na wcześniejszym etapie bez >> konieczności angażowania użytkowników. Obecnie jesteśmy w > trakcie >> tworzenia nowego API, które dodatkowo będzie umożliwiało >> anulowanie linku po wykonaniu płatności innym źródłem. >> Teoretycznie moglibyśmy generować linki przed wysłaniem maila
z
>> fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. >> Ogólnie jest dużo sposobów dystrybucji tych linków i
najlepiej
>> jakby były one generowane w jednym miejscu. Ponadto jeśli
linki
>> będą wygenerowane tylko raz, po wystawieniu faktury, to > ładowanie >> listy faktur w userpanelu będzie szybsze. > > Czyli link do płatności w Państwa systemie muszą się
pojawiać
> natychmiast czy > raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi
się,
> że mógłby > załatwić temat w miarę prosty skrypt backendowy, który > odpowiadałby za > wypełnianie > pól z linkiem tam gdzie jeszcze takiego linku nie ma
(oczywiście
> mógłby > brać > pod uwagę jakieś dodatkowe warunki). Staram się znaleźć
jakieś
> > rozwiązanie, > które nie będzie wymagało dużych zmian w kodzie generowania > obciążeń/faktur. > Pewnie, że fajnie byłoby mieć centralne miejsce dodawania
samego
> dokumentu > handlowego, a potem również centralne miejsce dodawania doń > pozycji. > Przy okazji pytanie: chodzi o powiązanie linków z: > 1. Dokumentem (rekord w 'documents'). > 2. Pozycją dokumentu (rekord w 'invoicecontents'). > 3. Operacją finansową (rekord w 'cash'). > ? > > -- > Pozdrawiam > Tomasz Chiliński, Chilan > opiekun projektu LMS - https://lms.org.pl > kierownik projektu LMS Plus / LMS+ - https://lms-plus.org > _______________________________________________ > lms mailing list > lms@lists.lms.org.pl > https://lists.lms.org.pl/mailman/listinfo/lms _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
Błąd myślowy po mojej stronie, bo chodziło mi o dokumenty na karcie klienta. ;) A tu mowa o tabelach.
-- Rafał Wójcik eDial Internet/AWB-NET ul. Lwowska 31/102, 56-400 Oleśnica 📧 rw@awbnet.pl 📞 71 606 6000 📠 71 606 6010
pon., 20 lip 2020 o 15:46 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 20.07.2020 15:31, Rafał Wójcik napisał(a):
Ale documents nie służy do trzymania faktur w ogóle.
Służy m.in. do faktur, faktur pro forma i not obciążeniowych.
-- Rafał Wójcik eDial Internet/AWB-NET ul. Lwowska 31/102, 56-400 Oleśnica 📧 rw@awbnet.pl 📞 71 606 6000 📠 71 606 6010
pon., 20 lip 2020 o 12:37 Paweł Sienkiewicz psienkiewicz@billtech.pl napisał(a):
Właśnie założenie czy linki do płatności to tabela 'documents' chcemy jeszcze zweryfikować. Widać oczywistą przewagę documents ale takie podejście uniemożliwi wygodne płacenie za opłaty subskrypcyjne, które są przechowywane w tabeli 'cash'. Wtedy pozostanie tylko możliwość opłacenia ich poprzez saldo. Wyobrażam sobie jednak sytuację, że użytkownik będzie wolał zapłacić na przykład zaległą opłatę subskrypcyjną, niż obie naraz przez saldo, na przykład z powodu braku środków.
Czemu dla opłat subskrypcyjnych nie mamy odpowiadających im faktur (rekordów w tabeli documents)? Czy są jeszcze jakieś inne zobowiązania użytkowników, które nie mają odpowiadających im rekordów w documents?
pt., 17 lip 2020 o 16:35 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 17.07.2020 12:29, Paweł Sienkiewicz napisał(a):
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na podstawie rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała ale to wydaje się niespójne. W kwestii zapisywania we własnej tabeli, to jest to dobry pomysł.
Jeśli linki do płatności za dokumenty to tabela 'documents'. Tabela 'cash' nie będzie wówczas szczególnie istotna.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a): > Dobre pytanie, wciąż się zastanawiamy się jak będzie lepiej. Z > jednej strony dobrze by było obsłużyć opłaty abonamentowe > (generowane za pomocą lms-payments.php na podstawie przypisanych > subskrypcji), które są tylko w tabeli cash oraz sumują się do > salda, z drugiej documents wydają się być bliższe pojęciu faktur > i mają unikalne tytuły. Co do invoicecontents, z tego co się > orientuje, to zdają się najmniej pasować do tej roli. Jak Pan > sądzi? Co byłoby najwygodniejsze z perspektywy dostawców internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej zrobić dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
> czw., 16 lip 2020 o 15:12 Tomasz Chiliński > tomasz.chilinski@chilan.com napisał(a): > >> W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a): >>> Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego >> mechanizmu >>> aby zapewnić lepszą synchronizację danych pomiędzy systemami. >> Przy >>> obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład >>> zdarzały się błędnie wygenerowane linki zgłaszane przez >>> użytkowników, spowodowane edge case’ami w LMS. Generowanie >> linków >>> przez API pozwoli wykrywać błędy na wcześniejszym etapie bez >>> konieczności angażowania użytkowników. Obecnie jesteśmy w >> trakcie >>> tworzenia nowego API, które dodatkowo będzie umożliwiało >>> anulowanie linku po wykonaniu płatności innym źródłem. >>> Teoretycznie moglibyśmy generować linki przed wysłaniem maila z >>> fakturą, ale nie wszyscy użytkownicy mają w LMS adres e-mail. >>> Ogólnie jest dużo sposobów dystrybucji tych linków i najlepiej >>> jakby były one generowane w jednym miejscu. Ponadto jeśli linki >>> będą wygenerowane tylko raz, po wystawieniu faktury, to >> ładowanie >>> listy faktur w userpanelu będzie szybsze. >> >> Czyli link do płatności w Państwa systemie muszą się pojawiać >> natychmiast czy >> raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi się, >> że mógłby >> załatwić temat w miarę prosty skrypt backendowy, który >> odpowiadałby za >> wypełnianie >> pól z linkiem tam gdzie jeszcze takiego linku nie ma (oczywiście >> mógłby >> brać >> pod uwagę jakieś dodatkowe warunki). Staram się znaleźć jakieś >> >> rozwiązanie, >> które nie będzie wymagało dużych zmian w kodzie generowania >> obciążeń/faktur. >> Pewnie, że fajnie byłoby mieć centralne miejsce dodawania samego >> dokumentu >> handlowego, a potem również centralne miejsce dodawania doń >> pozycji. >> Przy okazji pytanie: chodzi o powiązanie linków z: >> 1. Dokumentem (rekord w 'documents'). >> 2. Pozycją dokumentu (rekord w 'invoicecontents'). >> 3. Operacją finansową (rekord w 'cash'). >> ? >> >> -- >> Pozdrawiam >> Tomasz Chiliński, Chilan >> opiekun projektu LMS - https://lms.org.pl >> kierownik projektu LMS Plus / LMS+ - https://lms-plus.org >> _______________________________________________ >> lms mailing list >> lms@lists.lms.org.pl >> https://lists.lms.org.pl/mailman/listinfo/lms > _______________________________________________ > lms mailing list > lms@lists.lms.org.pl > https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
W dniu 20.07.2020 12:37, Paweł Sienkiewicz napisał(a):
Właśnie założenie czy linki do płatności to tabela 'documents' chcemy jeszcze zweryfikować. Widać oczywistą przewagę documents ale takie podejście uniemożliwi wygodne płacenie za opłaty subskrypcyjne, które są przechowywane w tabeli 'cash'. Wtedy pozostanie tylko możliwość opłacenia ich poprzez saldo. Wyobrażam sobie jednak sytuację, że użytkownik będzie wolał zapłacić na przykład zaległą opłatę subskrypcyjną, niż obie naraz przez saldo, na przykład z powodu braku środków.
Czemu dla opłat subskrypcyjnych nie mamy odpowiadających im faktur (rekordów w tabeli documents)? Czy są jeszcze jakieś inne zobowiązania użytkowników, które nie mają odpowiadających im rekordów w documents?
Moim zdaniem płatności BillTech w ogóle nie powinny być wiązane z dokumentami handlowymi czy operacjami finansowymi. Klient chce coś zapłacić - kilka - domyślnie wpisuje mu się kwota zaległości, ale ma możliwość jej zmiany. Tyle.
pt., 17 lip 2020 o 16:35 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 17.07.2020 12:29, Paweł Sienkiewicz napisał(a):
Nie przewidujemy częściowych płatności. Jeszcze mamy tylko wątpliwość w kwestii opłat okresowych wystawianych na
podstawie
rekordów w tarrifs za pomocą lms-payments.php. Chyba przy takim podejściu w ogóle nie bierzemy ich pod uwagę? Mamy też funkcjonalność opłacenia bilansu, która by je uwzględniała
ale
to wydaje się niespójne. W kwestii zapisywania we własnej
tabeli,
to jest to dobry pomysł.
Jeśli linki do płatności za dokumenty to tabela 'documents'. Tabela 'cash' nie będzie wówczas szczególnie istotna.
pt., 17 lip 2020 o 11:38 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 17:09, Paweł Sienkiewicz napisał(a):
Dobre pytanie, wciąż się zastanawiamy się jak będzie
lepiej.
Z
jednej strony dobrze by było obsłużyć opłaty abonamentowe (generowane za pomocą lms-payments.php na podstawie
przypisanych
subskrypcji), które są tylko w tabeli cash oraz sumują się
do
salda, z drugiej documents wydają się być bliższe pojęciu
faktur
i mają unikalne tytuły. Co do invoicecontents, z tego co się orientuje, to zdają się najmniej pasować do tej roli. Jak Pan sądzi? Co byłoby najwygodniejsze z perspektywy dostawców
internetu?
Tylko bez Panów ;-)
Czy przewidujecie częściową płatność za fakturę? Jeśli nie i kliknięcie będzie powodować opłacenie całej faktury to pod uwagę wystarczy brać tabelę 'documents'. Najlepiej
zrobić
dodatkową, własną tabelę, która będzie linkować się przez jakieś pole 'docid' do tabeli documents. Dzięki temu przy przyszłych aktualizacjach schematu i rekonstrukcjach widoków uniknie się problemów z customowymi polami.
Trzeba obsłużyć:
- Faktury.
- Faktury korygujące.
- Faktury pro forma.
- Noty obciążeniowe.
czw., 16 lip 2020 o 15:12 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
W dniu 16.07.2020 14:16, Paweł Sienkiewicz napisał(a): > Tak jest obecnie, natomiast potrzebujemy rozszerzenia tego mechanizmu > aby zapewnić lepszą synchronizację danych pomiędzy
systemami.
Przy > obecnym rozwiązaniu mieliśmy kilka problemów. Na przykład > zdarzały się błędnie wygenerowane linki zgłaszane przez > użytkowników, spowodowane edge case’ami w LMS. Generowanie linków > przez API pozwoli wykrywać błędy na wcześniejszym etapie
bez
> konieczności angażowania użytkowników. Obecnie jesteśmy w trakcie > tworzenia nowego API, które dodatkowo będzie umożliwiało > anulowanie linku po wykonaniu płatności innym źródłem. > Teoretycznie moglibyśmy generować linki przed wysłaniem
maila
z
> fakturą, ale nie wszyscy użytkownicy mają w LMS adres
e-mail.
> Ogólnie jest dużo sposobów dystrybucji tych linków i
najlepiej
> jakby były one generowane w jednym miejscu. Ponadto jeśli
linki
> będą wygenerowane tylko raz, po wystawieniu faktury, to ładowanie > listy faktur w userpanelu będzie szybsze.
Czyli link do płatności w Państwa systemie muszą się
pojawiać
natychmiast czy raczej mogą pojawiać się z pewnym opóźnieniem. Wydaje mi
się,
że mógłby załatwić temat w miarę prosty skrypt backendowy, który odpowiadałby za wypełnianie pól z linkiem tam gdzie jeszcze takiego linku nie ma
(oczywiście
mógłby brać pod uwagę jakieś dodatkowe warunki). Staram się znaleźć
jakieś
rozwiązanie, które nie będzie wymagało dużych zmian w kodzie generowania obciążeń/faktur. Pewnie, że fajnie byłoby mieć centralne miejsce dodawania
samego
dokumentu handlowego, a potem również centralne miejsce dodawania doń pozycji. Przy okazji pytanie: chodzi o powiązanie linków z:
- Dokumentem (rekord w 'documents').
- Pozycją dokumentu (rekord w 'invoicecontents').
- Operacją finansową (rekord w 'cash').
?
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
-- Pozdrawiam Tomasz Chiliński, Chilan opiekun projektu LMS - https://lms.org.pl kierownik projektu LMS Plus / LMS+ - https://lms-plus.org _______________________________________________ lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
lms mailing list lms@lists.lms.org.pl https://lists.lms.org.pl/mailman/listinfo/lms
uczestnicy (3)
-
Paweł Sienkiewicz -
Rafał Wójcik -
Tomasz Chiliński