Usługi
Zamówienia, płatności, stan magazynowy i operacje sprzedażowe zaprojektowane wokół rzeczywistej realizacji zamówień.
Klient widzi katalog, koszyk i checkout. Firma musi skoordynować zamówienie, płatność, stan magazynowy, magazyn, fakturę, dostawę, CRM, komunikację z klientem, zwroty i refundacje. Użyteczny workflow eCommerce przypisuje każdemu elementowi jasną odpowiedzialność i czyni wyjątki widocznymi.
GiSoft projektuje i modernizuje takie workflow bez założenia, że każdy sklep potrzebuje tych samych stanów, integracji lub architektury. Proces powinien odpowiadać sposobowi sprzedaży produktów fizycznych, usług cyfrowych, subskrypcji lub zamówień B2B.
Warto uzgodnić, kiedy zamówienie powstaje, kiedy rezerwowany jest towar, kto może je zatwierdzić, kiedy powstaje faktura i co oznaczają anulowanie lub refundacja. Stan zamówienia należy do logiki biznesowej backendu, a nie do ekranu w przeglądarce.
W wielu firmach wewnętrzny numer zamówienia utworzony podczas checkoutu łączy płatność, rezerwację, ERP, fakturę, wysyłkę i support. Często upraszcza odzyskiwanie, ale właściwa kolejność zależy od produktu i procesu handlowego.
Powrót z bramki płatniczej nie jest ostatecznym potwierdzeniem. Klient może zamknąć przeglądarkę, przekierowanie może nie zadziałać, a płatność może nadal oczekiwać. Aplikacja powinna korzystać ze zweryfikowanego potwierdzenia po stronie serwera od dostawcy albo z innego uzgodnionego sygnału rozliczenia, a potem aktualizować własny stan biznesowy płatności.
Autoryzacja, pobranie środków i potwierdzenie to odrębne pojęcia. Jeden dostawca może najpierw zarezerwować środki, inny potwierdzić zakończoną płatność później przez webhook. Workflow zamówienia powinien odzwierciedlać znaczenie potrzebne sklepowi: oczekuje na płatność, autoryzowana, opłacona, odrzucona, anulowana, zwrócona lub wymagająca wyjaśnienia.
Dostępność, rezerwacja i pomniejszenie stanu nie są tym samym. Dostępność odpowiada, czy produkt można obecnie zaoferować. Rezerwacja czasowo przypisuje sztuki do zamówienia według określonych warunków. Pomniejszenie stanu zapisuje końcowy lub związany z realizacją ruch magazynowy. ERP albo WMS może być źródłem prawdy, ale sklep nadal potrzebuje jasnych reguł, co może pokazać oraz kiedy rezerwacja wygasa lub zostaje zwolniona.
Wyobraźmy sobie starszy sklep Symfony, który zaczynał od katalogu, koszyka, checkoutu, zamówień i e-maili. Z czasem doszły płatności, synchronizacja ERP i WMS, API kuriera, fakturowanie oraz aktualizacje CRM. Jeśli kontroler checkoutu wywołuje bezpośrednio każdy system zewnętrzny, jeden wolny dostawca może opóźnić klienta, a częściową awarię trudno wyjaśnić.
Kontrolowana poprawa zachowuje istniejące reguły zamówień i umieszcza workflow aplikacyjny między checkoutem a usługami zewnętrznymi. Adaptery płatności, ERP, magazynu, faktur i powiadomień obsługują wtedy własne granice. Nie wymaga to przepisywania całego sklepu; można zacząć od obszaru o największym ryzyku operacyjnym.
Sukces HTTP ani odebranie webhooka nie musi oznaczać zakończenia całego procesu biznesowego. Timeout także nie dowodzi, że operacja zewnętrzna się nie powiodła: ERP, operator płatności lub usługa fakturowa mogły wykonać żądanie przed utratą odpowiedzi.
Zapisuj lokalną próbę, używaj trwałego identyfikatora biznesowego lub żądania, jeśli system zewnętrzny go obsługuje, i uzgadniaj niepewne przypadki ze źródłem prawdy. Idempotencja oznacza, że powtórzona operacja nie powinna wywołać dodatkowego zamierzonego skutku biznesowego. Zależy od projektu aplikacji oraz, gdy to istotne, wsparcia dostawcy lub wspólnego identyfikatora; sam identyfikator nie daje gwarancji.
Ponowienia powinny dotyczyć błędów chwilowych i mieć limit. Błędne dane albo brak decyzji biznesowej wymagają poprawy lub ręcznego przeglądu. Zadania w tle dobrze sprawdzają się przy aktualizacji ERP, fakturowaniu, synchronizacji stanów i powiadomieniach, ponieważ checkout nie powinien czekać na każde dalsze działanie.
Anulowanie, refundacja i zwrot to różne zdarzenia biznesowe. Anulowanie może zwolnić rezerwację przed wysyłką, refundacja nastąpić po rozliczeniu, a zwrot wymagać decyzji magazynu i korekty księgowej. Ich reguły powinny być jawne, łącznie z tym, kto może je zatwierdzić i który system zapisuje stan końcowy.
Rollback bazy nie odwróci zakończonej płatności, wysłanego e-maila ani akcji ERP. Odzyskanie może wymagać uzgodnienia, akcji kompensującej, bezpiecznego ponowienia albo obsługi ręcznej. Monitoring powinien wskazywać zamówienia oczekujące zbyt długo, błędne zadania, rozbieżności płatności, konflikty magazynowe i sprawy wymagające reakcji.
Stosuj autoryzację do zmian administracyjnych, chroń dane klientów i finansowe, weryfikuj webhooki płatnicze, a dane dostępowe dostawców trzymaj poza kodem i zbędnymi logami. Testuj krytyczne ścieżki: jednokrotne utworzenie zamówienia, powtórzone powiadomienia, rezerwację i zwalnianie stanu, fakturowanie oraz odzyskanie po błędzie.
GiSoft zaczyna od istniejącego procesu zamówienia, wskazuje źródło prawdy i punkty ryzyka, a potem poprawia najważniejsze granice. Właściwy projekt zależy od modelu sprzedaży, polityki stanów i połączonych systemów. Celem jest proces, który zespół rozumie i potrafi odzyskać, a nie obietnica idealnego działania wszystkich usług zewnętrznych.
