Ceny i stany dla partnerów B2B przez API
Scenariusz modelowy: partnerzy handlowi pobierają aktualny katalog, ceny i dostępność do własnych systemów, zamiast prosić handlowca o plik.
Zastrzeżenie
To scenariusz modelowy, nie case study konkretnego klienta. Opisuje architekturę i decyzje, które wracają w tego typu projektach. Nie zawiera nazw firm ani wyników przypisanych komukolwiek.
Punkt wyjścia
- każdy partner odbiera dane w innym formacie - inny ERP, inny sklep, inny plik
- ceny i stany wysyłane Excelem, więc są nieaktualne w momencie otwarcia pliku
- handlowcy zamiast sprzedawać odpowiadają na powtarzalne pytania o dostępność
- onboarding nowego partnera trwa tygodniami, bo za każdym razem robiony od zera
Model docelowy
- jeden model danych po stronie producenta, wiele formatów wyjściowych do partnerów
- partner pobiera katalog, ceny i stany do swojego systemu automatycznie
- indywidualne warunki handlowe wyliczane zgodnie z regułami z ERP, nie ręcznie
- kolejny partner to konfiguracja istniejącego kanału, nie nowy projekt
Punkt wyjścia
Partnerzy pracują w różnych systemach: Comarch, Subiekt, własny sklep, u części tylko poczta. Ceny i stany jadą do nich Excelem raz na jakiś czas. Partner sprzedaje z danych sprzed kilku dni, a różnicę ktoś prostuje ręcznie.
Opis dotyczy architektury, nie wdrożenia u konkretnego klienta.
Model rozwiązania
Jeden standard danych po stronie producenta: produkty, ceny, dostępność, warunki handlowe. Na wyjściu te same dane w formacie, który dany partner przyjmie - REST API, feed do pobrania, plik o uzgodnionej strukturze, EDI albo integracja wprost z jego systemem.
Rozdzielenie tych dwóch warstw decyduje o koszcie kolejnych partnerów. Gdy format wyjściowy jest wpisany w źródło, każdy nowy partner to nowy projekt integracyjny. Gdy jest osobno - konfiguracja istniejącego kanału.
Cztery ustalenia przed startem
Zakres pierwszego etapu. Zwykle produkty i ceny dla dwóch największych partnerów. Wystarczy, żeby potwierdzić model, i nie blokuje bieżącej sprzedaży.
Reguły cen indywidualnych. Czy partner dostaje cenę wyliczoną z rabatu, czy własny cennik kontraktowy. Przy cenie wyliczanej trzeba wskazać, gdzie liczy się rabat - po stronie producenta czy partnera.
Autoryzacja i zakres danych. Który partner widzi które produkty i które ceny. To reguła biznesowa; musi być zapisana, zanim powstanie API, bo wpływa na jego kształt.
Audit log. Kto pobrał jakie dane i kiedy. Przy sporze o cenę to jedyny dowód - szerzej w tekście o audit logu w wymianie danych B2B.
Kiedy wystarczy mniej
Przy kilku partnerach na jednym systemie wystarczy gotowa integracja albo feed. Osobna warstwa wymiany danych zaczyna się opłacać, gdy partnerów przybywa i każdy pracuje na czymś innym.
Podobny problem u Ciebie?
Opisz, jak dziś przepływają dane między Twoimi systemami. Odpowiemy, czy wystarczy konfiguracja, gotowa wtyczka, czy potrzebna jest dedykowana integracja.