Integracje (ERP, PIM, WMS, płatności)

Sklep to jeden system, ale biznes działa na kolejnych pięciu: ERP odpowiada za magazyn i księgowość, PIM za dane produktowe, WMS za logistykę, bramka płatności za pieniądze, CRM za marketing. Większość incydentów produkcyjnych zaczyna się właśnie w warstwie, która to wszystko łączy.

Systemy, do których podłączamy

• ERP: SAP Business One, Microsoft Dynamics 365 Business Central, Pohoda, Money S5, Odoo, NetSuite
• PIM: Akeneo, Pimcore, Plytix, a czasem wewnętrzne arkusze kalkulacyjne pełniące rolę PIM
• WMS / 3PL / logistyka: Zásilkovna, Packeta, GLS, DPD, FedEx, wewnętrzne systemy magazynowe
• Płatności: Stripe, GoPay, ComGate, PayU, Adyen, Mollie, razem z warstwami fraud detection i recurring billingu
• CRM / marketing: HubSpot, Klaviyo, Mailchimp, Salesforce
• Analityka / dane: BigQuery, Snowflake, Segment, GA4

Jak je budujemy

• Idempotentnie. Każdy webhook może przyjść dwa razy bez żadnych konsekwencji, bo systemy produkcyjne ponawiają żądania i integracja musi to obsłużyć.
• Obserwowalnie. Każde wywołanie między systemami trafia do logów z correlation ID. Kiedy zamówienie nie doszło do WMS, od razu widać, gdzie utknęło.
• Odpornie. Integracja ma przeżyć awarię po drugiej stronie: dead-letter queues, exponential backoff, narzędzia do ręcznego replayu.
• Z wersjonowanymi kontraktami. Kontrakt API leży w repo, więc łamiącą zmianę schematu u dostawcy widać przy deployu, a nie dopiero na produkcji.
• Z testami: contract tests na nagranych odpowiedziach i smoke testy na sandboxie przy każdym deployu.

Skąd się wzięły te zasady

Nic z powyższego nie jest teorią. Każda z tych zasad wynika z konkretnego incydentu w sklepie, przy którym pracowaliśmy:

• Synchronizacja statusów nie działała tygodniami, ani razu nie zgłaszając błędu: ERP wysyłał 300 000 statusów zamówień, które nigdy nie istniały w sklepie, przez co budżet błędów narzędzia importującego się wyczerpywał i każde uruchomienie kończyło się przedwcześnie, przed właściwymi danymi, bez żadnego komunikatu. Stąd zasada: budżety błędów się monitoruje, a nie tylko konfiguruje.
• Świeżo wdrożona synchronizacja zamówień nadpisała pola należące do konektora marketplace’ów i wysyłki z całego dnia nigdy do marketplace’ów nie dotarły. Od tamtej pory każda synchronizowana kolumna ma dokładnie jednego zadeklarowanego właściciela, a synchronizacja nie dotyka cudzych wierszy.
• Procedura składowana w ERP rzucała wyjątkami SQL, zwracając przy tym „sukces”. Wyszło to przy odtworzeniu 1 300 prawdziwych zamówień na integracji jeszcze przed startem; taka próba generalna jest dziś u nas standardem dla przepływów krytycznych dla zamówień.
• Wadliwy feed próbował kiedyś usunąć dziesiątki tysięcy produktów w jednym przebiegu. Progi na usunięcia z circuit breakerem są od tamtej pory częścią każdej synchronizacji katalogu, którą budujemy.
• Płatności przestały się parować z zamówieniami, bo firewall dostawcy hostingu blokował webhooki bramki płatności. Rozwiązaniem była whitelista; jej znalezienie wymagało analizy logów HTTP, do których nikt wcześniej nie zajrzał.

B2B e-commerce

B2B rządzi się innymi zasadami niż DTC: kupują pracownicy firm, ceny wynikają z umów, a zamówienia przechodzą przez akceptację. Tę warstwę też budujemy: konta firmowe z rolami i hierarchiami, katalogi i ceny kontraktowe per klient, workflow quote-to-order, warunki płatności (net 30/60/90, limity kredytowe, integracja fakturowania z ERP) oraz integrację zakupową: punchout (OCI, cXML, Ariba) i EDI dla klientów, którzy nadal wysyłają komunikaty 850.

Jak zwykle zaczyna się współpraca

Zakres pracy integracyjnej wyznacza konkretny, obserwowany problem: zamówienie, które nigdy nie dotarło do WMS, stan magazynowy, który co noc traci spójność, CSV, który ktoś co rano przepisuje ręcznie. Mapujemy ten przepływ od końca do końca, zakres i stałą cenę otrzymujesz na piśmie, a zamiennik budujemy tak, aby następna awaria była od razu widoczna w monitoringu, a nie po kilku dniach. Stała opieka, razem z monitoringiem, może zostać u nas na miesięcznym retainerze.