Integracja portalu B2B z ERP — Subiekt GT, Optima, enova365

Dlaczego integracja ERP to nie opcja, tylko fundament

Portal B2B bez integracji z ERP to połowiczne rozwiązanie. Zamówienia trafiają do portalu, ktoś ręcznie wpisuje je do ERP, stany są zawsze dzień do tyłu, a błędy cenowe wkradają się przy każdej aktualizacji cennika w Excelu. Powierzchnia jest zdigitalizowana — ale praca, którą miała zastąpić, nadal trwa.

Integracja to ta część, która sprawia, że portal faktycznie pracuje. Produkty, ceny i stany płyną automatycznie z ERP do portalu. Zamówienia wracają w drugą stronę. Nikt nie dotyka klawiatury dwa razy dla tych samych danych.

Ten przewodnik skupia się na trzech ERP-ach obejmujących mniej więcej 70% polskich hurtowni: Subiekt GT, Comarch Optima i enova365. Każdy z nich ma inne realia integracyjne — i te różnice są większe, niż większość dostawców powie Ci z góry.

Dwa podejścia integracyjne, które faktycznie się stosuje

Integracja przez API

ERP udostępnia ustrukturyzowany interfejs — REST lub SOAP — przez który portal czyta i zapisuje dane. Portal pobiera zaktualizowane produkty i ceny według harmonogramu, wyświetla stany w czasie bliskim rzeczywistemu i przesyła każde nowe zamówienie jako dokument sprzedaży.

To najczystsze podejście. Dane płyną prawie w czasie rzeczywistym, integrację łatwo monitorować, awarie łatwo diagnozować. Tyle że nie wszystkie polskie ERP-y mają dojrzałe API — a te, które mają, często wymagają dodatkowych licencji.

Realistyczne częstotliwości synchronizacji przy integracji API:

• Stany magazynowe: co 5 minut
• Ceny: co 15 minut
• Katalog produktów: co 60 minut lub webhook przy zmianie
• Zamówienia: w czasie rzeczywistym przy złożeniu

Synchronizacja plikowa

ERP eksportuje pliki (CSV, XML lub JSON) do wspólnej lokalizacji — serwer FTP, zasób sieciowy albo chmura. Portal pobiera je według harmonogramu, przetwarza zmiany i odkłada pliki zamówień do importu przez ERP.

Działa z praktycznie każdym ERP-em, również z tymi, gdzie API jest zamknięte lub wymaga drogich licencji. Kompromis to opóźnienie: interwały synchronizacji 15–60 minut, więcej punktów awarii do pilnowania i wyższe koszty utrzymania, gdy coś się posypie.

Kiedy synchronizacja plikowa to właściwy wybór: starsze instalacje Subiekta GT bez budżetu na licencję Sfera, konfiguracje Optimy bez modułu API, albo sytuacje gdy serwer ERP siedzi za firewallem, który nie wystawia zewnętrznych endpointów.

Subiekt GT (InsERT): realia najpopularniejszego polskiego ERP

Subiekt GT stoi w więcej polskich magazynach niż jakikolwiek inny ERP. I nie ma natywnego REST API. Ta luka jest istotna — ale projektu nie blokuje. Są trzy działające podejścia.

Opcja 1: Sfera SDK

Sfera to oficjalny SDK integracyjny InsERT. Pozwala zewnętrznym programom czytać i zapisywać dane w Subiekcie GT programistycznie — tak jak robi to aplikacja desktopowa, ale z zewnętrznego kodu.

Co Sfera potrafi:

• Czytać pełny katalog produktów z cenami, jednostkami i kategoriami
• Czytać stany magazynowe per lokalizacja magazynowa
• Zapisywać nowe zamówienia jako dokumenty sprzedaży (ZS) z poprawną numeracją ERP i przypisaniem klienta
• Czytać dane klientów i limity kredytowe

Wymagania infrastrukturalne: Sfera działa jako usługa Windows na tej samej maszynie co Subiekt GT. Twój portal — działający prawdopodobnie w chmurze — łączy się z tą usługą przez sieć. Potrzebujesz:

• Otwartego portu z serwera Subiekta do IP Twojego portalu
• Statycznego IP lub tunelu VPN
• Licencji Sfera (dodatkowy koszt — sprawdź u resellera InsERT, typowo 500–1 500 PLN zależnie od pakietu)

Czas integracji: 5–7 dni roboczych od momentu, gdy serwer Sfera jest dostępny.

Pułapka, w którą wszyscy wpadają: działy IT rutynowo blokują połączenia wychodzące z serwera Subiekta. "Skonfigurujemy firewall" to zdanie, które potrafi dodać 1–2 tygodnie do projektu. Ustal to przed startem, nie w trakcie.

Opcja 2: Bezpośredni dostęp do bazy Firebird

Subiekt GT używa Firebirda. Bezpośredni odczyt jest prosty — Firebird ma dobrze utrzymane konektory dla wszystkich popularnych języków. Przydatne do:

• Pełnych odczytów katalogu produktów
• Zapytań o aktualne stany magazynowe
• Danych cennikowych

Dlaczego nie zapisywać zamówień przez bazę: Subiekt GT ma logikę biznesową osadzoną w warstwie aplikacji — sekwencje numerowania dokumentów, triggery rezerwacji towaru, kalkulacje VAT. Zapis bezpośrednio do tabel Firebirda to ominięcie całej tej logiki. Dane trafiają do bazy, ale Subiekt "nie wie", że zamówienie zostało złożone. Dokumenty wychodzą nieprawidłowe albo nie powstają wcale.

Typowe podejście: bezpośredni odczyt bazy dla produktów, cen i stanów; Sfera do składania zamówień.

Opcja 3: Eksport plikowy

Subiekt GT może eksportować listy produktów, cenniki i raporty stanów do CSV. Jeśli Sfera odpada, to pokrywa przepływ danych z ERP do portalu. Zamówienia z portalu idą przez import XML Subiekta.

Czas integracji: 7–10 dni. Interwał synchronizacji: minimum 30–60 minut.

Comarch Optima: dobre API, nierówna implementacja

Comarch Optima to drugi najczęstszy polski ERP w segmencie MŚP. API ma — ale jakość i zakres zależą mocno od wersji i posiadanych licencji modułów.

API Optimy

Optima oferuje REST API przez platformę integracyjną Comarch. Gdy działa, pokrywa:

• Produkty i kategorie produktów
• Kontrahentów (klientów B2B)
• Dokumenty sprzedaży (tworzenie zamówień, odczyt faktur)
• Stany magazynowe

Problem z wersjami: jakość API Optimy znacznie poprawiła się między wersją 2023 a 2025. Przy starszej instalacji mogą brakować potrzebnych endpointów albo zachowywać się niespójnie. Przed projektowaniem integracji zdobądź dokładną wersję od IT i przetestuj konkretne endpointy, z których będziesz korzystać.

Czas integracji z API: 5–8 dni.

Wymiana plikowa Optimy

Wymiana plikowa Optimy (import/eksport XML) to najbardziej niezawodny plan B. Działa w produkcie od lat i pokrywa wszystkie potrzebne dane. Wady: asynchroniczność, konieczność zaplanowanego zadania na serwerze Optimy i nietrywialny schemat XML.

Jeden specyficzny problem Optimy: import zamówień XML ściśle waliduje kody kontrahentów. Jeśli Twój portal używa identyfikatorów, które nie pasują dokładnie do kodów w Optimie, import cicho się nie udaje — plik jest przetwarzany, ale żaden dokument nie powstaje. Zawsze waliduj mapowanie kodów kontrahentów przed uruchomieniem produkcyjnym.

Optima przez bezpośredni dostęp MS SQL

Optima stoi na Microsoft SQL Server. Odczyt danych produktów, cen i stanów jest prosty. Zapis zamówień przez bazę niesie te same ryzyka co przy Subiekcie — omijasz warstwę aplikacji i omijasz logikę biznesową.

Czas integracji: 5–7 dni (tylko odczyt) + dodatkowy czas na import zamówień przez XML.

enova365: najlepsza integracja z polskiego rynku ERP

enova365 ma najbardziej dojrzałe REST API wśród polskich systemów ERP. Jest dobrze udokumentowane, pokrywa wszystkie dane potrzebne portalowi B2B i — co ważne — działa spójnie między wersjami.

Co pokrywa API enova365:

• Produkty z pełnymi atrybutami: SKU, nazwa, opis, jednostki, waga, kategorie
• Indywidualne ceny per kontrahent lub grupa cenowa
• Stany magazynowe per lokalizacja magazynowa
• Zamówienia sprzedaży: tworzenie, odczyt, aktualizacja statusu
• Faktury: odczyt i pobieranie PDF
• Kontrahenci: dane klientów, limity kredytowe, warunki płatności

Czas integracji: 3–5 dni dla pełnej dwukierunkowej integracji. To najszybsza integracja ERP, którą wykonuję.

Jedna rzecz do sprawdzenia z góry: REST API enova365 wymaga aktywnego modułu API w licencji — nie wchodzi w pakiet podstawowy. Zadzwoń do resellera przed startem projektu. Jeśli nie masz tego modułu — dokup. Koszt jest zazwyczaj niższy niż alternatywa, czyli budowanie synchronizacji plikowej.

Webhooki: enova365 obsługuje wychodzące webhooki dla niektórych zdarzeń (zmiana statusu zamówienia, zmiany stanów). Portal może odbierać aktualizacje bez odpytywania, co zmniejsza obciążenie synchronizacji. Nie wszystkie instalacje mają webhooki skonfigurowane, ale warto zapytać.

SAP Business One: potężny, ale złożony

SAP B1 pojawia się w polskich hurtowniach, gdy biznes wyrósł ponad segment MŚP. Integracja jest dobra: SAP B1 oferuje Service Layer (REST) i DI API (COM). Większość portali B2B używa Service Layer.

Czas integracji: 5–7 dni developmentu, plus 3–5 dni na mapowanie danych. Model obiektowy SAP jest rozbudowany, a nazwy pól — nieintuicyjne. Mapowanie ItemCode SAP na SKU portalu, CardCode na identyfikatory klientów — to wymaga czasu, żeby pokryć wszystkie przypadki brzegowe.

Dane, które muszą się synchronizować — i jak często

Przed startem projektu zmapuj każdy typ danych. Ta tabela pokrywa standardowe wymagania polskiego portalu B2B dla hurtowni:

Typ danych	Kierunek	Minimalna częstotliwość	Priorytet
Katalog produktów (nazwa, SKU, opis, jednostka)	ERP → Portal	Raz dziennie lub przy zmianie	Wysoki
Indywidualne ceny per klient	ERP → Portal	Co 15 minut	Krytyczny
Przypisania do grup cenowych	ERP → Portal	Raz dziennie	Wysoki
Stany magazynowe	ERP → Portal	Co 5–15 minut	Krytyczny
Zdjęcia produktów	Ręcznie lub ERP → Portal	Przy zmianie	Średni
Zamówienia	Portal → ERP	W czasie rzeczywistym	Krytyczny
Potwierdzenie/status zamówienia	ERP → Portal	Co 15–30 minut	Wysoki
Faktury PDF	ERP → Portal	Przy wygenerowaniu	Średni
Dane klientów (limity kredytowe, warunki płatności)	ERP → Portal	Raz dziennie	Wysoki
Lista kontrahentów	ERP → Portal	Raz dziennie	Wysoki

Problem złożoności cenowej

Polskie hurtownie rzadko mają prostą strukturę cen. Typowy schemat:

• Cennik bazowy
• Rabat per grupa klienta (np. -12% dla grupy A, -8% dla grupy B)
• Indywidualny rabat na produkt per klient (np. -5% na produkt X dla klienta Kowalski)
• Progi ilościowe (np. powyżej 50 sztuk dodatkowe -3%)
• Promocje okresowe

Portal musi kalkulować ceny identycznie jak ERP. Każda rozbieżność — inne zaokrąglanie, inna kolejność stosowania rabatów, inna logika promocji — sprawia, że klient widzi jedną cenę w portalu, a na fakturze dostaje inną. To szybko niszczy zaufanie.

Jedyne bezpieczne podejście: ERP kalkuluje cenę końcową i przesyła ją do portalu. Nie odtwarzaj logiki cenowej w portalu niezależnie. Jedno źródło prawdy, zawsze.

Harmonogram wdrożenia: realistyczne oczekiwania

Na podstawie zrealizowanych przeze mnie integracji — uczciwe terminy dla pełnej dwukierunkowej integracji (produkty, ceny, stany, zamówienia, statusy):

ERP	Podejście	Dni programistyczne	Łączny czas kalendarzowy (z konfiguracją i testami)
enova365	REST API	3–5 dni	2–3 tygodnie
Subiekt GT	Sfera + odczyt DB	5–7 dni	3–4 tygodnie
Comarch Optima	API	5–8 dni	3–4 tygodnie
Comarch Optima	Wymiana plikowa	7–10 dni	4–5 tygodni
SAP Business One	Service Layer	6–9 dni	3–5 tygodni

Różnica między dniami programistycznymi a czasem kalendarzowym to prawie zawsze to samo: czekanie na IT w sprawie dostępu do serwera. Otwarcie portu, tunel VPN, whitelist IP. Zadania na 30 minut, które zajmują 2 tygodnie, bo wchodzą do kolejki zgłoszeń.

Rekomendacja: Przed startem projektu wyślij IT listę dokładnie tego, czego potrzebujesz. Nie czekaj, aż zapyta o to developer w połowie projektu.

Typowe pułapki i jak ich uniknąć

Overselling: Dwóch klientów jednocześnie zamawia ostatnie 20 sztuk. Obaj dostają potwierdzenia. Rozwiązanie: synchronizuj stany co 5–10 minut i wdróż miękką rezerwację przy złożeniu zamówienia (rezerwuj w bazie portalu natychmiast, synchronizuj rezerwację z ERP w ciągu 60 sekund).

Rozbieżność cenowa na fakturze: Portal pokazuje 42 PLN, faktura przychodzi na 45 PLN. Prawie zawsze to różnica w kalkulacji rabatu albo opóźnienie synchronizacji przy aktualizacji cennika. Rozwiązanie: waliduj cenę wobec ERP przy potwierdzeniu zamówienia, nie tylko przy wyświetlaniu w katalogu.

Kodowanie znaków przy synchronizacji plikowej: Polskie znaki (ą, ę, ś, ź, ó, ł) się sypią. Zdarza się w mniej więcej 30% integracji plikowych przy pierwszym uruchomieniu. Rozwiązanie: wymuś UTF-8 od początku do końca. Testuj z nazwami produktów zawierającymi wszystkie polskie znaki przed startem.

Ciche niepowodzenia importu: Import zamówień ERP raportuje sukces, ale żaden dokument nie powstaje. Zazwyczaj błąd walidacji wychwycony przez warstwę aplikacji ERP, który nie pojawia się jako błąd w portalu. Rozwiązanie: zawsze sprawdzaj liczbę dokumentów po imporcie, nie tylko kody statusu.

Restarty serwera ERP: Zaplanowane restarty serwerów Subiekt/Optima, o których nikt Ci nie powiedział, zrywające usługę Sfera albo harmonogram eksportu FTP o 3:00 w nocy. Rozwiązanie: monitoring z alertami dla luk synchronizacji — jeśli żadna synchronizacja nie zakończyła się w ciągu dwukrotności oczekiwanego interwału, ktoś powinien dostać powiadomienie.

Przed startem: 6-punktowa lista kontrolna integracji

Zbierz te informacje przed startem developmentu. Eliminuje to najczęstsze opóźnienia w trakcie projektu:

1. Dokładna wersja ERP — nie "mamy Subiekta", ale "Subiekt GT 1.09 SR2 (build 43521)". Wersja determinuje dostępne metody integracji.
2. Licencje API/modułów — potwierdź licencję Sfera dla Subiekta, moduł API dla enova365, odpowiednie moduły Optimy.
3. Dostęp do serwera — adres IP, port, poświadczenia i potwierdzenie na piśmie, że IP Twojego portalu zostanie dodane do whitelist.
4. Eksport cennika — rzeczywisty eksport aktualnych cenników, żeby walidować kalkulacje cen portalu wobec ERP przed uruchomieniem.
5. Eksport listy klientów — wszystkie aktywne rekordy z identyfikatorami, żeby portal mógł poprawnie mapować klientów od pierwszego dnia.
6. Dokumentacja obiegu zamówień — jak zamówienie przechodzi od "złożonego" do "zafakturowanego" w Twoim ERP? Każde przejście statusu musi być zmapowane na stan portalu.

Brak któregokolwiek z tych punktów będzie Cię kosztować dni. Najczęstsze opóźnienie w integracjach ERP to czekanie na IT po poświadczenia dostępu do serwera. Rozwiąż to przed startem projektu.

Więcej o tym, co zawiera kompletny portal B2B dla hurtowni poza warstwą integracji ERP, znajdziesz na stronie usługi — albo odezwij się, jeśli chcesz bezpośredniej oceny swojego konkretnego ERP-u.