Wypłaty

Problem#

Wypłata wygląda na przelew, a jest odpowiedzią na pytanie, ile pieniędzy należy się sprzedawcy w konkretnym momencie. To pytanie zależy od zamówień, zwrotów, prowizji, ewentualnych potrąceń i od tego, ile już wypłacono.

Do tego dochodzi asymetria czasu: pieniądze wychodzą raz i nieodwołalnie, a zwrot może przyjść tydzień później.

Minimalna wersja#

• Kwota należna liczona z zamówień, a nie trzymana jako saldo, które trzeba aktualizować.
• Reguła kwalifikacji: które zamówienia w ogóle wchodzą do wypłaty.
• Wypłata jako niezmienny zapis: kwota, moment, zakres zamówień, identyfikator przelewu.
• Wykonanie ręczne, wyzwalane przez człowieka.

Okno wstrzymania jako parametr#

Prawie każdy marketplace wstrzymuje wypłatę na jakiś czas po dostawie, żeby zdążył wpłynąć ewentualny zwrot. Długość tego okna wynika z polityki zwrotów, a nie z architektury.

To ma być wartość konfiguracyjna, a nie liczba wpisana w kod. Pierwszy klient z inną polityką zwrotów albo inną kategorią towaru zmieni ją w pierwszym tygodniu.

Czego nie budować teraz#

• Wypłat natychmiastowych.
• Salda sprzedawcy jako rekordu aktualizowanego przy każdej operacji. Liczenie na żądanie jest prostsze i nie potrafi się rozjechać.
• Automatycznego harmonogramu, zanim ręczne wykonanie zacznie boleć.
• Obsługi salda ujemnego, dopóki nie wystąpi pierwszy przypadek.

Zaplanuj z góry#

Wypłata jest niezmienna#

Zapis wypłaty nie może być aktualizowany, gdy przyjdzie zwrot. Zwrot po wypłacie jest osobnym zdarzeniem, które odwołuje część poprzedniego. Nadpisanie kwoty niszczy jedyny ślad tego, co faktycznie wyszło z konta.

Kwalifikacja jako reguła, nie flaga#

Zamówienie gotowe do wypłaty to wynik kilku warunków sprawdzanych w momencie wypłaty. Flaga ustawiana wcześniej rozjedzie się przy zwrocie, który przyszedł po jej ustawieniu.

Droga powrotna od pierwszego dnia#

Zwrot po wykonanej wypłacie zdarzy się. Model musi wiedzieć, która wypłata objęła które zamówienie, żeby dało się cofnąć właściwą kwotę. Bez tego powiązania pozostaje odejmowanie z przyszłych wypłat, co przy sprzedawcy, który przestał sprzedawać, kończy się stratą.

Wyzwalacze#

• pierwszy zwrot po wykonanej wypłacie;
• sprzedawca pyta, za które zamówienia dostał daną kwotę;
• wypłaty zaczynają zajmować stały blok czasu w tygodniu;
• pierwsza pomyłka w kwocie wypłaconej ręcznie;
• pierwsza rozbieżność między sumą wypłat a wyciągiem.

Następny etap#

Po drugim wyzwalaczu: zestawienie pokazujące, które zamówienia weszły do której wypłaty. To najczęściej zadawane pytanie sprzedawcy i najtańsza rzecz do zbudowania. Po trzecim i czwartym: harmonogram z zabezpieczeniem przed podwójnym wykonaniem. Po piątym: uzgadnianie z danymi dostawcy.

Częste błędy#

Co się sprawdza w praktyce#

Najważniejsze przy wypłatach okazało się powiązanie każdej z nich z konkretnymi zamówieniami. To wygląda na szczegół księgowy, a jest warunkiem dwóch rzeczy naraz: odpowiedzi na pytanie sprzedawcy, za co dostał pieniądze, i możliwości cofnięcia właściwej kwoty, gdy zwrot przyjdzie po przelewie.

Druga rzecz: wypłata wykonywana raz. Operacje pieniężne trzeba zabezpieczyć tak, żeby ponowienie po błędzie sieciowym nie wysłało przelewu drugi raz. To jest ten rodzaj problemu, który przy pierwszym wystąpieniu kosztuje realne pieniądze, a nie tylko czas.

Checklista#

• Kwota należna jest liczona, nie przechowywana jako saldo.
• Okno wstrzymania jest wartością konfigurowalną.
• Wypłata jest zapisem niezmiennym, powiązanym z konkretnymi zamówieniami.
• Istnieje droga powrotna dla zwrotu, który przyszedł po wypłacie.
• Ponowienie operacji nie może wysłać przelewu drugi raz.
• Zwrot u jednego sprzedawcy nie dotyka wypłaty innego.