Najważniejsza decyzja przy integracji Subiekt GT i nexo PRO z e-commerce dotyczy modelu wdrożenia: konektor, middleware czy custom. O wyniku projektu decydują mapowanie danych, logika dokumentów i koszt wyjątków po starcie.
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.
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.
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.
Omówmy Twój projekt, kontekst techniczny i możliwe kierunki działania. Krótka rozmowa zwykle wystarcza, żeby ocenić ryzyka, zakres i sensowny następny krok.
Jak zaczynamy
24h
Po wiadomości wracamy z terminem rozmowy i pierwszym spojrzeniem na temat. Powiemy, czy warto budować, integrować, automatyzować czy zacząć prościej.
Jak zaczynamy
24h
Po wiadomości wracamy z terminem rozmowy i pierwszym spojrzeniem na temat. Powiemy, czy warto budować, integrować, automatyzować czy zacząć prościej.
Najstabilniej działa przepływ, w którym sklep lub marketplace wysyła zdarzenie do warstwy integracyjnej, a ta dopiero po walidacji zapisuje dane do ERP. Dzięki temu można zatrzymać rekord z błędnym SKU, niepełnym adresem albo nieobsługiwaną metodą dostawy, zanim powstanie dokument w Subiekcie.
{
"order_id": "EXT-2024-00125",
"channel": "sklep",
"payment_status": "confirmed",
"fulfillment_status": "new",
"items": [
{
"sku": "ABC-001",
"qty": 2,
"price_gross": 129.99
}
],
"delivery_method": "kurier",
"updated_at": "2024-10-12T10:15:00Z"
}Po stronie integracji potrzebne są co najmniej cztery kroki: walidacja danych wejściowych, sprawdzenie idempotencji, mapowanie na model ERP i dopiero potem utworzenie lub aktualizacja rekordu. Jeżeli któryś etap kończy się błędem, rekord powinien trafić do kolejki wyjątków z jasnym komunikatem dla operatora.
Najbardziej użyteczny przepływ jest prosty: kanał sprzedaży przyjmuje zamówienie i wysyła zdarzenie, warstwa integracyjna waliduje dane, zapisuje identyfikator zewnętrzny, sprawdza reguły płatności i dopiero potem tworzy albo aktualizuje rekord w ERP. Następnie ERP odsyła status operacyjny, nie pełną kopię własnej logiki.
Taki układ ogranicza dwa kosztowne błędy. Pierwszy to tworzenie dokumentów zbyt wcześnie. Drugi to próba synchronizacji wszystkiego dwukierunkowo. Ta druga pokusa brzmi ambitnie, ale w praktyce często kończy się konfliktem odpowiedzialności między sklepem a ERP.
Nie każdy obszar powinien być synchronizowany w obie strony. Opisy, zdjęcia i promocje kanałowe rzadko mają sens jako domena ERP. Dokumenty handlowe, rozliczalne stany i dane kontrahenta już tak. Upieranie się przy pełnej synchronizacji dwukierunkowej w małym lub średnim e-commerce to zwykle sygnał, że ktoś sprzedaje efektowną architekturę zamiast porządnego procesu.
Walidacja przed zapisem do ERP powinna obejmować zgodność SKU, kompletność wymaganych pól, poprawność VAT, mapowanie płatności i dostawy oraz sprawdzenie, czy zdarzenie nie zostało już przetworzone. To nie luksus. To filtr, który chroni operację przed codziennym poprawianiem dokumentów.
Dobra integracja nie ukrywa błędów. Odrzuca rekord z jasnym powodem, zapisuje ślad diagnostyczny i pozwala wznowić przetwarzanie po poprawce. Gorszy wariant to częściowy zapis albo ciche pominięcie problemu. Wtedy sklep pokazuje jedno, ERP drugie, a zespół nie wie, gdzie naprawdę powstał błąd.
Z obserwacji takich wdrożeń wynika jeden powtarzalny wzorzec: najbardziej niedoszacowany koszt nie leży w developmentcie. Leży w obsłudze wyjątków po starcie. Jeżeli po wdrożeniu ktoś codziennie poprawia płatności, dokumenty albo stany, integracja nie automatyzuje sprzedaży. Ona tylko przenosi pracę operacyjną do mniej przejrzystego obiegu.
Krótko mówiąc: brak kolejki błędów i sensownych logów to nie drobny brak techniczny. To zaproszenie do ręcznej roboty.
Przy bardziej wymagających wdrożeniach dobrze działa prosty podział odpowiedzialności. Sklep odpowiada za doświadczenie zakupowe i prezentację oferty. Warstwa integracyjna odpowiada za walidację, kolejki, ponowienia i mapowanie. ERP odpowiada za dokumenty, rozrachunki, kartoteki i rozliczalny stan. Gdy te granice są rozmyte, każdy błąd kończy się sporem o to, kto ma go naprawić.
Jeżeli proces ma rosnąć o kolejne kanały albo własne reguły logistyczne, sensownie jest od razu zaprojektować integracje API pod docelowy model operacyjny. To zwykle tańsze niż późniejsze dokładanie kolejek, logów i walidacji do wtyczki, która od początku była za mała.
Bez porządnych logów nie da się utrzymać integracji, nawet jeśli start przebiegł spokojnie. Minimalny zakres to identyfikator zamówienia zewnętrznego, identyfikator rekordu w ERP, typ operacji, wynik walidacji, kod błędu, czas przetworzenia i informacja o ponowieniu. To pozwala odtworzyć ścieżkę zdarzenia bez zgadywania.
Monitoring powinien wychwytywać nie tylko awarie techniczne, ale też błędy biznesowe: brak mapowania płatności, nieznane SKU, nieobsługiwaną metodę dostawy, próbę wystawienia dokumentu dla zamówienia anulowanego. Właśnie te przypadki najczęściej generują ręczną pracę, choć sam serwer działa poprawnie.
Uczciwa wycena nie zaczyna się od pytania o platformę sklepową. Zaczyna się od pytań o kanały sprzedaży, magazyny, typy dokumentów, zwroty, korekty, źródła cen i stanów, zestawy oraz wymagania B2B. Jeżeli dostawca tego nie pyta, to zła wiadomość. Najczęściej sprzedaje standardowy scenariusz, a nie rozwiązanie dla realnego procesu.
Przed startem trzeba uporządkować SKU, warianty, stawki VAT, waluty, jednostki miary, statusy zamówień oraz reguły dla zwrotów, korekt i zestawów. Trzeba też ustalić właściciela błędów integracyjnych. Ktoś musi reagować na odrzucone rekordy, a nie tylko oglądać logi po fakcie.
Dobrym testem oferty jest jedno pytanie: co dokładnie stanie się z zamówieniem, gdy webhook przyjdzie dwa razy, płatność potwierdzi się z opóźnieniem, a jednego SKU zabraknie w kartotece ERP? Jeżeli odpowiedź jest ogólna, wdrożenie prawdopodobnie też będzie ogólne.
Źródła, które realnie pomagają przy projektowaniu takiej integracji, są dość oczywiste: dokumentacje InsERT oraz API kanałów sprzedaży, z których korzystasz. Wystarczy sprawdzić model zdarzeń, webhooki, statusy zamówień i ograniczenia aktualizacji zasobów. To szybko obnaża nierealne założenia po obu stronach.
Zakup warto oprzeć na kilku twardych kryteriach. Jeżeli masz jeden kanał, jeden magazyn i mało wyjątków procesowych, wybierz prosty konektor. Jeżeli dochodzą kolejne kanały, osobne reguły dla zwrotów, różne typy płatności albo więcej niż jeden magazyn, bezpieczniejszy będzie middleware. Gdy proces obejmuje wiele wyjątków, odpowiedzialność za dane jest rozproszona między kilka systemów, a zespół oczekuje własnej logiki dokumentów i stanów, rozsądniejszy zakup to integracja projektowana pod konkretny model operacyjny, a nie kolejna wtyczka z długą listą ograniczeń.
Tu pojawia się niewygodna, ale praktyczna obserwacja: w wielu firmach problemem nie jest brak integracji, tylko brak decyzji, kto jest właścicielem prawdy o zamówieniu, płatności i stanie magazynowym. Dopóki to nie jest ustalone, nawet dobry software będzie tylko szybciej przenosił niespójności między systemami.
Najkrótsze wdrożenia dotyczą jednego kanału sprzedaży, jednego magazynu i prostego obiegu dokumentów. Czas rośnie głównie przez wyjątki procesowe, porządkowanie danych i testy przypadków brzegowych, a nie przez samo połączenie systemów.
Najczęściej wtedy, gdy pojawiają się co najmniej trzy kanały sprzedaży, więcej niż jeden magazyn, zwroty częściowe, zestawy, różne źródła cen lub potrzeba dokładnych logów błędów i ponowień. W takim układzie standardowa wtyczka zwykle nie obejmuje realnego procesu.
Przede wszystkim SKU, warianty, jednostki miary, stawki VAT, waluty, mapowanie płatności i dostaw, statusy zamówień oraz reguły dla zwrotów, korekt i zestawów. Jeśli te elementy są niespójne, integracja tylko szybciej skopiuje problem między systemami.
Nie. W wielu firmach lepiej działa model mieszany: szybki import zamówień i cykliczna publikacja stanów z buforem bezpieczeństwa. Tryb bliski czasu rzeczywistego ma sens tam, gdzie rotacja jest wysoka, a opóźnienie realnie zwiększa ryzyko oversellingu.
Trzeba policzyć liczbę zamówień wymagających interwencji, czas poprawy jednego przypadku, koszt pracy zespołu oraz wpływ błędów na wysyłkę i obsługę klienta. Jeśli operatorzy codziennie poprawiają dokumenty, płatności albo stany, koszt utrzymania jest już za wysoki niezależnie od ceny wdrożenia.
