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ć:
>> 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:
>>>> 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