Gdy sklep i Subiekt przestają mówić tym samym językiem
Wzrost liczby zamówień w sklepie internetowym cieszy każdego właściciela e-commerce, ale szybko ujawnia wąskie gardła w operacyjnej części biznesu. W pewnym momencie ręczna obsługa sprzedaży przestaje być wykonalna. Przenoszenie danych między platformą sklepową a systemem ERP – takim jak Subiekt GT lub Subiekt nexo – staje się źródłem ciągłych pomyłek, które bezpośrednio uderzają w marżę i zaufanie klientów.
Objawy, które szybko obciążają obsługę sprzedaży
Najbardziej zauważalnym symptomem braku sprawnej automatyzacji jest czas, jaki zespół spędza na powtarzalnych czynnościach. Ręczne przepisywanie danych klienta, danych do faktury, wybór formy płatności i dostawy oraz wystawianie paragonów lub faktur w Subiekcie generuje stały, wysoki koszt roboczogodzin. Zamiast zajmować się pakowaniem paczek lub obsługą zapytań klientów, pracownicy stają się łącznikami przenoszącymi formularze z jednego ekranu na drugi.
Drugim krytycznym problemem są rozbieżności stanów magazynowych. Towar sprzedany na platformie e-commerce może w tym samym czasie zostać wydany w sklepie stacjonarnym albo zarezerwowany przez dział handlowy obsługujący klientów B2B. Jeśli aktualizacja ilości w sklepie odbywa się ręcznie raz dziennie lub z kilkugodzinnym opóźnieniem, pojawia się zjawisko oversellingu – przyjmowania wpłat za produkty, których fizycznie nie ma na półce.
Do tego dochodzą błędy w cennikach i parametrach zamówień. Klient kupuje produkt po cenie promocyjnej w sklepie, jednak w systemie Subiekt pobiera się cena domyślna, co wymusza ręczną korektę dokumentów. Pojawiają się rozbieżności w kosztach dostawy, nieuwzględnione rabaty koszykowe czy niewłaściwie zmapowane warianty towarów. Każdy taki błąd generuje pożary w dziale obsługi: odwołane zamówienia, telefony od niezadowolonych kupujących oraz czasochłonne procedury zwrotu środków.
W efekcie pracownicy przestają ufać automatom i zaczynają ręcznie weryfikować każde wpłynięcie zamówienia w obu systemach. Taki stan całkowicie przekreśla sens inwestowania w nowoczesną platformę sprzedażową.
Problem nie zawsze leży po stronie sklepu
Gdy dochodzi do błędów synchronizacji, naturalną reakcją jest obwinianie wtyczki sklepowej lub samej platformy (np. WooCommerce czy PrestaShop). W praktyce jednak architektura systemów ERP z rodziny InsERT rządzi się własną, sztywną logiką, która bywa fundamentalnie odmienna od sposobu przetwarzania danych w e-commerce.
Subiekt GT
Subiekt GT i Subiekt nexo są systemami, w których dane handlowe nie są jedynie prostymi rekordami do skopiowania. Dokument sprzedaży może uruchamiać rezerwacje, rozchód magazynowy, naliczanie rabatów, dobór cen, powiązania z kontrahentem czy mechanizmy księgowe. Sklep natomiast pracuje głównie na statusach zamówienia, koszyku, płatności i wysyłce. Integracja musi więc nie tylko przesłać dane, ale też poprawnie przełożyć znaczenie każdego z nich na reguły obowiązujące po drugiej stronie. [1]
Różnice są widoczne choćby przy stanach magazynowych. Sklep może pokazywać dostępność produktu, podczas gdy Subiekt rozróżnia stan fizyczny, towar zarezerwowany, zamówiony u dostawcy lub dostępny w konkretnym magazynie. Bez jasnej reguły łatwo wyświetlić klientowi ilość, której firma realnie nie może już sprzedać. Podobnie wygląda kwestia cen: jedna karta towaru w ERP może mieć kilka poziomów cenowych, indywidualne rabaty kontrahenta albo ceny zależne od magazynu, a sklep oczekuje jednej konkretnej kwoty dla danego wariantu produktu. [5]
Źródło: Pexels | Autor: Jakub Zerdzicki
Niepokój przed integracją jest zrozumiały, zwłaszcza gdy sprzedaż już trwa i każda pomyłka oznacza ręczne sprzątanie dokumentów. Nie oznacza to jednak, że projekt musi być skomplikowany. Najpierw dobrze jest ustalić, które dane mają być źródłowe w Subiekcie, które w sklepie, a które wymagają kontroli po obu stronach. Przykładowo karta towaru, cena bazowa i stan mogą pochodzić z ERP, natomiast adres dostawy, uwagi klienta oraz wybrany paczkomat ze sklepu. [4]
Dopiero po takim uporządkowaniu procesów da się uczciwie ocenić, czy wystarczy gotowy konektor, czy potrzebny będzie moduł uwzględniający nietypowe zasady firmy. Dobrze dobrana integracja nie ma jedynie „przesyłać zamówień” – ma zdejmować z zespołu powtarzalną pracę, a jednocześnie pozostawiać kontrolę tam, gdzie automatyzacja mogłaby stworzyć kosztowny błąd.
Większość uniwersalnych wtyczek integracyjnych projektowana jest z myślą o najprostszym scenariuszu: produkt ma jeden kod SKU, jedną cenę, sprzedawany jest klientowi indywidualnemu z jednego magazynu, a zamówienie zamienia się w prosty paragon lub fakturę. Gdy rzeczywistość firmy wykracza poza ten schemat, standardowe narzędzie zaczyna generować ciche błędy – takie, które ujawniają się dopiero przy bilansowaniu miesiąca lub podczas audytu magazynowego.
Ograniczenia architektoniczne i przekłamania w mapowaniu danych
Głównym powodem problemów jest fakt, że uniwersalne konektory próbują spłaszczyć złożoną strukturę bazodanową Subiekta do uproszczonego modelu danych sklepu internetowego. Systemy z rodziny InsERT (szczególnie przy wykorzystaniu dodatków sferycznych) wymagają bardzo precyzyjnego wykonywania operacji. Jeśli konektor nie potrafi prawidłowo obsłużyć mechanizmów systemowych, pojawiają się wąskie gardła:
Magazyny i filie: Subiekt GT i Subiekt nexo doskonale radzą sobie z obsługą wielu magazynów (np. magazyn główny, magazyn wysyłkowy, salon stacjonarny, magazyn zwrotów). Standardowa wtyczka często potrafi pobierać stan tylko z jednego wskazanego magazynu lub sumuje je w sposób, który prowadzi do wystawiania dokumentów na braki magazynowe.
NIP, kontrahenci i rozrachunki: Tworzenie kartoteki kontrahenta przy każdym zamówieniu potrafi w krótkim czasie zanieczyścić bazę ERP tysiącami dubli. Z kolei próba przypisywania wszystkich zamówień do jednego „klienta detalicznego” uniemożliwia późniejszą analitykę, prawidłowe zarządzanie rozrachunkami czy obsługę transakcji B2B i procedur podatkowych (np. VAT OSS przy sprzedaży zagranicznej).
Pola własne i cechy towarów: Firma może wykorzystywać pola własne w Subiekcie do zarządzania lokalizacją półkową, gabarytem przesyłki czy dostawcą. Zwykły konektor zazwyczaj nie przesyła tych danych do sklepu (lub ze sklepu do ERP), co zmusza magazynierów do ręcznego przepisywania kluczowych informacji.
Niewydolność połączeń i ograniczenia kolejkowania
Drugą przyczyną awarii są kwestie wydajnościowe. Standardowe wtyczki często opierają się na prostym cyklicznym zapytaniu (tzw. polling), uruchamianym przez harmonogram zadań co określony czas (np. co 15 minut). W trakcie wyprzedaży lub pików sprzedażowych, gdy w ciągu minuty spływa kilkadziesiąt zamówień, mechanizm ten przestaje nadążać.
Jeśli wtyczka nie posiada bufora oraz mechanizmu kolejkowania z obsługą błędów, zakleszczenie bazy danych SQL lub chwilowa przerwa w dostępie do Sfery GT/nexo SDK może spowodować całkowicie pominięcie zamówienia. W efekcie klient otrzymuje potwierdzenie ze sklepu, ale w Subiekcie nie powstaje żaden dokument – ani ZK (Zlecenie Kancelaryjne / Zamówienie od Klienta), ani dokument sprzedaży. Problem ujawnia się dopiero wtedy, gdy klient pyta o status braku przesyłki. [3]
Gotowy konektor do Subiekta – kiedy rozwiązuje problem wystarczająco dobrze
Mimo wskazanych ograniczeń, gotowe (pudełkowe) konektory integracyjne są najpopularniejszym wyborem na rynku – i w wielu przypadkach jest to decyzja w pełni uzasadniona biznesowo. Kluczem do sukcesu nie jest szukanie idealnego oprogramowania, ale obiektywna ocena, czy procesy w firmie są na tyle standardowe, by zmieścić się w ramach narzuconych przez twórcę integracji.
Kiedy wybór gotowego konektora ma sens?
Pudełkowe rozwiązanie sprawdzi się doskonale, jeśli model operacyjny e-commerce spełnia następujące kryteria:
Model B2C o prostej strukturze: Sprzedaż kierowana jest do osób fizycznych, obsługa transakcji opiera się na standardowych dokumentach (paragon imienny, faktura VAT), a firma korzysta z jednego cennika bazowego.
Jednolita gospodarka magazynowa: Sprzedaż internetowa odbywa się z jednego, wyznaczonego magazynu fizycznego, a stany nie wymagają skomplikowanych przeliczeń ani rezerwacji wielopoziomowych.
Standardowy przepływ dokumentów: Wpływające zamówienie ma tworzyć w Subiekcie dokument ZK z automatyczną rezerwacją zasobów, a po opłaceniu lub wysłaniu – przekształcać się w fakturę (FS) lub paragon (PA/PAi).
Gotowość do dostosowania procesów do narzędzia: Właściciel biznesu woli zmienić wewnętrzną procedurę pakowania lub księgowania tak, aby odpowiadała możliwościom wtyczki, zamiast płacić
za indywidualne prace programistyczne.
Główną zaletą gotowych wtyczek jest krótki czas wdrożenia oraz relatywnie niski koszt początkowy. Zamiast czekać miesiącami na realizację projektu programistycznego, firma może uruchomić podstawową synchronizację w ciągu kilku dni. Kluczem do sukcesu jest jednak pełna akceptacja faktu, że to biznes musi dopasować się do możliwości narzędzia, a nie odwrotnie.
Dedykowany moduł integracyjny – dla procesów, których nie da się wtłoczyć w schemat
Gdy skala sprzedaży rośnie, a model biznesowy zaczyna wykraczać poza proste wydanie towaru z jednego magazynu, ograniczenia gotowych konektorów stają się bezpośrednią barierą w rozwoju firmy. Dedykowany moduł integracyjny nie jest po prostu „droższą wtyczką” – to indywidualnie zaprojektowana warstwa pośrednicząca, która odwzorowuje unikalne
procesy firmy. Może uwzględniać nietypowe statusy, dodatkowe źródła danych, zasady rezerwacji oraz kolejność wykonywania operacji, której nie przewidział producent uniwersalnej wtyczki.
Co daje rozwiązanie projektowane pod konkretną firmę
Dedykowana integracja pozwala zdefiniować przepływ danych zamiast przyjmować gotowy, często zbyt uproszczony scenariusz. Nie chodzi przy tym o programowanie dla samego programowania. Celem jest obsłużenie tych punktów procesu, w których ręczna praca, pomyłka lub opóźnienie faktycznie kosztują firmę czas i pieniądze.
Przykładem może być sklep prowadzący sprzedaż z kilku lokalizacji. Zamówienie złożone przez klienta może zostać skierowane do magazynu, w którym towar jest fizycznie dostępny i z którego da się najszybciej nadać paczkę. Jeśli część produktów wymaga kompletacji, a pozostałe mogą wyjechać od razu, moduł może przekazać do ERP odpowiednią informację lub utworzyć dokumenty zgodnie z ustaloną logiką. Gotowy konektor zwykle widzi wyłącznie stan i zamówienie. Dedykowana warstwa może uwzględnić również reguły operacyjne stojące za tymi danymi.
Takie rozwiązanie przydaje się szczególnie wtedy, gdy firma:
łączy kilka kanałów sprzedaży – sklep internetowy, marketplace, sprzedaż telefoniczną, punkty stacjonarne lub platformę B2B;
korzysta z wielu magazynów i potrzebuje osobnych reguł dostępności, przesunięć międzymagazynowych albo obsługi zwrotów;
obsługuje klientów B2B i B2C z różnymi cennikami, progami rabatowymi, formami płatności i sposobem wystawiania dokumentów;
sprzedaje towary z wariantami lub kompletami, których mapowanie do kartotek ERP wymaga dodatkowych reguł;
potrzebuje przekazywać dane niestandardowe, takie jak numer punktu odbioru, termin realizacji, oznaczenie źródła zamówienia, cechy towaru czy informacje dla magazynu;
ma własny obieg dokumentów, na przykład tworzy najpierw zamówienie, następnie rezerwację, a dokument sprzedaży wystawia dopiero po konkretnym zdarzeniu logistycznym lub płatniczym.
Ważna różnica dotyczy także obsługi wyjątków. W każdym sklepie pojawiają się anulacje, częściowe zwroty, korekty adresu po złożeniu zamówienia, brak jednego produktu albo płatność zaksięgowana po czasie. Dobrze zaprojektowany moduł nie zakłada, że każde zamówienie przejdzie idealnie od początku do końca. Powinien rozpoznawać sytuacje nietypowe, zatrzymać automatyzację tam, gdzie potrzebna jest decyzja człowieka, i jasno wskazać powód problemu.
Źródło: Pexels | Autor: Daniil Komov
Kontrola, kolejki i możliwość ponowienia operacji
Przy większej liczbie zamówień sama wymiana danych to za mało. Potrzebna jest widoczność procesu: informacja, które zamówienie zostało przekazane, które utworzyło dokument w Subiekcie, które czeka na ponowną próbę, a które wymaga ręcznej interwencji.
Dedykowany moduł może korzystać z kolejki zdarzeń, dzięki której chwilowy brak połączenia z bazą, serwerem sklepu albo usługą pośredniczącą nie powoduje zgubienia zamówienia. Operacja trafia do kolejki, zostaje oznaczona i może zostać ponowiona po usunięciu przyczyny błędu. Istotne jest przy tym zabezpieczenie przed duplikatami. Ponowne wysłanie żądania nie powinno tworzyć drugiego dokumentu sprzedaży ani drugiej rezerwacji dla tego samego zakupu.
To właśnie w takich szczegółach kryje się przewaga integracji budowanej pod proces. Pracownik nie musi codziennie porównywać listy zamówień ze sklepem „na wszelki wypadek”. Zamiast tego dostaje listę konkretnych wyjątków: brak dopasowania SKU, nieznany kontrahent, produkt niedostępny w wybranym magazynie czy błąd wystawienia dokumentu. Automatyzacja pozostaje pod kontrolą, ale nie zamienia zespołu w operatorów dwóch ekranów.
Dedykowany moduł wymaga uporządkowania procesów
Indywidualne rozwiązanie nie jest jednak automatyczną odpowiedzią na każdy problem. Jeżeli w firmie nie ma ustalonej reguły, z którego magazynu realizowane są zamówienia albo kiedy dokładnie ma powstawać faktura, programista nie powinien zgadywać. Integracja może odwzorować proces, ale nie zastąpi decyzji biznesowej.
Przed rozpoczęciem prac dobrze jest rozpisać kilka rzeczy w prosty, operacyjny sposób: kto zarządza kartoteką towarową, które statusy zamówienia uruchamiają kolejne czynności, jak obsługiwane są anulacje, gdzie mają trafiać zwroty oraz kto odpowiada za poprawę błędnych danych. Nie trzeba tworzyć rozbudowanej dokumentacji korporacyjnej. Często wystarczą przejrzyste scenariusze oparte na realnych zamówieniach.
Przykładowo zamówienie opłacone online może mieć inną ścieżkę niż pobranie. Pierwsze można przekazać do realizacji od razu, drugie wymagać dodatkowego oznaczenia w ERP. Jeśli firma chce rozdzielać te przypadki, reguła powinna być jednoznaczna przed wdrożeniem. Dzięki temu później nie trzeba poprawiać mechanizmu, który technicznie działa prawidłowo, ale realizuje nie to, czego oczekuje dział obsługi.
Jak porównać konektor i dedykowaną integrację przed podjęciem decyzji
Wybór nie powinien opierać się wyłącznie na cenie licencji lub koszcie stworzenia modułu. Tańszy start może okazać się droższy, jeśli pracownicy codziennie poprawiają dokumenty, a firma traci zamówienia przez błędne stany. Z drugiej strony rozbudowany projekt dedykowany nie ma uzasadnienia, gdy sprzedaż przebiega według prostego i stabilnego schematu.
Najbezpieczniej porównać oba warianty na podstawie rzeczywistych przypadków, a nie deklaracji typu „synchronizacja zamówień i stanów”. Takie hasło może oznaczać zupełnie co innego dla sklepu z jedną grupą produktów, a co innego dla firmy obsługującej kilka magazynów i klientów biznesowych.
Pytania, które odsłaniają rzeczywistą złożoność
Przed decyzją dobrze jest przejść przez codzienny przepływ pracy i odpowiedzieć na kilka konkretnych pytań:
Jaki system jest źródłem prawdy dla towarów, cen i stanów magazynowych?
Czy wszystkie produkty mają jednoznaczne identyfikatory, które można bezpiecznie mapować między sklepem a Subiektem?
Z ilu magazynów realizowana jest sprzedaż i czy dostępność w sklepie ma uwzględniać rezerwacje?
Jakie dokumenty powinny powstawać w ERP po złożeniu, opłaceniu, wysłaniu i anulowaniu zamówienia?
Czy różne grupy klientów mają inne ceny, formy płatności, terminy lub dane wymagane na dokumentach?
Jak mają być obsługiwane promocje koszykowe, kody rabatowe, gratisy, zestawy i koszty dostawy?
Co ma się wydarzyć, gdy zamówienie zawiera produkt niedostępny, błędnie zmapowany albo wycofany ze sprzedaży?
Czy zespół potrzebuje raportu błędów i możliwości bezpiecznego ponowienia synchronizacji?
Nie tylko koszt wdrożenia, ale koszt obsługi po starcie
Przy porównaniu ofert dobrze policzyć również pracę, która zostanie po stronie zespołu po uruchomieniu integracji. Jeśli konektor nie obsługuje części scenariuszy, ktoś będzie musiał ręcznie poprawiać dokumenty, zmieniać magazyny lub wyjaśniać rozbieżności stanów. Przy kilku wyjątkach tygodniowo może to być akceptowalne. Gdy wyjątków przybywa wraz ze sprzedażą, pozorna oszczędność szybko przestaje nią być.
Nie trzeba też od razu budować rozbudowanego modułu obejmującego każdy możliwy proces. Rozsądnym podejściem bywa wdrożenie najważniejszych reguł, na przykład poprawnego tworzenia dokumentów, rezerwacji i obsługi błędów, a następnie rozwijanie integracji wraz z potrzebami firmy. Taki etapowy model ogranicza ryzyko i pozwala sprawdzić, czy przyjęte zasady rzeczywiście działają w codziennej pracy.
Gotowy konektor będzie dobrym wyborem, gdy proces sprzedaży jest prosty, dane są uporządkowane, a firma akceptuje standardowy sposób działania narzędzia. Dedykowany moduł ma sens tam, gdzie integracja ma wspierać własne reguły sprzedaży, logistyki i dokumentowania, a nie wymuszać ich zmianę. Najlepsze rozwiązanie to niekoniecznie najbardziej rozbudowane, lecz takie, które bezpiecznie przenosi dane między sklepem a Subiektem GT lub Nexo i nie dokłada zespołowi codziennej pracy. [2]
Najczęściej zadawane pytania (FAQ)
Kiedy gotowy konektor do Subiekta może wystarczyć?
Gotowy konektor może być odpowiedni przy prostym modelu B2C, jednym magazynie, jednym cenniku i standardowym obiegu dokumentów, takim jak ZK, FS lub PA.
Kiedy warto rozważyć dedykowany moduł integracyjny?
Dedykowany moduł warto rozważyć wtedy, gdy firma korzysta z wielu magazynów, niestandardowych cenników, pól własnych, rozbudowanych reguł rezerwacji lub obsługuje procesy B2B.
Jakie dane należy ustalić przed wdrożeniem integracji?
Trzeba określić, które dane są źródłowe w Subiekcie, które w sklepie, a które wymagają kontroli po obu stronach. Dotyczy to między innymi kartotek towarów, cen, stanów, danych klienta i dostawy.
Dlaczego stany magazynowe mogą być niezgodne?
Sklep i Subiekt mogą inaczej interpretować stan fizyczny, rezerwacje, dostawy oraz dostępność w konkretnym magazynie. Bez jasno ustalonej reguły synchronizacji łatwo o overselling.
Co może się stać, gdy integracja nie obsługuje kolejkowania?
Przy dużej liczbie zamówień lub chwilowym błędzie połączenia zamówienie może nie zostać przekazane do Subiekta. Dlatego warto sprawdzić, czy rozwiązanie ma bufor, obsługę błędów i możliwość ponowienia operacji.
Kluczowe Wnioski
Gotowy konektor sprawdzi się przede wszystkim przy prostym modelu sprzedaży, jednym magazynie i standardowym obiegu dokumentów.
Dedykowany moduł jest uzasadniony, gdy integracja musi obsługiwać wiele magazynów, różne cenniki, kontrahentów B2B, pola własne lub niestandardowe reguły.
Przed wyborem rozwiązania trzeba ustalić, który system jest źródłem poszczególnych danych oraz jak mają działać rezerwacje i synchronizacja stanów.
Istotne są nie tylko zakres funkcji, lecz także wydajność, kolejkowanie, obsługa błędów i możliwość ponawiania operacji.
Dobrze dobrana integracja ogranicza ręczną pracę, ale nie powinna odbierać kontroli nad procesami, w których błąd może powodować kosztowne konsekwencje.
