Integracja Subiekta GT i nexo z platformą B2B – zamówienia, stany i ceny bez przepisywania

Subiekta GT i Subiekta nexo da się połączyć z platformą B2B tak, żeby zamówienia wpadały do systemu bez przepisywania, a klienci widzieli aktualne stany i swoje ceny. Warunek jest jeden: integracja powinna iść przez oficjalną warstwę programistyczną InsERT (Sferę) i przez niewielką usługę pośredniczącą postawioną obok bazy danych, a nie przez bezpośrednie zapisy do SQL. Poniżej opisujemy, jak taka architektura wygląda w praktyce, co synchronizować w którą stronę i na czym najczęściej wykładają się pierwsze wdrożenia.

Dlaczego Subiekt nie „wystawi” danych sam z siebie

Oba programy powstały jako aplikacje desktopowe dla Windows, pracujące na bazie Microsoft SQL Server w sieci lokalnej firmy. Nie mają wbudowanego publicznego REST API, pod które portal B2B mógłby się po prostu podpiąć przez internet. To zasadnicza różnica w porównaniu z systemami chmurowymi.

Do automatyzacji producent udostępnia Sferę:

• Subiekt GT + Sfera – dodatkowo płatna licencja, która daje dostęp do obiektów programu przez interfejs COM. Z poziomu kodu (najczęściej C# lub innego języka obsługującego COM) można m.in. tworzyć dokumenty, dodawać kontrahentów i odczytywać towary tak, jak zrobiłby to użytkownik – z zachowaniem logiki programu.
• Subiekt nexo + Sfera – odpowiednik dla linii nexo, oparty na bibliotekach .NET. Model jest podobny: kod uruchamia się na maszynie z Windows, loguje do podmiotu i operuje na obiektach biznesowych.

Szczegóły licencjonowania, wymagane wersje i zakres dostępnych obiektów zmieniają się między wydaniami, dlatego przed wyceną zawsze sprawdzamy je dla konkretnej wersji i licencji klienta u partnera InsERT albo w dokumentacji producenta.

Pokusa, żeby ominąć Sferę i czytać lub zapisywać tabele SQL bezpośrednio, jest zrozumiała – działa od razu i nie wymaga dodatkowej licencji. Odczyt stanów czy cen przez widoki SQL bywa akceptowalny jako rozwiązanie tymczasowe. Zapis dokumentów prosto do bazy to już proszenie się o kłopoty: pomijasz numerację, rezerwacje, przeliczenia VAT i powiązania, których program pilnuje sam. Pierwsza aktualizacja Subiekta może też zmienić strukturę tabel bez ostrzeżenia.

Architektura: portal, kolejka i usługa przy bazie

Model, który sprawdza się przy integracjach z systemami lokalnymi, składa się z trzech elementów:

• Portal B2B w chmurze – katalog, koszyk, konta klientów. Udostępnia własne API (np. zbudowane w Laravel) do odbioru stanów i cen oraz wydawania nowych zamówień.
• Kolejka zadań – każde zamówienie z portalu i każda paczka zmian z Subiekta trafia do kolejki jako osobne zadanie ze statusem i licznikiem prób.
• Usługa Windows przy bazie Subiekta – mały program działający na serwerze firmy, który co określony czas pobiera zadania z portalu, wykonuje je przez Sferę i odsyła wynik. Połączenie inicjuje usługa (ruch wychodzący HTTPS), więc nie trzeba otwierać portów do serwera z księgowością.

Takie rozdzielenie ma dwie zalety. Po pierwsze, gdy serwer w biurze jest wyłączony albo trwa aktualizacja Subiekta, portal działa dalej – zamówienia czekają w kolejce i zostaną przeniesione, kiedy usługa wróci. Po drugie, każdy krok jest zalogowany: widać, które zamówienie weszło, pod jakim numerem ZK, a które zostało odrzucone i dlaczego. Szerzej opisujemy to podejście na stronie integracje B2B z ERP, w tym z Subiektem.

Co synchronizować i w którą stronę

Najwięcej problemów bierze się z niejasnego podziału odpowiedzialności. Dobra zasada: każda dana ma jedno źródło prawdy.

• Towary i opisy handlowe: Subiekt → portal. Kartoteka towarowa zostaje w Subiekcie, a portal dokłada treści marketingowe, zdjęcia i atrybuty filtrów, których Subiekt nie przechowuje.
• Stany magazynowe: Subiekt → portal, najlepiej jako stan dostępny (po odjęciu rezerwacji), a nie stan fizyczny.
• Ceny i rabaty: Subiekt → portal. Poziomy cen, cenniki i rabaty kontrahenta powinny być liczone według tych samych reguł, które stosuje handlowiec.
• Kontrahenci: zwykle Subiekt → portal (portal tworzy konto do istniejącej kartoteki), z możliwością rejestracji nowych firm w portalu i zakładania ich w Subiekcie po akceptacji.
• Zamówienia: portal → Subiekt jako zamówienie od klienta (ZK), z numerem zamówienia portalu w polu uwag lub numerze obcym.
• Statusy i dokumenty: Subiekt → portal – realizacja, numer faktury, ewentualnie PDF faktury i dokumenty przewozowe.

Częstotliwość i konflikty

Nie wszystko musi dziać się w czasie rzeczywistym. Przykładowy harmonogram, od którego zaczynamy rozmowę z klientem:

1. zamówienia – od razu po złożeniu trafiają do kolejki, usługa pobiera je co 1–2 minuty,
2. stany – przyrostowo co kilka minut, pełne uzgodnienie raz na dobę w nocy,
3. ceny i rabaty – co godzinę lub po zmianie cennika, plus pełna synchronizacja nocna,
4. kartoteka towarów – kilka razy dziennie albo na żądanie z panelu.

Konflikty pojawiają się głównie przy stanach. Klient zamawia 50 sztuk, portal pokazał 60, a w tej samej minucie handlowiec wystawił w Subiekcie fakturę na 20. Nie da się tego wyeliminować w stu procentach, ale można ograniczyć skutki: portal rezerwuje ilość lokalnie do czasu potwierdzenia, a usługa po utworzeniu ZK odsyła rzeczywisty stan. Gdy towaru zabraknie, zamówienie wchodzi z brakiem, a klient dostaje informację o częściowej realizacji zamiast milczenia.

Druga kategoria konfliktów to edycje tych samych danych w dwóch miejscach, np. adresu dostawy. Tu wystarcza reguła: portal może zaproponować zmianę, ale zatwierdza ją Subiekt (albo osoba w dziale obsługi).

Pułapki, które wychodzą dopiero na produkcji

Ceny indywidualne

Subiekt pozwala łączyć poziomy cen, rabaty dla kontrahenta, grupy towarów i promocje. Portal musi odtworzyć dokładnie ten sam wynik, inaczej klient zobaczy w koszyku jedną kwotę, a na fakturze drugą. Mamy dwie drogi: przeliczać cenę w portalu według przeniesionych reguł albo cyklicznie liczyć gotowe ceny w Subiekcie i wysyłać je do portalu jako cennik per klient. Druga opcja jest prostsza w utrzymaniu przy mniejszej liczbie klientów, pierwsza lepiej skaluje się przy tysiącach kontrahentów. W obu przypadkach przed startem porównujemy ceny dla próbki klientów i towarów – to test, którego nie wolno pominąć.

Jednostki miary i opakowania

Towar liczony w sztukach w Subiekcie bywa sprzedawany w kartonach po 12. Jeżeli portal pozwala zamówić karton, a do Subiekta trafia „1” zamiast „12”, różnica wyjdzie dopiero przy kompletacji. Przelicznik jednostek musi być jawnie zmapowany, a minimalne ilości zamówienia pilnowane po obu stronach.

Rezerwacje

Zamówienie ZK w Subiekcie może, ale nie musi rezerwować towaru – zależy to od ustawień. Jeśli portal liczy stan dostępny, a rezerwacje w Subiekcie są wyłączone, dwóch klientów kupi ten sam ostatni towar. Ustalenie tej zasady z magazynem to pół godziny rozmowy, która oszczędza tygodni reklamacji.

Stawki VAT i waluty

Klienci z UE z ważnym numerem VAT, sprzedaż w euro, towary z różnymi stawkami – każdy z tych przypadków trzeba przejść na testowym zamówieniu, zanim portal zostanie otwarty dla klientów.

Plan wdrożenia etapami

Nie zaczynamy od pełnej dwustronnej synchronizacji. Bezpieczniejsza kolejność wygląda tak:

1. Analiza bazy i licencji – wersja Subiekta, liczba podmiotów i magazynów, sposób wyliczania cen, dostępność Sfery.
2. Eksport tylko do odczytu – towary, stany i ceny płyną do portalu, a zamówienia jeszcze przychodzą mailem. Tak sprawdzamy poprawność cen na realnych danych.
3. Zamówienia do Subiekta – najpierw w trybie „do zatwierdzenia” przez handlowca, po kilku tygodniach automatycznie dla zaufanych klientów.
4. Statusy i dokumenty zwrotnie – klient widzi w portalu realizację i faktury.
5. Monitoring – alert, gdy usługa nie połączy się z portalem przez określony czas, dzienny raport błędów, prosty panel ponowienia zadania.

Dzięki takiemu podziałowi każdy etap daje wartość i można go wycofać bez zatrzymywania sprzedaży.

Kiedy integracja z Subiektem nie ma sensu

Jeżeli firma przyjmuje kilkanaście zamówień B2B miesięcznie, a cenniki są proste, koszt licencji, usługi pośredniczącej i jej utrzymania może przewyższyć oszczędność czasu. Czasem lepszym krokiem jest eksport cennika i import zamówień z pliku raz dziennie. Z drugiej strony firmy, które rosną, szybko trafiają na limity Subiekta i rozważają przejście na Comarch lub inny ERP – wtedy warto projektować warstwę pośrednią tak, żeby portal nie wiedział, jaki system stoi po drugiej stronie. Wymiana ERP oznacza wtedy wymianę usługi, a nie całego portalu. Więcej o typowych błędach tego typu projektów przeczytasz w artykule Integracja ERP z platformą B2B – najczęstsze pułapki.

Od czego zacząć

Zanim poprosisz o wycenę, przygotuj trzy informacje: wersję Subiekta (GT czy nexo i numer wydania), opis tego, jak dziś liczycie ceny dla różnych klientów, oraz przybliżoną liczbę zamówień i pozycji miesięcznie. Z tym da się rzetelnie ocenić, czy wystarczy prostsza wymiana plików, czy potrzebna jest pełna integracja przez Sferę, i jak ma wyglądać platforma B2B dla Twojej firmy. Jeśli chcesz przejść przez to z zespołem, który budował portale B2B zintegrowane z systemami lokalnymi, napisz do nas – zaczniemy od krótkiej analizy Twojej bazy i procesu zamówień.