Rozmowa o integracji Optimy ze sklepem prawie zawsze zaczyna się tak samo: „chcemy, żeby stany się zgadzały". Kończy się pytaniem, dlaczego klient kupił trzy sztuki towaru, którego na półce leży jedna, a magazynier właśnie dzwoni do trzech osób z przeprosinami.
Między jednym a drugim jest kilka decyzji, które w małej firmie podejmuje się raz i żyje z nimi latami. Czy do sklepu leci stan fizyczny, czy ilość dostępna. Co się dzieje, gdy sklep przez dwie minuty nie odpowiada. Kto zauważy, że synchronizacja stanęła w czwartek o 3:40 nad ranem.
Ogólne drogi podpięcia Optimy i Subiekta pod automatyzacje opisałem wcześniej w osobnym tekście o integracji systemów handlowo-księgowych. Tutaj schodzę poziom niżej, do jednego scenariusza: Optima po jednej stronie, sklep internetowy po drugiej, stany i zamówienia w środku.
TL;DR: Masz trzy drogi: natywny Comarch e-Sklep (najmniej pracy, ale wybierasz też platformę sklepu), gotowy integrator do WooCommerce, PrestaShopa czy Shopera (abonament, konfiguracja zamiast kodu) albo własną integrację (najdroższa, uzasadniona przy nietypowej logice). Stany wysyłaj jako ilość dostępną, zamówienia ściągaj jako RO, a każdej nocy porównuj oba systemy.
Co naprawdę oznacza „synchronizacja stanów"
Zacznijmy od liczby, o którą toczy się cała gra. Optima rozróżnia stan fizyczny towaru i ilość dostępną, czyli, zgodnie z dokumentacją Comarch, ilość, jaką da się w danym momencie jeszcze wydać z magazynu. Ilość dostępna to stan pomniejszony o rezerwacje. Zamówienie od odbiorcy (dokument RO) taką rezerwację tworzy, więc każde ściągnięte ze sklepu zamówienie od razu obniża ilość dostępną w Optimie.
Ta jedna różnica odpowiada za większość oversellu, jaki widzę u klientów. Jeśli do sklepu leci stan fizyczny, magazyn przez cały dzień pokazuje towar, który jest już sprzedany i czeka tylko na spakowanie. Przy dwudziestu zamówieniach dziennie nikt tego nie zauważy. Przy dwustu w piątkowe popołudnie zauważy każdy, łącznie z klientami.
Druga decyzja to magazyn: firma z magazynem głównym, reklamacyjnym i ekspozycyjnym musi jednoznacznie ustalić, który z nich zasila sklep. Trzecia to bufor bezpieczeństwa, czyli odjęcie od wysyłanej ilości stałej wartości albo ukrycie produktu poniżej progu. Brzydkie obejście, które ratuje więcej zamówień niż niejedna integracja.
Trzy drogi połączenia Optimy ze sklepem
| Comarch e-Sklep / e-Sale | Gotowy integrator | Własna integracja | |
|---|---|---|---|
| Co to jest | sklep od Comarchu, zintegrowany fabrycznie | wtyczka lub usługa spinająca Optimę z Woo, Presta, Shoperem | łącznik pisany pod firmę |
| Czas uruchomienia | dni | dni do kilku tygodni | tygodnie do miesięcy |
| Model kosztu | abonament za sklep | abonament lub licencja | projekt + utrzymanie |
| Elastyczność logiki | ograniczona do parametrów | ograniczona do parametrów | pełna |
| Kto to utrzymuje | Comarch | dostawca integratora | Ty albo Twój wykonawca |
| Kiedy wybrać | budujesz sklep od zera | masz już sklep na popularnym silniku | logika, której gotowce nie obsługują |
Kolejność w tabeli jest też kolejnością sprawdzania. W większości projektów, które prowadzimy, własna integracja przegrywa z gotowcem na etapie liczenia, i dobrze. Programowanie łącznika, żeby przenosił zamówienia i stany w standardowy sposób, to płacenie za coś, co można wynająć za kilkaset złotych miesięcznie.
Droga 1: natywny Comarch e-Sklep i e-Sale
Comarch e-Sklep to platforma sklepowa producenta Optimy, zintegrowana z systemem fabrycznie. Do sklepu jadą towary, grupy, cenniki, stany magazynowe, ceny i rabaty, zestawy promocyjne, zdjęcia oraz kontrahenci. W drugą stronę wracają zamówienia (lądują na liście dokumentów RO), nowi kontrahenci oraz dane o płatnościach i dostawach.
Warunki wejścia są konkretne. Po stronie Optimy potrzebujesz modułów Kasa/Bank i Handel, stanowiska e-Sklep skonfigurowanego w gałęzi Konfiguracja Firmy/e-Handel, a każdy towar musi mieć zaznaczony parametr „Udostępniaj w Comarch e-Sklep", przypisanie do grupy i ustaloną cenę domyślną. Ten ostatni punkt jest źródłem klasycznej reklamacji „produkt nie pojawił się w sklepie": nie pojawił się, bo nikt nie odhaczył parametru na karcie.
Synchronizację odpalasz ręcznie z menu Handel, gdzie masz osobno „Wyślij ofertę do e-Sklepu", „Pobierz zamówienia", „Wyślij tylko ceny" i „Wymuś pełną synchronizację", albo automatycznie przez harmonogramy w Start/Konfiguracja/Program/Automat synchronizacji. Automat wymaga skonfigurowanej usługi Serwis Operacji Automatycznych po stronie stanowiska. Sprawdź to przed wdrożeniem, bo gałąź tej usługi nie jest dostępna w wersji usługowej programu, a każda zmiana parametrów automatu restartuje usługę na komputerze, na którym działa. Jeśli działa na innej maszynie, restart robisz tam ręcznie.
Cennik Comarch e-Sklep zaczyna się od 150 zł netto miesięcznie za plan Standard, 599 zł za Enterprise i 899 zł za wersję B2B, do tego dodatki w rodzaju powiadomień SMS za 55 zł miesięcznie czy certyfikatu SSL za 139 zł rocznie (ceny ze strony Comarchu, sierpień 2026). Osobnym produktem jest Comarch e-Sale, który wystawia towary z systemu ERP na Allegro, eBay i Amazon, rozliczany stałym abonamentem niezależnie od liczby aukcji.
Kiedy ta droga wygrywa: gdy sklepu jeszcze nie masz albo stoi na czymś, czego i tak zamierzasz się pozbyć. Kiedy przegrywa: gdy masz działający sklep z ruchem, pozycjami w Google i zespołem przyzwyczajonym do panelu. Migracja platformy to projekt zupełnie innej wagi niż integracja.
Droga 2: gotowy integrator
Jeśli sklep stoi na WooCommerce, PrestaShopie albo Shoperze, prawie na pewno istnieje gotowy łącznik do Optimy. Rynek jest gęsty: OpSync z integratory.pl, MegaIntegrator od CTI, SellIntegro, Astrabit, a także eCommerce Integrator dostępny na Comarch Marketplace. Zakres jest u wszystkich podobny: towary, ceny, stany, zamówienia, czasem zdjęcia i dokumenty sprzedaży.
Większość dostawców pracuje w modelu abonamentowym z okresem próbnym (integratory.pl daje 15 dni, Apilo 21 dni), więc realny test kosztuje tydzień pracy, nie budżet projektowy. Sprawdzają się w firmie, której proces mieści się w standardzie: jeden magazyn, jedna cena, jeden kanał, dokumenty sprzedaży wystawiane w Optimie.
Przy wyborze pytaj o cztery rzeczy, bo różnicują dostawców mocniej niż lista funkcji z ulotki:
- Częstotliwość i tryb. Czy stany lecą co kilka minut, czy raz na godzinę i czy da się to ustawić osobno dla każdego typu danych.
- Zachowanie przy błędzie. Co się dzieje z zamówieniem, którego nie udało się zapisać w Optimie: wisi w kolejce, wraca przy kolejnym przebiegu, czy znika z logu.
- Wymagania środowiskowe. Łączniki do Optimy potrzebują zwykle maszyny z Windowsem i dostępu do instalacji programu. Apilo wymaga Windows 10/11 albo Windows Server 2016 i nowszego oraz wolnych licencji na moduły Handel, Faktury i Kasa/Bank.
- Mapowanie pól. Czy poradzi sobie z Waszymi kodami EAN, wariantami i cenami netto/brutto bez dłubania przy każdym produkcie.
Droga 3: własna integracja i co Optima naprawdę udostępnia
Tu trzeba powiedzieć rzecz, którą sprzedawcy integracji zwykle pomijają: Optima nie ma otwartego REST API w takim sensie, w jakim ma je typowe narzędzie SaaS. Nie wystawia publicznego adresu, do którego wysyłasz token i zaczynasz pobierać stany. To, co Twoja instalacja udostępnia programistycznie, zależy od wersji, wariantu (stacjonarny kontra usługowy) i licencji, więc pierwsze pytanie kieruj do partnera Comarchu, nie do wykonawcy integracji.
Przy okazji dwa mity do wyprostowania. Hydra, o której czasem słyszy się w kontekście „API Comarchu", jest interfejsem programistycznym Comarch ERP XL, nie Optimy, i jest adresowana do partnerów po szkoleniu. Z kolei „praca rozproszona" w Optimie to mechanizm wymiany danych słownikowych i dokumentów plikami XML między działem sprzedaży a księgowością. Świetnie nadaje się do przerzucania dokumentów do biura rachunkowego, ale nie jest kanałem do aktualizowania stanów w sklepie co pięć minut.
Zostaje więc realnie: warstwa integracyjna udostępniona przez producenta w Waszej wersji, gotowa wtyczka partnera albo praca bezpośrednio na bazie SQL. Ta ostatnia kusi, bo jest najprostsza do napisania. Odczyt do raportu bywa akceptowalny, zapis to inna liga: pomijasz logikę biznesową programu, więc dokument potrafi powstać bez rezerwacji, bez poprawnego numeru albo bez wpisów w tabelach, o których nikt nie pamiętał. Comarch nie ma też obowiązku zachować struktury bazy między wersjami, a przy zgłoszeniu awarii pierwsze pytanie będzie brzmiało, kto pisał do bazy poza programem.
„Najdroższe integracje e-commerce, jakie widziałem, nie były drogie z powodu programowania. Były drogie, bo ktoś na starcie oszczędził na jednym: nocnym raporcie porównującym stany w sklepie i w ERP. Bez niego rozjazd wychodzi na jaw dopiero z reklamacji klienta, czyli w najdroższym możliwym momencie." — Mikołaj Brunka, założyciel NoCodeWork
Własną integrację buduj wtedy, gdy logika naprawdę wykracza poza standard: stany liczone z kilku magazynów po własnym wzorze, ceny zależne od kanału i grupy klienta, zamówienia rozbijane na kilka dokumentów, dropshipping z osobnym obiegiem. Poza tymi przypadkami zwykle przepłacasz za coś, co gotowiec robi w konfiguracji. O tym, jak podchodzić do systemów, które nie chcą rozmawiać po swojemu, pisaliśmy szerzej w tekście jak automatyzować, gdy narzędzie nie ma API.
Co synchronizować i jak często
Najczęstszy błąd konfiguracyjny to jeden wspólny harmonogram na wszystko. Dane mają różną wagę i różny koszt przesłania, więc rozdziel je.
| Dane | Kierunek | Rozsądna częstotliwość | Uwagi |
|---|---|---|---|
| Stany magazynowe | Optima → sklep | co 5–15 minut | wysyłaj tylko zmienione pozycje |
| Zamówienia | sklep → Optima | co 5–15 minut | jako RO, z identyfikatorem ze sklepu |
| Ceny i promocje | Optima → sklep | kilka razy dziennie lub na żądanie | promocje planuj z wyprzedzeniem |
| Nowe produkty i opisy | Optima → sklep | raz dziennie | opisy i zdjęcia rzadko są gotowe od razu |
| Statusy realizacji, numery przesyłek | Optima → sklep | co godzinę | to widzi klient, więc opóźnienie boli |
| Pełna synchronizacja kontrolna | obustronnie | raz na dobę, w nocy | porównanie, nie nadpisanie w ciemno |
Stany i zamówienia to jedna para: im częściej ściągasz zamówienia, tym szybciej rezerwacje obniżają ilość dostępną i tym mniej masz oversellu. Reszta może chodzić wolniej.
Nowe produkty świadomie odsuwam na dobowy cykl, bo karta towaru w Optimie powstaje zwykle wcześniej niż zdjęcia i opis, a produkt wypchnięty do sklepu w stanie surowym ląduje na liście „do poprawy", z której nikt go nie zdejmuje.
Kontrola nocna to nie kolejna pełna wysyłka, tylko porównanie dwóch list i raport rozbieżności. Przeładowywanie całego katalogu jako lekarstwo na rozjazd działa do dnia, w którym katalog przestaje mieścić się w nocnym oknie.
Pięć awarii, które zdarzają się naprawdę
1. Sklep chwilowo nie odpowiada. Aktualizacja wtyczki, restart hostingu, chwilowy limit zapytań. Integracja bez kolejki gubi wtedy pakiet danych i idzie dalej, jakby nic się nie stało. Minimum w każdym wdrożeniu: ponawianie z rosnącym odstępem, trwała kolejka nieprzesłanych zmian i alert po serii nieudanych prób. Pusty log powinien uruchamiać alarm, bo tak właśnie wygląda integracja, która umarła po cichu.
2. Rozjazd stanów po awarii. Po każdej dłuższej przerwie stany w obu systemach różnią się i nikt nie wie o ile. Stąd rekoncyliacja: nocne porównanie pary „kod towaru, ilość" po obu stronach i raport z listą różnic. Na start wystarczy sam raport, bo w małym katalogu różnic jest kilka. Automatyczne wyrównywanie dokładaj dopiero, gdy wiesz, która strona ma rację.
3. Duplikaty dokumentów. Klasyk: integracja pobrała zamówienie, utworzyła RO, po czym straciła połączenie przed zapisaniem informacji o sukcesie. Przy kolejnym przebiegu tworzy je drugi raz. Lekarstwem jest klucz idempotencji: numer zamówienia ze sklepu zapisany w dokumencie w Optimie i sprawdzany przed każdym utworzeniem. Bez tego dublety wracają przy każdej awarii sieci, a wykrywa je zwykle księgowość na koniec miesiąca.
4. Konfiguracja operatora i usługi w tle. Integracje po stronie Optimy pracują na koncie operatora i wymagają usługi działającej na konkretnej maszynie. Wygasłe hasło, zajęta licencja modułu, restart serwera bez wznowienia usługi: każda z tych rzeczy zatrzymuje wymianę bez efektownego komunikatu. W Comarch DMS analogiczne parametry ustawia się w zakładce autoryzacji API, a dokumentacja ostrzega wprost, że wystarczy spacja przed loginem albo po nim, żeby autoryzacja przestała działać. Tyle wystarczy, żeby zablokować wymianę na cały weekend.
5. Wydajność przy dużym katalogu. Przy kilkuset produktach wszystko działa. Przy kilkudziesięciu tysiącach pozycji z wariantami pełna wysyłka przestaje mieścić się w oknie, a sklep zaczyna zwracać błędy limitu. Wtedy potrzebujesz wysyłki różnicowej (tylko to, co się zmieniło), paczkowania zapytań i rozłożenia dużych operacji na noc. Jeśli częścią układanki jest arkusz Google, sprawdź wcześniej limity Google Sheets w automatyzacjach, bo to najczęstsze wąskie gardło w prowizorkach, które przerosły swoje założenia.
Kiedy Optima plus sklep to za mało
Para Optima–sklep spina się elegancko dopóty, dopóki sklep jest jedynym kanałem. Wystarczy dołożyć Allegro, Erli albo Amazon i model się sypie, bo ten sam stan magazynowy obsługuje teraz kilka niezależnych kanałów, z których każdy ma własne tempo, własny format zamówienia i własne wymagania wysyłkowe.
Wtedy centralnym punktem sprzedaży staje się integrator: Baselinker, Apilo albo Comarch e-Sale, jeśli chcecie zostać w ekosystemie producenta. Optima zostaje przy dokumentach, magazynie i księgowości, a integrator bierze na siebie kanały i wysyłki. Porównanie tego podejścia z budowaniem własnych workflow opisaliśmy w tekście Baselinker czy n8n w polskim e-commerce.
Granicę widać najlepiej w rachunku. Przy kilkuset zamówieniach miesięcznie abonament integratora jest tańszy niż jeden dzień pracy programisty. Przy kilku tysiącach i rosnących progach cennika opłacalność się odwraca, a wtedy wraca pytanie o własne rozwiązanie: kiedy ma sens i ile kosztuje, rozpisaliśmy w artykule o własnym panelu zamówień.
Na co uważać
- Zła kolejność prac. Zdublowane indeksy, brakujące kody EAN, ceny wpisywane ręcznie na dokumencie: to trzeba uporządkować przed uruchomieniem, bo potem poprawia się w dwóch systemach naraz.
- Testy na produkcji. Każdą integrację uruchamiamy najpierw na kopii bazy. Źle zmapowane pole tworzy kilkaset dokumentów szybciej, niż ktokolwiek zdąży kliknąć „stop".
- Brak właściciela procesu. Ktoś musi rano sprawdzać, czy nocna synchronizacja przeszła. Jeśli takiej osoby nie ma, dołóż alert na czat albo SMS, bo mail z błędem nie ma szans.
- Aktualizacje po obu stronach. Optima aktualizuje się kilka razy w roku, sklep i wtyczki znacznie częściej. Ustal z dostawcą, kto testuje integrację po aktualizacji i w jakim czasie reaguje na awarię.
- Kiedy to zły pomysł. Przy kilkunastu zamówieniach miesięcznie i katalogu na kilkadziesiąt pozycji integracja bywa droższa niż ręczne wprowadzanie. Policz godziny, zanim zamówisz projekt.
- Faktury i KSeF osobno. Nie doklejaj do integracji sklepowej całego obiegu faktur. To odrębny proces z własnymi terminami, opisany w tekście o KSeF i automatyzacji obiegu faktur.
FAQ
Czy Comarch ERP Optima ma API do integracji ze sklepem internetowym?
Optima nie udostępnia otwartego, publicznego REST API w takim sensie, w jakim mają je narzędzia chmurowe. Integracje realizuje się przez natywną wymianę z Comarch e-Sklep i e-Sale, przez gotowe łączniki partnerów albo na możliwościach konkretnej wersji programu. Zakres zależy od wersji, wariantu instalacji i licencji, więc potwierdź go u partnera Comarchu przed zamówieniem wdrożenia.
Jak często synchronizować stany magazynowe między Optimą a sklepem?
Stany i zamówienia co 5–15 minut, ceny kilka razy dziennie, nowe produkty raz na dobę, a w nocy pełne porównanie kontrolne obu systemów. Częstsza wymiana stanów ma sens tylko wtedy, gdy równie często ściągasz zamówienia, bo to one tworzą rezerwacje obniżające ilość dostępną w Optimie.
Dlaczego sklep sprzedaje towar, którego nie ma na magazynie?
Najczęściej dlatego, że do sklepu leci stan fizyczny zamiast ilości dostępnej, czyli stanu pomniejszonego o rezerwacje. Drugi powód to zbyt rzadka synchronizacja przy dużym ruchu, trzeci to sprzedaż w kilku kanałach bez wspólnego zarządzania stanem. Zacznij od sprawdzenia, którą liczbę wysyła Wasza integracja.
Comarch e-Sklep czy WooCommerce z integratorem?
Jeśli sklepu jeszcze nie masz albo i tak planujesz zmianę platformy, e-Sklep jest wygodny: integracja z Optimą jest fabryczna i nie utrzymujesz jej sam. Przy działającym sklepie z ruchem i pozycjami w wyszukiwarce taniej wychodzi dołożyć gotowy integrator, bo migracja platformy to osobny projekt o zupełnie innej skali ryzyka.
Czy można zapisywać dane do sklepu bezpośrednio z bazy SQL Optimy?
Odczyt do raportów bywa akceptowalny, zapis z pominięciem programu jest ryzykowny. Omijasz logikę biznesową Optimy, więc dokumenty potrafią powstać niekompletne, struktura bazy może zmienić się przy aktualizacji, a przy zgłoszeniu problemu wsparcie zapyta, kto pisał do bazy poza programem. Jeżeli nie ma innej drogi, ogranicz się do odczytu.
Podsumowanie
Synchronizacja Optimy ze sklepem rzadko rozbija się o technologię. Rozbija się o trzy decyzje podjęte po łebkach: którą liczbę wysyłamy do sklepu, co się dzieje, gdy jedna ze stron milczy, i kto rano sprawdza, że wszystko przeszło. Firmy, które mają to ustawione, żyją z integracją latami bez emocji, niezależnie od tego, czy stoi na e-Sklepie, gotowym integratorze, czy na własnym łączniku.
Kolejność jest prosta. Najpierw uporządkuj kartoteki i ustal, który magazyn zasila sklep. Potem przetestuj gotowe rozwiązanie na okresie próbnym, bo tydzień testu kosztuje mniej niż tydzień analizy. Do własnej integracji siadaj dopiero wtedy, gdy potrafisz jednym zdaniem nazwać to, czego gotowiec nie umie.
Chcesz ustalić, która droga pasuje do Waszego katalogu i liczby zamówień? Umów bezpłatną konsultację — powiemy wprost, jeśli w Waszym przypadku wystarczy gotowy integrator za kilkaset złotych miesięcznie i żadne wdrożenie nie jest potrzebne.
