Kredyt kupiecki w sprzedaży firmowej. Jak połączyć koszyk z limitami i fakturami?

W sprzedaży firmowej "zapłać później" nie jest wygodną wersją płatności kartą. To decyzja kredytowa i operacyjna. Kupujący może mieć limit 150 000 PLN, termin płatności 30 dni, otwarte faktury, częściowe płatności, zamówienia w realizacji, ręczne blokady finansowe, różne limity dla oddziałów i specjalne warunki dla konkretnych kategorii.

Jeżeli sklep widzi tylko aktualny koszyk, podejmuje złą decyzję. Może zablokować klienta, który rano opłacił fakturę, ale system finansowo-magazynowy jeszcze nie zsynchronizował salda. Może też przyjąć zamówienie, mimo że klient ma już trzy otwarte zamówienia i realnie przekroczy limit po ich wysyłce.

Dobry kredyt kupiecki w sprzedaży firmowej nie pyta systemu finansowo-magazynowego przy każdym kliknięciu i nie ufa ślepo zapamiętanym danym. Buduje osobny rejestr limitu: uzgodniony limit, aktualne wykorzystanie, rezerwacje, blokady, zamówienia, korekty, płatności i statusy faktur. Dopiero ten rejestr mówi ścieżce zakupu, czy można kontynuować, wymagać akceptacji, zmniejszyć koszyk albo skierować kupującego do handlowca.

Kredyt kupiecki to możliwość złożenia zamówienia teraz i zapłaty później na podstawie uzgodnionego limitu oraz terminu płatności, na przykład 14, 30 albo 60 dni. W sklepie dla firm wygląda jak metoda płatności, ale jej logika należy do finansów, ryzyka i systemu finansowo-magazynowego.

Najważniejsza różnica względem konsumenckiego "kup teraz, zapłać później": w sprzedaży firmowej zwykle nie chodzi o jednorazową ratę dla konsumenta, tylko o relację handlową, limity z umowy, faktury, konta firmowe, oddziały, akceptację zamówień i uzgadnianie w księgowości. Każda decyzja musi zostawić ślad do późniejszego sprawdzenia.

W praktyce sklep powinien umieć odpowiedzieć na jedno pytanie: "ile realnie wolnego limitu ma ten kupujący teraz, dla tego koszyka, tego oddziału i tej daty dostawy?". Jeśli odpowiedź brzmi "nie wiemy", automatyzacja jest tylko pozorna.

System finansowo-magazynowy jest źródłem prawdy dla należności, faktur, płatności i blokad finansowych. Nie zawsze jest jednak dobrym miejscem do obsługi każdego kliknięcia w koszyku. Starsze instalacje SAP, Comarch, Microsoft Dynamics, enova, Subiekt albo własne systemy mogą mieć limity zapytań, wolne raporty i okna księgowania.

Z systemu finansowo-magazynowego warto synchronizować: konto klienta, limit kredytowy, terminy płatności, kwotę zaległości, otwarte faktury, płatności nieprzypisane do faktur, noty korygujące, ręczne blokady, strukturę oddziałów i statusy faktur. Nie warto pytać go o to wszystko przy każdym otwarciu mini koszyka.

Bezpieczniejszy model to synchronizacja po konkretnych zdarzeniach i cykliczne odświeżanie: płatność zaksięgowana, faktura wystawiona, nota korygująca, zamówienie wysłane, zamówienie anulowane, limit zmieniony, klient zablokowany. Ścieżka zakupu używa aktualnego widoku danych, a dla dużych koszyków może uruchomić dodatkową weryfikację przed ostatecznym złożeniem zamówienia.

Limit nie powinien być sprawdzany tylko w chwili kliknięcia "złóż zamówienie". W koszyku firmowym kupujący może pracować nad zamówieniem kilka dni, a kilku pracowników tej samej firmy może tworzyć równoległe koszyki. Bez rezerwacji limitu dwa zamówienia mogą osobno wyglądać poprawnie i razem przekroczyć dopuszczalne wykorzystanie kredytu.

Dobre wdrożenie rozróżnia miękką i twardą blokadę limitu. Miękka blokada może zarezerwować limit dla aktywnego koszyka przez krótki czas. Twarda blokada powstaje po złożeniu zamówienia i trwa do anulowania, odrzucenia, fakturowania albo wysyłki. Każda blokada musi mieć czas wygaśnięcia, właściciela, źródło i relację do zamówienia.

To jest miejsce na bezpieczne ponawianie operacji i spójny zapis po stronie zaplecza. Jeśli kupujący kliknie dwa razy, część systemu przyjmująca zamówienie nie może zarezerwować limitu dwa razy. Jeśli system finansowo-magazynowy odpowie po czasie, system sprzedaży musi wiedzieć, czy zamówienie jest przyjęte, czeka na akceptację, jest zablokowane czy wymaga sprawdzenia przez finanse.

Moduł koszyka w Medusa daje zarządzanie koszykiem, adresami, pozycjami koszyka, metodami dostawy, korektami, liniami podatkowymi i przypisaniem koszyka do kanału sprzedaży, regionu oraz klienta. Moduł płatności obsługuje autoryzację, pobranie płatności, zwrot płatności, zbiory płatności, dostawców płatności i zdarzenia zewnętrzne. To dobry fundament, ale kredyt kupiecki wymaga własnych reguł biznesowych.

W GMI zwykle nie wkładamy reguł wykorzystania limitu do kodu odpowiedzialnego za ekrany. Next.js pokazuje status limitu i ścieżkę zakupu. MedusaJS trzyma rdzeń sprzedażowy. NestJS albo osobny moduł obsługuje zasady kredytu kupieckiego, rejestr limitu, połączenia z systemem finansowo-magazynowym, ścieżkę akceptacji, bezpieczne ponawianie operacji i dziennik decyzji.

Taki podział ułatwia później kanał mobilny. React Native/Expo może używać tych samych operacji: sprawdzenia dostępnego limitu, rezerwacji limitu, zwolnienia blokady, wysłania zamówienia do akceptacji i potwierdzenia zapłaty faktury. Nie budujesz drugiego zestawu reguł kredytowych tylko dla aplikacji mobilnej.

Kredyt kupiecki nie kończy się na przyjęciu zamówienia. Po ścieżce zakupu zaczyna się cykl: zamówienie przyjęte, wysyłka, faktura wystawiona, termin płatności, przypomnienie, płatność częściowa, nota korygująca, spór, blokada po terminie i uzgadnianie danych. Każdy z tych stanów może zmienić dostępny limit.

Jeżeli używasz Stripe Invoicing lub podobnej warstwy fakturowania, warto oddzielić terminy płatności od decyzji kredytowej. Faktura może mieć metodę wysłania do klienta, termin płatności i noty korygujące, ale system sprzedaży nadal musi wiedzieć, czy klient ma prawo do kolejnego zamówienia przed zapłatą poprzedniego.

Uzgadnianie danych powinno porównywać co najmniej cztery źródła: zamówienie w sklepie, rejestr limitu, należności w systemie finansowo-magazynowym i dostawcę płatności lub fakturowania. Bez tego finanse będą eksportować pliki w formacie CSV i ręcznie tłumaczyć, dlaczego sklep pokazał limit 40 000 PLN, a system finansowy zablokował konto.

Najgorsze doświadczenie to komunikat "limit przekroczony, skontaktuj się z handlowcem". Kupujący firmowy potrzebuje informacji operacyjnej: dostępny limit, wykorzystane saldo, przeterminowane faktury, brakująca kwota, możliwość częściowej płatności, ścieżka akceptacji albo kontakt do opiekuna z kontekstem koszyka.

Dobra ścieżka zakupu pokazuje trzy warianty: zamówienie mieści się w limicie i idzie dalej, zamówienie wymaga akceptacji, albo zamówienie wymaga zmiany płatności lub zmniejszenia koszyka. Dla dużych klientów przydają się też numer zamówienia zakupu, centrum kosztów, rola kupującego, wybór oddziału i dokumenty do pobrania.

To jest szczególnie ważne w kanale mobilnym. Jeśli aplikacja React Native ma uproszczony komunikat bez faktur i limitu, kupujący i tak zadzwoni do handlowca. Wtedy automatyzacja tylko przenosi problem z koszyka do obsługi klienta.

W rozpoznaniu biznesu, projektu i technologii zaczynamy od warsztatu z finansami, sprzedażą, operacjami i zespołem technicznym. Mapujemy typy klientów, limity, terminy płatności, blokady, faktury, korekty, zwroty, akceptacje, połączenia z systemem finansowo-magazynowym, okna księgowania, oczekiwany poziom dostępności połączeń i sytuacje awaryjne. Bez finansów przy stole kredyt kupiecki wygląda łatwo tylko na makiecie.

Typowa architektura to MedusaJS jako oddzielony rdzeń sprzedażowy, sklep Next.js, NestJS dla rejestru limitu i połączeń między systemami, PostgreSQL dla zapisów transakcyjnych, Redis i kolejki dla synchronizacji oraz ponowień, system finansowo-magazynowy, baza produktów, magazyn oraz dostawca płatności lub fakturowania. Jeżeli aplikacja mobilna jest kanałem zamówień, dokładamy React Native/Expo na tych samych zasadach wymiany danych między systemami.

Po rozpoznaniu biznesu, projektu i technologii możemy rozmawiać o stałej cenie, bo znane są ryzyka: jakość danych finansowo-magazynowych, dostępność połączeń, reguły polityki kredytowej, ścieżka akceptacji, uzgadnianie danych, wgląd w działanie systemu, migracja kont i przekazanie projektu. Klient zachowuje kod źródłowy, dokumentację i architekturę bez uzależnienia od dostawcy technologicznego.

Użyj tej listy przed wyborem platformy albo integratora. Jeśli nie znasz odpowiedzi, projekt może działać tylko w szczęśliwej ścieżce i rozpaść się przy pierwszej płatności częściowej, nocnym księgowaniu albo sporze o fakturę.

• Który system jest prawdą dla limitu kredytowego, przeterminowanych faktur, otwartych zamówień i ręcznych blokad?
• Czy limit jest przypisany do firmy, oddziału, roli kupującego, waluty, regionu czy kanału sprzedaży?
• Kiedy rezerwujemy limit: koszyk, złożenie zamówienia, akceptacja, wysyłka czy faktura?
• Jak zwalniamy blokadę przy anulowaniu, częściowej wysyłce, zwrocie albo korekcie?
• Jak obsługujemy płatność częściową, notę kredytową, spór, blokadę po terminie i ręczne nadpisanie decyzji przez handlowca?
• Jak często synchronizujemy system finansowo-magazynowy i co robimy, gdy jest niedostępny?
• Jakie statusy pokazujemy kupującemu zamiast prostego "limit przekroczony"?
• Jak uzgadnianie danych porównuje sklep, rejestr limitu, system finansowo-magazynowy i dostawcę fakturowania?