Architektura B2B e-commerce: źródła prawdy, reguły handlowe i wyjątki

1. Zacznij od procesu i źródeł prawdy, a listę funkcji zostaw na później

Handel B2B opiera się na domenach, które w firmie zwykle już istnieją. Klient jest w CRM lub ERP, produkt w PIM, warunki handlowe w ERP, dostępność w WMS albo OMS, a zamówienie przechodzi przez kilka systemów. Nowa platforma nie powinna przejmować wszystkich tych zadań z automatu. Powinna mieć jasno określony własny zakres i uzgodnione kontrakty z pozostałymi systemami.

Dla każdego pola wskaż jedno źródło prawdy. Różne atrybuty tej samej encji mogą pochodzić z różnych systemów: nazwa firmy i limit kredytowy z ERP, preferencje użytkownika z platformy commerce, a status dostawy z OMS. Kopie danych są dopuszczalne, ale każda musi mieć właściciela synchronizacji, znacznik wersji i zasadę rozstrzygania konfliktów.

Pierwszym dokumentem z etapu discovery powinna być mapa procesu od logowania do faktury i zwrotu. Zaznacz na niej decyzje podejmowane automatycznie, czynności ręczne, momenty, od których nie ma odwrotu, i wyjątki. Jeśli dziś proces działa dzięki wiedzy handlowca, tę wiedzę trzeba spisać, zanim zacznie się cokolwiek automatyzować.

2. Organizacje, oddziały, użytkownicy i role

Tożsamość osoby i konto handlowe firmy to dwie osobne rzeczy. Jeden użytkownik może działać w imieniu kilku firm lub oddziałów, a jego uprawnienia mogą zależeć od tego, w którym kontekście akurat pracuje. Model danych powinien obejmować organizację, konta rozliczeniowe i dostawcze, członkostwo, role, limity oraz czasowe zastępstwa.

Uprawnienia nie powinny sprowadzać się do nazw ról w rodzaju „admin” i „buyer”. Lepiej zdefiniować konkretne czynności: zapraszanie użytkowników, podgląd cen, tworzenie koszyka, składanie zamówień, akceptacja do określonego limitu, dostęp do faktur, zarządzanie adresami. Rola jest wtedy zestawem takich czynności, a reguły dostępu dodatkowo sprawdzają organizację, oddział, wartość i stan obiektu.

Ukrycie przycisku w interfejsie nie jest kontrolą dostępu. Backend musi sprawdzać uprawnienia dla każdego obiektu osobno. OWASP wymienia brak autoryzacji na poziomie obiektu i na poziomie funkcji jako podstawowe ryzyka API, a wielopoziomowy model B2B sprawia, że takie błędy zdarzają się łatwiej.

• Rozdziel użytkownika, jego członkostwo w organizacji i konto klienta w ERP.
• Przechowuj historię nadawania, zmiany i odbierania uprawnień.
• Zadbaj o to, żeby odejście pracownika nie usuwało historii zamówień jego firmy.
• Przy operacjach wysokiego ryzyka wymagaj ponownego uwierzytelnienia.
• Administrator po stronie klienta nie może nadać nikomu szerszych uprawnień, niż ma jego organizacja.

3. Ceny: w B2B cena wynika z kontekstu zakupu

Cena B2B może zależeć od firmy, umowy, oddziału, rynku, waluty, jednostki miary, ilości, kombinacji produktów, daty, promocji, podatku i sposobu dostawy. Wymaganie w stylu „zsynchronizować ceny” jest więc zbyt ogólne. Trzeba określić dane wejściowe do kalkulacji, kolejność stosowania reguł, zasady zaokrągleń i system, który wylicza cenę ostateczną.

Stosuje się trzy główne podejścia. Wyliczone z góry cenniki są szybkie i odporne przy odczycie, ale liczba rekordów szybko rośnie. Wyliczanie ceny na bieżąco daje aktualny wynik, ale uzależnia interfejs i checkout od dostępności silnika cenowego. Model hybrydowy kopiuje podstawowe warunki, a do źródła sięga tylko przy wyjątkach albo końcowej walidacji. Wybór zależy od liczby kombinacji, akceptowalnego opóźnienia i tego, ile kosztuje błędna cena.

Storefront nigdy nie jest źródłem ostatecznej ceny. Backend zwraca rozbicie ceny, walutę, jednostkę, podatek, rabaty, termin ważności wyniku i powód ewentualnej zmiany. W checkoucie cenę liczy się jeszcze raz. Jeśli system zmieni cenę bez wyjaśnienia, klient zadzwoni do handlowca.

• Testuj ceny na zestawie wzorcowych umów i koszyków zatwierdzonym przez dział handlowy i finanse.
• Wersjonuj reguły cenowe i zapisuj przy zamówieniu kopię wyliczenia.
• Cache cen ma sens tylko wtedy, gdy klucz uwzględnia cały istotny kontekst.
• Ustal, co się dzieje, gdy cena jest niedostępna: blokada zakupu, zapytanie ofertowe albo wyraźnie oznaczona cena katalogowa.

4. Dostępność: obiecuj tylko to, co magazyn i logistyka są w stanie dowieźć

Stan fizyczny, ilość możliwa do obiecania (ATP), towar zarezerwowany i termin dostawy to różne informacje. Klient B2B zwykle chce wiedzieć, ile i kiedy może dostać, a liczba sztuk na magazynie mniej go interesuje. Model dostępności powinien uwzględniać magazyn, rynek, jednostkę, minimalną wielkość zamówienia, zamówienia oczekujące na dostawę i reguły przydziału towaru.

To, jak świeże muszą być dane, zależy od ryzyka. Przy produktach konfigurowanych lub importowanych wystarczy deklarowany termin. Przy szybko rotującym towarze sprzedawanym w kilku kanałach potrzebna jest częsta synchronizacja, rezerwacja albo sprawdzenie stanu tuż przed złożeniem zamówienia. Jeśli źródło aktualizuje się partiami, nie obiecuj danych „w czasie rzeczywistym”.

Przed potwierdzeniem zamówienia backend jeszcze raz sprawdza dostępność i informuje klienta o różnicach. Jeśli zamówienie może być zrealizowane tylko częściowo, model musi pozwalać na podział, dosłanie reszty później albo decyzję klienta. Gdy taki wyjątek trafia tylko do notatki w ERP, samoobsługa przestaje działać.

5. Cykl życia zamówienia: jedna maszyna stanów, wiele widoków

Zamówienie to proces, a nie rekord z polem tekstowym „status”. Może przechodzić przez stany takie jak szkic, złożone, oczekujące na akceptację, zaakceptowane, przyjęte, z przydzielonym towarem, częściowo zrealizowane, zrealizowane, zafakturowane, anulowane albo odrzucone. Konkretna lista zależy od firmy, ale każde przejście między stanami musi mieć warunek, autora, znacznik czasu i skutek.

Stan handlowy, płatniczy i realizacyjny warto prowadzić osobno. Zamówienie może być przyjęte, częściowo zrealizowane i jeszcze niezafakturowane. Jeden ogólny status „w realizacji” ukrywa problem zarówno przed klientem, jak i przed obsługą. Portal może pokazywać klientowi uproszczony status, ale powinien go wyprowadzać z jawnie zdefiniowanych stanów źródłowych.

W procesach rozproszonych nie każdą operację da się cofnąć. Microsoft opisuje transakcję kompensującą jako operację naprawczą w logice biznesowej, stosowaną w procesach z ostateczną spójnością danych. W B2B anulowanie zamówienia po jego wysłaniu do ERP może wymagać osobnej komendy, akceptacji i dokumentu. Samo usunięcie rekordu tu nie wystarczy.

• Każde przejście ma warunek, wymagane uprawnienie i zdarzenie w logu audytowym.
• Momenty bez odwrotu są jawnie opisane, np. rozpoczęcie produkcji lub wystawienie dokumentu.
• Zmiana wprowadzona przez pracownika wymaga podania powodu i zostaje w historii.
• Klient widzi, które pozycje zostały zaakceptowane, odrzucone, odłożone albo wysłane.
• Ponowienie zamówienia tworzy nowy koszyk, w którym cena i dostępność są wyliczane od nowa.

6. Podział zadań między ERP, PIM, OMS i platformę commerce

ERP jest często źródłem danych finansowych i operacyjnych, ale nie powinien stawać się synchronicznym backendem całego portalu. PIM odpowiada za jakość i publikację informacji o produktach. OMS steruje realizacją i przydziałem towaru, jeśli proces tego wymaga. Platforma commerce odpowiada za doświadczenie zakupowe, koszyk, reguły kanału i przyjęcie zamówienia od klienta.

Granice między systemami wyznacza się według tego, co dany system robi, a nie według tabel w bazie. Platforma może przechowywać kopię danych klienta potrzebną do szybkiego logowania i wyświetlania adresów, ale przyznanie limitu kredytowego zostaje w ERP. PIM może opublikować produkt w kanale, ale to commerce decyduje, czy w danym kontekście da się go kupić.

Unikaj sytuacji, w której każdy system jest zintegrowany z każdym. Dla danych wspólnych stosuj kontrakty domenowe i adaptery. Nie buduj też centralnej szyny, w której ląduje cała logika biznesowa i za którą nikt nie odpowiada. Reguła powinna zostać w tej domenie, która odpowiada za jej wynik.

7. Synchronizacja: czas rzeczywisty tylko tam, gdzie opóźnienie kosztuje więcej

Synchronizacja synchroniczna daje aktualną odpowiedź, ale uzależnia systemy od siebie nawzajem i wydłuża czas oczekiwania użytkownika. Asynchroniczna izoluje awarie, lepiej znosi skoki ruchu i pozwala ponawiać operacje, ale wprowadza opóźnienie i wymaga regularnego uzgadniania danych. Żaden z tych modeli nie pasuje do całej platformy.

Synchroniczny odczyt wybierz wtedy, gdy klient musi podjąć decyzję na podstawie aktualnych danych, system źródłowy ma odpowiednie SLO, a rozwiązanie zastępcze byłoby ryzykowne. Zdarzenia i kolejki sprawdzają się przy publikacji katalogu, aktualizacji kont, eksporcie zamówień i dokumentów oraz przy wszystkim, czego klient nie musi zobaczyć w tej samej odpowiedzi.

Kolejka nie poprawi jakości danych. Trzeba znać maksymalne opóźnienie, kolejność komunikatów, sposób usuwania duplikatów, obsługę komunikatów, których nie da się przetworzyć, i zachowanie po przekroczeniu czasu. Wzorzec queue-based load leveling wyrównuje obciążenie, ale odbiorca nadal musi kontrolować przepustowość i monitorować zaległości.

8. Idempotencja i uzgadnianie danych: ponawianie operacji to normalna sytuacja

Przekroczenie czasu nie oznacza, że operacja się nie wykonała. Klient albo integracja musi mieć możliwość ponowienia komendy bez podwójnego skutku. Klucz idempotencji identyfikuje intencję biznesową, a nie pojedyncze wywołanie HTTP. Ten sam identyfikator powinien przetrwać ponowienie, restart procesu i zmianę połączenia sieciowego.

Odbiorca zdarzeń zapisuje identyfikator przetworzonego komunikatu albo korzysta z naturalnego klucza operacji. Aktualizacja powinna sprawdzać wersję encji, żeby starszy komunikat nie nadpisał nowszego stanu. Obietnica dostarczenia dokładnie raz (exactly-once) na całej ścieżce między niezależnymi systemami rzadko jest realna. W praktyce celem jest dostarczenie co najmniej raz i skutki odporne na powtórzenia.

Uzgadnianie danych porównuje stan w różnych systemach niezależnie od bieżących integracji. Proces uruchamiany codziennie lub częściej wychwytuje zamówienia, które nie zostały wyeksportowane, niezgodne sumy, brakujące pozycje, płatności bez zamówień i statusy, które utknęły. Wyniki trafiają do kolejki wyjątków, która ma właściciela i bezpieczną ścieżkę naprawy.

• Klucz idempotencji dla złożenia zamówienia, płatności, anulowania, zwrotu środków i eksportu.
• Wspólny identyfikator korelacyjny dla zamówienia, komunikatów i wywołań zewnętrznych.
• Wzorzec outbox lub podobny mechanizm tam, gdzie zapis w domenie i publikacja zdarzenia muszą być spójne.
• Kolejka DLQ to nie archiwum. Ma alert, termin obsługi i możliwość ponownego przetworzenia.
• Raport z uzgadniania pokazuje liczbę, wartość i wiek rozbieżności.

9. Scenariusze awarii: zaplanuj, jak system ma się zachować

W B2B część zamówień ma dużą wartość, a błędna cena albo zgubione zamówienie mogą być poważniejsze niż chwilowa niedostępność strony. Dla każdego systemu, od którego zależy platforma, określ, jak ma działać w trybie ograniczonym. Nie każda awaria wymaga wyłączenia całego portalu.

Ponawianie stosuj przy błędach przejściowych, z rosnącym odstępem i losowym rozrzutem. Błąd walidacji danych nie zniknie od ponawiania, więc powinien trafić do widocznej kolejki wyjątków. Circuit breaker chroni system źródłowy przed lawiną zapytań, ale musi iść w parze z komunikatem dla użytkownika i kontrolowanym rozwiązaniem zastępczym.

Działanie naprawcze nie zawsze oznacza automatyczne wycofanie zmian. Jeśli zamówienie trafiło już do produkcji, system może musieć wstrzymać proces i poprosić pracownika o decyzję. Przy wyjątkach o dużym znaczeniu zaplanuj udział człowieka i nie chowaj ich w logach.

10. Bezpieczeństwo i audyt przy wielu organizacjach klientów

Najważniejszą granicą bezpieczeństwa jest tenant, czyli firma klienta. Każde zapytanie o użytkownika, cenę, koszyk, zamówienie, fakturę czy adres musi być ograniczone do aktualnego kontekstu organizacji. Testy powinny próbować podmieniać identyfikatory między firmami i rolami, a nie tylko sprawdzać poprawny scenariusz.

Dla kont z szerokimi uprawnieniami stosuj MFA, krótkie sesje przy operacjach wysokiego ryzyka i rejestrowanie zmian. NIST SP 800-63B opisuje wymagania dotyczące uwierzytelniania i zarządzania metodami uwierzytelniania. Poziom zabezpieczeń dobieraj do skutków operacji, a nie do tego, co jest najłatwiejsze we wdrożeniu.

Log audytowy jest zapisem biznesowym: kto, w jakiej organizacji i roli, co zmienił, z jakiego stanu na jaki, kiedy i dlaczego. Nie powinno się go dać edytować ze zwykłego panelu. Jednocześnie nie zapisuj w nim pełnych komunikatów z danymi osobowymi i kluczami tylko dlatego, że kiedyś mogą się przydać przy debugowaniu.

• Izolacja tenantów automatycznie testowana dla API i eksportów.
• MFA dla administratorów po stronie klienta, pracowników obsługi i dostępu do produkcji.
• Zasada minimalnych uprawnień i regularny przegląd członkostw.
• Podpisy webhooków, lista dozwolonych adresów tam, gdzie ma to uzasadnienie, i ochrona przed ponownym odtworzeniem.
• Log audytowy dla cen, limitów, ról, akceptacji i zmian w zamówieniach.
• Retencja, anonimizacja i eksport danych ustalone przed startem.

11. Obserwowalność: mierz przepływ zamówień, a nie tylko pracę serwerów

Osoba z obsługi musi umieć odpowiedzieć na pytanie, gdzie jest konkretne zamówienie i dlaczego tam utknęło. Wspólny identyfikator korelacyjny powinien łączyć sesję lub szkic zamówienia, jego złożenie, decyzję o akceptacji, eksport, numer w ERP, płatność i realizację. Trace techniczny jest uzupełnieniem, ale nie zastąpi historii zamówienia widocznej dla działu obsługi.

Metryki techniczne obejmują czas odpowiedzi, odsetek błędów, zaległości w kolejkach i zużycie zasobów. Metryki procesowe to odsetek zamówień wymagających ręcznej poprawki, czas od złożenia zamówienia do jego przyjęcia w ERP, opóźnienie cen i stanów, liczba rozbieżności wykrytych przy uzgadnianiu i wiek najstarszego wyjątku. To one pokazują, czy automatyzacja rzeczywiście zmniejsza ilość pracy.

Alert powinien mieć próg, okno czasowe, adresata i runbook. Jeśli system sam ponawia błędy integracji, nie ma sensu alarmować przy każdym z nich. Alarmuj wtedy, gdy wyczerpią się próby ponowienia, rosną zaległości, opóźnienie przekracza uzgodniony poziom albo wartość zamówień o niepewnym stanie przekracza zaakceptowany próg.

12. Wdrażanie etapami: pełny proces dla wąskiej grupy klientów

Dobre MVP w B2B to nie szeroki katalog z niedokończonym checkoutem. To kompletny proces dla ograniczonej grupy: jeden rynek, jeden typ klienta, jeden magazyn, jedna waluta i jeden model cen. Klient powinien móc się zalogować, zobaczyć właściwy asortyment i swoje ceny oraz złożyć zamówienie, a zespół operacyjny powinien móc je obsłużyć do końca.

Do pilota wybierz klientów o typowej złożoności, bez najbardziej nietypowych wyjątków. Zbyt prosty klient nie sprawdzi architektury, a najtrudniejszy może zatrzymać cały projekt. Ustal kolejność grup, warunki rozszerzenia pilota i warunki wycofania. Włączanie platformy powinno być możliwe dla pojedynczej organizacji, a nie tylko globalnie.

W czasie pilota porównuj zamówienia składane na platformie z dotychczasowym procesem, ale nie utrzymuj w nieskończoność podwójnego ręcznego wprowadzania. Tryb równoległy ma służyć walidacji przez określony czas. Każdy ręczny wyjątek zaklasyfikuj: błąd produktu, brakująca reguła, problem z jakością danych albo świadomie ręczna obsługa.

13. Checklista odbioru architektury B2B

Odbiór nie może kończyć się na pokazie scenariusza, w którym wszystko idzie gładko. Każdy punkt wymaga dowodu w postaci testu, raportu, dashboardu, runbooka albo zatwierdzonego dokumentu. Szczególnie dokładnie sprawdź opóźnienia, duplikaty i błędne dane, bo w integracjach zdarzają się na co dzień.

• Każdy kluczowy atrybut ma źródło prawdy, właściciela, listę odbiorców i maksymalne opóźnienie.
• Model organizacji rozdziela osobę, członkostwo, konto w ERP, oddział i adres.
• Backend egzekwuje uprawnienia i izolację tenantów dla każdego obiektu.
• Wzorcowe koszyki dają ceny zgodne z wynikami zatwierdzonymi przez dział handlowy i finanse.
• Przy zamówieniu zapisywana jest kopia ceny, podatku, jednostki i rabatów.
• Dostępność ma jasno określone znaczenie i opisane zachowanie przy opóźnieniu danych.
• Maszyna stanów zamówienia rozdziela status handlowy, płatniczy i realizacyjny.
• Granice odpowiedzialności ERP, PIM, OMS i commerce są spisane jako zakres zadań, a nie tylko lista tabel.
• Każda integracja ma określony model (synchroniczny lub asynchroniczny), limit czasu, ponawianie, DLQ i właściciela.
• Komendy wywołujące skutki są idempotentne, a komunikaty można bezpiecznie przetworzyć ponownie.
• Uzgadnianie danych wykrywa brakujące, zdublowane i niespójne zamówienia oraz kwoty.
• Scenariusze awarii silnika cenowego, ERP, OMS i webhooków zostały przećwiczone.
• Log audytowy obejmuje role, ceny, limity, akceptacje i ręczne korekty.
• Dashboard pokazuje cały przepływ od złożenia zamówienia do ERP i realizacji, powiązany identyfikatorem korelacyjnym.
• Pilot ma określoną grupę klientów oraz kryteria startu, rozszerzenia, wycofania i wygaszenia starego procesu.
• Kolejki wyjątków mają termin obsługi, właściciela i bezpieczną ścieżkę naprawy.