Integracja Subiekt GT ze sklepem internetowym

Subiekt GT to w polskich hurtowniach i sklepach niemal domyślny program magazynowo-handlowy. Problem w tym, że przez lata żył on obok sklepu internetowego, a nie razem z nim: ktoś przepisywał stany, ręcznie zakładał zamówienia, wieczorem zgrywał sprzedaż. Integracja ma to skasować i zrobić z Subiekta oraz sklepu jedno źródło prawdy o tym, co jest na stanie, po jakiej cenie i z jakimi dokumentami. Poniżej jak się do tego zabrać i gdzie są miny.

Po co w ogóle to spinać

Zanim wejdziemy w metody, warto nazwać cel. Integracja Subiekta ze sklepem załatwia trzy rzeczy naraz:

• Stany magazynowe – sklep pokazuje to, co faktycznie leży w magazynie, a nie stan sprzed wczoraj. Mniej naddostępności i tłumaczenia klientom, że jednak nie ma.
• Ceny i kartoteki – cennik i dane produktów mają jedno miejsce zarządzania, zamiast rozjeżdżać się między systemami.
• Dokumenty – zamówienie ze sklepu ląduje w Subiekcie jako dokument (zamówienie od klienta, potem faktura albo paragon), więc księgowość i magazyn nie przepisują niczego ręcznie.

Dla hurtowni B2B dochodzi czwarta rzecz: kontrahenci, ich indywidualne warunki i limity. O tym niżej, bo to zwykle najtrudniejszy fragment.

Sposoby integracji

Nie ma jednego „prawidłowego” sposobu – są trzy podejścia o różnym poziomie zaawansowania i kosztu utrzymania.

Sfera – programistyczne API Subiekta

Sfera to dodatek firmy InsERT, który udostępnia programistyczny interfejs do Subiekta (oparty na technologiach COM/OLE Automation). Mówiąc wprost: kod może tworzyć w Subiekcie dokumenty, czytać kartoteki i stany, zakładać kontrahentów – tak, jakby robił to operator, tylko automatycznie. To płatny dodatek, który trzeba dokupić do licencji Subiekta GT.

Sfera daje najwięcej kontroli i najczystszą logikę: sam decydujesz, co, kiedy i w którą stronę się synchronizuje. Kosztem jest to, że działa lokalnie przy instalacji Subiekta, więc integracja zwykle wymaga usługi pośredniczącej (konektora) po stronie serwera lub maszyny z Subiektem. To rozwiązanie dla firm, które chcą stabilnej, „szytej” synchronizacji i traktują ją jak element infrastruktury.

Pośrednik typu BaseLinker

Zamiast łączyć sklep z Subiektem bezpośrednio, można wpiąć między nie gotową platformę. BaseLinker zbiera zamówienia (także z marketplace’ów), a z Subiektem wymienia się stanami i dokumentami przez gotowy konektor. Zaleta: szybki start, bez pisania własnego kodu. Wada: jesteś w ramach tego, co pośrednik potrafi, a przy nietypowej logice cenowej B2B potrafi to nie wystarczać. Dla wielu sklepów detalicznych i mniejszych hurtowni to jednak sensowne wejście.

Wymiana plikowa

Najstarszy, najprostszy mechanizm: Subiekt eksportuje dane (np. stany i cennik) do pliku, sklep je zaciąga, a zamówienia wracają w drugą stronę osobnym plikiem. Bywa realizowana przez feedy XML. Działa cyklicznie, jest tania i odporna na „chwilowe” niedostępności, ale z natury nie jest natychmiastowa. Sprawdza się tam, gdzie asortyment nie jest mocno deficytowy i kilkuminutowe opóźnienie stanu nikogo nie boli.

Metoda	Kiedy wybrać	Uwaga
Sfera	Pełna kontrola, szyta logika, większa skala	Płatny dodatek, potrzebny konektor przy Subiekcie
Pośrednik (BaseLinker)	Szybki start, sprzedaż wielokanałowa	Ograniczenia przy złożonej logice B2B
Pliki (XML/CSV)	Prostota, cykliczna synchronizacja	Nie działa „na żywo”

Co synchronizować i w którą stronę

Integracja to nie „wszystko z wszystkim”. Najwięcej problemów bierze się z niejasnego kierunku synchronizacji. Dobra mapa wygląda mniej więcej tak:

• Stany magazynowe: Subiekt → sklep. Towar schodzi z dokumentów i sprzedaży stacjonarnej, więc to Subiekt zna prawdę. Sklep odczytuje.
• Ceny i kartoteki: zwykle Subiekt → sklep, choć opisy, zdjęcia i SEO często żyją po stronie sklepu. Ustal, które pole ma którego właściciela, żeby jedna strona nie nadpisywała drugiej.
• Zamówienia: sklep → Subiekt. Zamówienie klienta tworzy w Subiekcie dokument, na bazie którego magazyn kompletuje, a księgowość fakturuje.
• Statusy i numery dokumentów: Subiekt → sklep, żeby klient widział w koncie, że zamówienie jest w realizacji albo zafakturowane.

Zasada nadrzędna: każde pole ma dokładnie jednego właściciela. Gdy dwie strony mogą zmieniać ten sam stan, prędzej czy później się rozjadą.

Pułapki, które kosztują najwięcej

To fragment, który odróżnia integrację „działa na demo” od „działa po roku na produkcji”.

• Jednostki miary. Subiekt operuje jednostkami (szt., opak., karton), a sklep często sprzedaje w innej. Jeśli mapowanie jednostek jest niedbałe, zamawiasz karton, a schodzi sztuka – albo odwrotnie. To klasyk przy artykułach sprzedawanych zbiorczo.
• VAT i ceny netto/brutto. Hurtownia myśli w netto, detal w brutto. Integracja musi jednoznacznie wiedzieć, którą wartość przenosi i jak liczy podatek, inaczej pojawiają się groszowe rozjazdy między sklepem a fakturą. Rozwijamy ten wątek w tekście o cenach netto i brutto w hurtowni.
• Duplikaty kontrahentów. Największy killer w B2B. Jeśli integracja przy każdym zamówieniu zakłada nowego klienta zamiast dopasować istniejącego po NIP-ie, po kwartale masz jednego kontrahenta w kilku wersjach, rozjechane historie i nietrafione limity. Klucz dopasowania (dla firm to zwykle NIP) trzeba ustalić na samym początku.
• Rezerwacje i wyścig o stan. Gdy ten sam towar sprzedaje sklep, Allegro i handlowiec z Subiekta, trzeba świadomie zdecydować, kto rezerwuje i kto ustępuje. Bez tego dojdzie do sprzedania sztuki, której już nie ma.

Jak przetestować, zanim wpuścisz ruch

Integracja magazynowa to obszar, w którym błąd widać dopiero na produkcji, gdy schodzą realne stany i powstają realne faktury. Dlatego warto ją przećwiczyć wcześniej, na danych, których nie szkoda.

• Pracuj na kopii bazy Subiekta. Testuj tworzenie dokumentów i zakładanie kontrahentów na osobnej instancji, nie na produkcyjnej bazie księgowości. Odzyskiwanie po pomyłce na żywych danych bywa droższe niż samo wdrożenie.
• Przejdź pełny cykl jednego zamówienia. Od złożenia w sklepie, przez dokument w Subiekcie, po zejście stanu i status wracający do sklepu. Jedno zamówienie „na sucho” wyłapie więcej niż godziny czytania dokumentacji.
• Sprawdź przypadki brzegowe. Zamówienie z nowym kontrahentem (czy nie powstaje duplikat?), z towarem na granicy dostępności (czy stan nie schodzi poniżej zera?), z nietypową jednostką. To tu kryją się problemy, które później generują reklamacje.
• Zaplanuj, co się dzieje przy awarii konektora. Subiekt bywa wyłączony na noc albo maszyna się restartuje. Zamówienia z tego okna muszą się zbuforować i dojść później, a nie przepaść.

Ta sama filozofia „najpierw środowisko testowe, potem ruch” sprawdza się w każdej integracji – opisaliśmy ją też przy wpinaniu InPostu.

Subiekt GT czy nexo

Krótko, bo to częste pytanie. Subiekt GT to starsza, bardzo rozpowszechniona linia InsERT z dodatkiem Sfera. Subiekt nexo to nowsza linia z własnym, bardziej współczesnym API (Sfera nexo). Oba integrują się ze sklepem. Jeśli dopiero wybierasz system, nexo bywa wygodniejsze technicznie, ale decyzję powinny napędzać potrzeby księgowo-magazynowe, nie sama integracja – tę wykonasz na jednym i drugim. Jeśli już masz GT z historią dokumentów i kontrahentów, rzadko warto migrować tylko po to, żeby spiąć sklep.

Niezależnie od wybranej drogi sedno jest to samo: integracja ma zamienić dwa systemy w jeden spójny obieg towaru, ceny i dokumentu. To dokładnie zakres, który robimy w ramach integracji systemów ERP, OMS i WMS – od mapowania kartotek, przez kierunki synchronizacji, po obsługę błędów, gdy któraś strona chwilowo milczy.