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