Integracja Subiekt GT i nexo PRO z e-commerce nie sprowadza się do zakupu wtyczki. Najpierw trzeba rozstrzygnąć, który system odpowiada za dane, dokumenty i status operacyjny. Bez tej decyzji nawet poprawnie działający konektor zaczyna produkować ręczne korekty. Zwykle nie przegrywa samo połączenie systemów, tylko zbyt wygodne założenie, że standardowa integracja przykryje bałagan w statusach, płatnościach i kartotekach.
Subiekt GT i nexo PRO można spiąć ze sklepem, marketplace i kanałem B2B, ale koszt utrzymania takiego układu potrafi się mocno rozjechać. GT częściej pracuje w środowisku pełnym historycznych wyjątków, dodatków i ręcznych obejść. nexo PRO zwykle lepiej znosi porządkowanie procesu, ale nie naprawi niespójnych danych ani źle rozpisanej logiki między sklepem a ERP.
Właśnie tu firmy przepłacają. Kupują tanią integrację, która poprawnie importuje zamówienia, a potem wychodzi, że płatności, zwroty, korekty i dokumenty trzeba prostować ręcznie. Przy większej liczbie kanałów sprzedaży gotowy konektor bywa tańszy tylko na starcie, ale to zależy od liczby wyjątków, skali zwrotów, liczby magazynów, sposobu rozliczania płatności i jakości danych w ERP oraz sklepie. Jeżeli te elementy są niestabilne, koszt wraca później w operacji.
Jak wybrać model integracji bez kosztownej pomyłki
Nie potrzeba rozbudowanej macierzy. Wystarczą trzy kryteria: liczba kanałów, liczba magazynów i liczba wyjątków procesowych. Wyjątki nie są detalem. To zwroty częściowe, zestawy, różne reguły rezerwacji, odroczone płatności, osobne cenniki B2B albo publikacja stanów według innych zasad niż stan fizyczny.
Gotowy konektor ma sens wtedy, gdy układ jest prosty: jeden sklep, jeden magazyn, standardowe dokumenty, mało ręcznych decyzji. Zamówienie wpada, mapowanie jest przewidywalne, a zespół nie potrzebuje rozbudowanych logów ani kolejek ponowień. W takim scenariuszu dokładanie cięższej architektury jest zwykłym przerostem formy.
Middleware zaczyna mieć sens, gdy pojawiają się 2-4 kanały, więcej niż jeden magazyn albo potrzeba walidacji przed zapisem do ERP. To nie moda architektoniczna. To sposób na oddzielenie kolejek, logiki błędów, idempotencji i mapowania od sklepu oraz od samego Subiekta.
Integracja custom jest uzasadniona wtedy, gdy proces sprzedaży nie mieści się w standardzie: indywidualne cenniki B2B, kilka źródeł stanów, zestawy rozbijane na komponenty, integracja z WMS, własne reguły kompletacji albo wymagania bliskie czasu rzeczywistego dla wybranych SKU.
Granica jest bardziej konkretna, niż wielu dostawców chce przyznać. Jeżeli masz kilka kanałów sprzedaży, więcej niż jeden magazyn i osobne reguły dla zwrotów lub rezerwacji, ryzyko niedopasowania gotowej wtyczki wyraźnie rośnie. Demo nadal wygląda dobrze, bo zamówienia wpadają. Problem wychodzi później: statusy nie znaczą tego samego, dokumenty powstają za wcześnie, a operatorzy zaczynają żyć w wyjątkach.
Prosty model oceny złożoności wygląda tak:
| Poziom | Kiedy występuje | Najczęściej trafiony wybór |
|---|---|---|
| Niski | 1 kanał, 1 magazyn, prosty katalog, standardowe dokumenty | Konektor |
| Średni | 2-4 kanały, zwroty częściowe, różne płatności, potrzeba logów błędów | Middleware |
| Wysoki | B2B, wiele magazynów, zestawy, różne źródła cen lub stanów, logistyka zewnętrzna | Custom lub mocne middleware |
Najgorszy zakup to nie najdroższa integracja. Najgorszy zakup to rozwiązanie za małe do procesu, który już dziś jest złożony. Potem każda zmiana kosztuje podwójnie, bo utrzymujesz wyjątki zamiast spójnej architektury.
W hurtowni technicznej obsługującej sklep, Allegro i kanał B2B przy rozbudowanym katalogu największym problemem nie był sam import zamówień, tylko ręczne prostowanie wyjątków po starcie: brakujące mapowania dostaw, rozjazdy statusów płatności i dokumenty tworzone za wcześnie. To właśnie taki rodzaj tarcia podnosi koszt wdrożenia bardziej niż samo połączenie systemów.
Jeżeli układ ma objąć także logistykę i sprzedaż wielokanałową, pomocne będzie spojrzenie na integrację ERP, WMS i marketplace. Wtedy szybciej widać, czy obecny model danych wytrzyma rozwój.
Mapowanie danych i przepływ zamówień: tu wdrożenia pękają
Najwięcej problemów nie bierze się z braku połączenia, tylko z błędnego mapowania. Zamówienie ze sklepu nie jest jeszcze dokumentem handlowym w ERP. Status „opłacone” nie zawsze oznacza gotowość do wystawienia dokumentu. SKU w sklepie nie musi odpowiadać kartotece jeden do jednego. Jeżeli te różnice nie są rozpisane przed startem, integracja zaczyna produkować błędy od pierwszego dnia.
Pierwsza decyzja dotyczy momentu zapisu do ERP. W praktyce działają trzy modele: zapis każdego zamówienia od razu, zapis do bufora i utworzenie dokumentu po potwierdzeniu płatności albo zapis do bufora z dodatkową walidacją danych i stanów. Dla prostego sklepu pierwszy wariant bywa wystarczający. Przy marketplace i płatnościach asynchronicznych bezpieczniejszy jest bufor.
To nie jest przesadna ostrożność. Dokumentacje Allegro API, Shopify i WooCommerce pokazują model zdarzeniowy, w którym webhook może przyjść ponownie, status może zmienić się z opóźnieniem, a kolejność zdarzeń nie zawsze będzie idealna. Bez idempotencji, czyli odporności na wielokrotne przetworzenie tego samego zdarzenia, łatwo o podwójne dokumenty albo błędne aktualizacje.
Minimalny zestaw danych do sensownego mapowania obejmuje identyfikator zamówienia zewnętrznego, identyfikator klienta, SKU, ilości, ceny według jednego modelu netto albo brutto, stawki VAT, walutę, formę płatności, metodę dostawy, koszt dostawy, źródło kanału i znacznik czasu aktualizacji. Bez tego nie odtworzysz błędu ani nie zbudujesz bezpiecznych ponowień.
Statusów nie warto kopiować jeden do jednego. Lepiej zbudować kilka stanów biznesowych, które mają znaczenie operacyjne: przyjęte, opłacone, gotowe do realizacji, wydane, wysłane, anulowane. Każdy stan powinien mieć jasny warunek przejścia. Inaczej sklep i ERP zaczynają mówić różnymi językami o tym samym zamówieniu.
Źle zmapowane statusy powodują bardzo konkretne skutki operacyjne: dokument sprzedaży może powstać przed faktycznym potwierdzeniem płatności, korekta może zostać wystawiona do niewłaściwego etapu realizacji, a sklep i ERP zaczynają pokazywać różne informacje o tym samym zamówieniu. Wtedy zespół wraca do ręcznych poprawek, a automatyzacja przestaje być przewidywalna.
Płatności wymagają osobnej logiki. Płatność online, pobranie i sprzedaż B2B z terminem płatności nie mogą uruchamiać tych samych akcji. Jeżeli dokument sprzedaży powstaje wyłącznie po zmianie statusu w sklepie, a operator płatności potwierdzi transakcję później, rozjazd jest niemal pewny.
Stany magazynowe też trzeba rozdzielić. W e-commerce liczy się stan fizyczny, stan dostępny i stan publikowany. Wrzucanie do kanału sprzedaży czystego stanu fizycznego to prosty przepis na overselling. Lepszy jest stan sprzedażowy po uwzględnieniu rezerwacji i bufora bezpieczeństwa.
Zwrot i korekta to osobne zdarzenia biznesowe. Zwrot wpływa na magazyn i płatność. Korekta wpływa na dokument handlowy i rozliczenie. Integracja, która miesza te dwa światy, zwykle kończy jako półautomatyczny system do generowania pracy ręcznej.
