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