Integracja Comarch Optima z portalem B2B — jak to naprawdę wygląda

Comarch Optima to najpopularniejszy polski ERP — i najtrudniejszy do czystej integracji

Comarch Optima ma największą bazę instalacji ze wszystkich ERP-ów na polskim rynku MŚP. Jeśli sprzedajesz oprogramowanie albo budujesz portale w Polsce, spotykasz ją częściej niż enova365, Subiekt czy cokolwiek innego. A to znaczy, że pytanie "jak podłączyć nasz portal B2B do Optimy?" wraca bez przerwy — i szczera odpowiedź nie jest tą, którą ludzie chcą usłyszeć.

Optima nie ma czystego, udokumentowanego REST API, które pokrywałoby potrzeby portalu hurtowego od początku do końca. enova365 ma — przez Soneta WebAPI — i dzięki temu jej integracja to robota na 3–5 dni. Optima to 7–10 dni na ten sam zakres funkcji, i te dodatkowe dni to nie jest naddatek. To warstwa synchronizacji, którą musisz zbudować sam, bo ERP ci jej nie daje.

Ten artykuł jest dla firm działających na Comarch Optima, które chcą podłączyć hurtowy portal B2B — i dla ludzi, którzy będą to budować. Jeśli dopiero wybierasz ERP, porównanie integracji portali B2B z Subiektem GT, Optimą i enova365 daje pełny obraz. A o tym, co portal robi poza warstwą ERP, przeczytasz na stronie portalu hurtowego.

---

Trzy realne drogi integracji

Nie ma jednego "API Optimy", które robi wszystko. W praktyce łączysz jedno lub kilka z trzech podejść. Każde ma jasne zastosowanie i jasny scenariusz porażki.

1. Praca Rozproszona — wymiana XML

Praca Rozproszona to wbudowany mechanizm Optimy do wymiany dokumentów między bazami w postaci plików XML. Powstał do synchronizacji oddziałów z centralą, ale to oficjalnie usankcjonowana droga wprowadzania dokumentów do Optimy z zewnątrz.

Co robi dobrze: zwrotne składanie zamówień. Portal generuje dokument XML opisujący zamówienie (RO — rezerwacja odbiorcy, albo faktura/paragon zależnie od obiegu), umieszcza go w lokalizacji wymiany, a Optima go importuje — nadając własny numer, stosując własne reguły cenowe i własną walidację. To poprawny sposób tworzenia dokumentów w Optimie. Nigdy nie wymyślasz numerów dokumentów po stronie portalu.

Co robi słabo: odczyty w czasie rzeczywistym. Wymiana XML jest wsadowa. Sprawdza się przy zamówieniach płynących w jedną stronę według harmonogramu, ale jest niewygodna przy odczycie stanów i cen na żywo, gdy portal potrzebuje odpowiedzi w tej samej sekundzie.

2. Bezpośredni odczyt z bazy SQL Optimy

Optima trzyma wszystko w bazie Microsoft SQL Server. Odczyt wprost z niej to najszybszy sposób wyciągnięcia katalogu, cen i stanów.

Używaj tylko do odczytu. Pobieranie katalogu produktów, cenników, stanów magazynowych i danych kontrahentów zapytaniami SELECT jest częste, wydajne i niezawodne. Wiele produkcyjnych integracji Optima–portal robi dokładnie to na ścieżce odczytu.

Nigdy nie zapisuj wprost. Schemat nie jest dokumentowany do użytku zewnętrznego, zmienia się między wersjami Optimy, a zapis prosto do tabel omija całą logikę biznesową, którą Optima uruchamia przy zapisie. Popsujesz dane i unieważnisz wsparcie Comarch w momencie, gdy zobaczą obce zapisy. Zamówienia wracają przez Pracę Rozproszoną lub API CDN — nigdy przez surowy INSERT.

3. API CDN i middleware

Optima udostępnia model automatyzacji — historycznie API CDN, warstwę obiektową COM/OCX działającą na Windows obok instalacji Optimy. Pozwala zewnętrznemu kodowi sterować Optimą tak, jak robiłby to użytkownik: tworzyć dokumenty, czytać dane, wyzwalać operacje, wszystko przez własną logikę Optimy. Jest solidniejsze niż surowy SQL do zapisów, ale przywiązane do Windows i nie zaprojektowane pod chmurowy, wysokowspółbieżny ruch webowy.

Dlatego większość poważnych integracji Optimy stawia usługę middleware między portalem a ERP. Mały konektor hostowany na Windows stoi obok Optimy, rozmawia z nią przez API CDN i kontrolowany odczyt SQL, a portalowi w chmurze wystawia czyste wewnętrzne API. To wzorzec, po który sięgam: izoluje całe sprzężenie specyficzne dla Optimy w jednym miejscu, więc aktualizacja wersji dotyka jednego adaptera, a nie całego portalu.

---

Architektura referencyjna, która się trzyma

Oto kształt integracji Optima–portal, która przeżywa zderzenie z produkcją i z kolejną aktualizacją Optimy.

Portal działa w chmurze, jak należy. Nigdy nie rozmawia z Optimą bezpośrednio i nigdy nie trzyma danych logowania do Optimy.

Konektor middleware działa on-premise albo na maszynie Windows z dostępem sieciowym do serwera SQL Optimy. Robi trzy rzeczy:

1. Synchronizacja odczytu (SQL, tylko odczyt): według harmonogramu pobiera katalog, cenniki per kontrahent i stany magazynowe z bazy Optimy i wysyła je do własnej bazy portalu. Katalog co 30–60 minut, ceny co 15 minut, stany co 5–15 minut zależnie od rotacji.
2. Zwrotne składanie zamówień (Praca Rozproszona / API CDN): gdy klient potwierdza zamówienie, portal woła konektor, który tworzy dokument w Optimie usankcjonowaną drogą. Optima nadaje numer i go zwraca. Zapisz ten numer — to do niego odwołuje się i klient, i twoja księgowość.
3. Synchronizacja statusów i faktur (odczyt SQL): konektor odczytuje zmiany statusu zamówień i wygenerowane faktury, żeby portal mógł pokazać postęp realizacji i pozwolić klientom pobrać faktury.

Sprzężenie żyje w jednym module. Każda nazwa tabeli, każda wersja obiektu CDN, każda osobliwość schematu XML jest wewnątrz konektora. Gdy Comarch wypuszcza nowy build Optimy, walidujesz i — jeśli trzeba — poprawiasz jeden komponent, a nie pięćdziesiąt endpointów portalu.

---

Ceny: ta sama reguła co w każdym polskim ERP

Polskie ceny hurtowe w Optimie są wielowarstwowe — cennik bazowy, grupy cenowe per kontrahent, rabaty indywidualne, progi ilościowe, promocje czasowe. Te warstwy oddziałują na siebie według reguł priorytetu w silniku cenowym Optimy.

Nie odtwarzaj tej logiki w portalu. Odczytaj z Optimy cenę końcową, wyliczoną dla konkretnego kontrahenta i produktu, wyświetl ją i zwaliduj ponownie przy potwierdzeniu zamówienia. Jeśli sam odtworzysz matematykę rabatów, w końcu trafisz na przypadek, gdy portal pokazuje jedną cenę, a faktura mówi inną — a to problem z zaufaniem klienta, z którego trudno się wycofać. Porównanie integracji ERP wchodzi głębiej w to, dlaczego ERP musi zostać jedynym źródłem prawdy o cenach we wszystkich trzech systemach.

---

Pułapka przywiązania do wersji

Największa różnica między integracją Optimy, która trwa latami, a taką, która pada co kwartał, to sposób obsługi aktualizacji.

Comarch wydaje nowe buildy Optimy kilka razy w roku. Zmienić się może zarówno schemat SQL, jak i powierzchnia API CDN. Integracja wpięta wprost w konkretne struktury tabel — bez warstwy izolującej — to obciążenie serwisowe, które pada przy kolejnej aktualizacji, zwykle w najgorszym momencie.

Trzy praktyki utrzymują to w ryzach:

• Izoluj całe sprzężenie z Optimą w konektorze. Jeden moduł zna nazwy tabel i wersje obiektów. Nic innego.
• Trzymaj bazę testową na docelowej wersji Optimy. Przed każdą aktualizacją produkcyjną przepuść pełną integrację przez kopię bazy klienta na nowym buildzie.
• Waliduj przy każdej aktualizacji Optimy. Traktuj każdą aktualizację ERP jak wydanie integracji, z własnym przejściem testów. Przy Optimie to nie jest opcjonalne — inaczej niż niemal przy enova365.

---

Harmonogram i koszty

Czas developmentu: 7–10 dni roboczych dla standardowej pełnej dwukierunkowej integracji — synchronizacja odczytu katalogu, cen i stanów; zwrotne składanie zamówień przez Pracę Rozproszoną lub API CDN; pobieranie statusów i faktur. Dla porównania: 3–5 dni dla enova365 i 5–7 dla Subiekta GT przez Sferę.

Czas kalendarzowy: 3–4 tygodnie. Różnicę robi zwykła historia plus jeden element specyficzny dla Optimy: potrzebujesz kopii testowej bazy klienta i dostępu sieciowego do serwera SQL, zanim ruszą realne prace. Zdobycie backupu bazy i hosta Windows pod konektor rutynowo dodaje tydzień.

Koszt bieżący: zabudżetuj rewalidację przy aktualizacjach Optimy. Jest niewielki, jeśli sprzężenie jest izolowane, i bolesny, jeśli nie jest. To ten powracający koszt, którego enova365 w większości unika — warto o tym wiedzieć, zanim wybierzesz Optimę jako cel integracji.

Jeśli przewidywalność kosztów liczy się dla ciebie najbardziej, przeczytaj ile naprawdę kosztuje portal B2B — to właśnie w pozycji integracji ERP Optima i enova365 rozjeżdżają się najmocniej.

---

Optima kontra enova365: szczerze

Optima nie jest złym ERP-em. Ma największą bazę instalacji w Polsce nie bez powodu — szeroka funkcjonalność, mocna księgowość, ogromna sieć partnerów. Ale jako cel integracji dla portalu B2B wymaga od ciebie więcej niż enova365. Brak czystego REST API, większa kruchość przy aktualizacjach, więcej własnego kodu synchronizacji.

Jeśli już działasz na Optimie, żaden z tych punktów nie jest powodem do zmiany — integracja jest w pełni wykonalna, istnieją ich tysiące, a wzorzec konektora middleware czyni ją odporną. Wejdź w to, wiedząc, że to budowa na 7–10 dni z bieżącym zobowiązaniem do rewalidacji, a nie weekendowa wtyczka. A jeśli dopiero wybierasz między ERP-ami i nakład na integrację jest realnym czynnikiem w decyzji, właśnie do tego służy porównanie Subiekt vs Optima vs enova365.

---

Podłączasz Comarch Optima do portalu B2B?

Integracje Optimy są w pełni wykonalne — klucz to architektura, która izoluje sprzężenie z ERP, i plan na przetrwanie aktualizacji wersji. Zrób te dwie rzeczy dobrze, a będzie działać latami.

Jeśli działasz na Comarch Optima i rozważasz portal B2B albo masz portal, który musi się z Optimą połączyć, napisz do mnie. Ocenię twoją konkretną konfigurację — wersję Optimy, dostęp do bazy, obieg zamówień — i powiem wprost, czego integracja będzie wymagać po twojej stronie.

Pełny obraz ERP po ERP-ie znajdziesz w porównaniu integracji Subiekt GT, Optima i enova365 oraz na stronie usługi integracji ERP z B2B.