Dwa systemy i dwie wersje tego samego zamówienia – to najczęstszy objaw źle zaprojektowanej integracji SugarCRM z ERP. Dział handlowy widzi zamówienie ze statusem „w realizacji”, księgowość już wystawiła fakturę korygującą, a magazyn pracuje na trzeciej wersji ilości. Problemem rzadko jest sama technologia synchronizacji – najczęściej brakuje jasnej odpowiedzi na pytanie, który system jest właścicielem którego rekordu na danym etapie jego cyklu życia.

Duplikaty w integracji SugarCRM z ERP (Comarch, SAP, Symfonia) powstają najczęściej z jednego powodu: oba systemy mogą niezależnie utworzyć ten sam rekord, a mechanizm synchronizacji nie ma jednoznacznego identyfikatora pozwalającego rozpoznać, że chodzi o ten sam obiekt biznesowy. Handlowiec zapisuje zamówienie w SugarCRM, a magazynier wprowadza je ręcznie do ERP, zanim synchronizacja zdąży zadziałać – w efekcie powstają dwa rekordy zamiast jednego.

Problem pogłębia się przy synchronizacji dwukierunkowej bez jasnych reguł kolejności zapisu. Jeśli SugarCRM i ERP mogą jednocześnie aktualizować to samo pole – na przykład status zamówienia – a integracja nie ma logiki rozstrzygania konfliktów, końcowy stan zależy od tego, który system zapisał zmianę jako ostatni, a nie od tego, który zapis jest merytorycznie poprawny. To źródło większości „cichych” błędów, które ujawniają się dopiero przy rozbieżności w raportach sprzedażowych lub finansowych.

Model własności danych określa, który system jest jedynym źródłem prawdy dla danego typu rekordu na danym etapie jego cyklu życia – i to jest pierwszy krok do wykonania przed jakąkolwiek konfiguracją techniczną integracji. W praktyce sprawdza się podział, w którym SugarCRM jest właścicielem zamówienia od momentu jego utworzenia do chwili przekazania do realizacji, a ERP (Comarch, SAP lub Symfonia) przejmuje własność od momentu wystawienia dokumentu magazynowego lub faktury.

Przekazanie własności nie oznacza zniknięcia rekordu z drugiego systemu – oznacza, że tylko jeden system ma prawo go modyfikować, a drugi wyłącznie go odczytuje i wyświetla. SugarCRM po przekazaniu zamówienia do ERP powinien blokować handlowcowi edycję pozycji zamówienia i pokazywać status pobrany z ERP jako pole tylko do odczytu. To eliminuje najczęstszy scenariusz prowadzący do duplikacji: równoległą edycję tego samego rekordu w dwóch miejscach jednocześnie.

Ten sam podział własności trzeba osobno zdefiniować dla faktury i dla korekty faktury – to dwa różne obiekty biznesowe, które często są traktowane w integracji jak jeden typ rekordu. Faktura pierwotna zwykle powstaje wyłącznie w ERP i trafia do SugarCRM jako rekord tylko do odczytu, natomiast informacja o jej statusie płatności powinna wracać do SugarCRM, żeby dział handlowy widział ją bez logowania się do systemu finansowo-księgowego.

Techniczne uniknięcie duplikatów wymaga trzech elementów działających razem: zewnętrznego identyfikatora przechowywanego w obu systemach, logiki idempotencji przy każdym zapisie oraz jednoznacznej kolejności operacji w warstwie integracyjnej. Zewnętrzny identyfikator (external ID) to pole w SugarCRM przechowujące ID rekordu z ERP i odwrotnie – dzięki niemu integracja przed utworzeniem nowego rekordu zawsze najpierw sprawdza, czy odpowiednik już istnieje.

Idempotencja oznacza, że wielokrotne przesłanie tej samej operacji synchronizacji – na przykład po błędzie sieci i automatycznym ponowieniu – nie tworzy kolejnej kopii rekordu, tylko aktualizuje istniejący. W praktyce wymaga to, aby każda transakcja synchronizacji miała unikalny klucz transakcyjny, a warstwa integracyjna sprawdzała ten klucz przed zapisem. Dla organizacji korzystających z Comarch ERP, SAP lub Symfonii mechanizm ten wygląda podobnie — różni się głównie sposobem wystawiania i odbierania zapytań API lub webhooków przez każdy z tych systemów.

Mechanizm zapobiegania duplikatom jest ten sam niezależnie od wybranego ERP, ale sposób jego wdrożenia różni się w zależności od dostępnego interfejsu integracyjnego. Poniższa tabela pokazuje główne różnice, które wpływają na wybór architektury integracji dla każdego z trzech systemów.

ERP	Interfejs integracyjny	Typowe wyzwanie przy synchronizacji
Comarch ERP (XL / Optima)	API REST w Comarch ERP XL; w Comarch ERP Optima częściej eksport/import plików	Optima nie zawsze udostępnia webhooki w czasie rzeczywistym – zwykle wymaga synchronizacji cyklicznej
SAP (Business One / S/4HANA)	SAP Business One API, OData Service Layer	Rozbudowany model danych SAP wymaga precyzyjnego mapowania pól już na etapie projektowania
Symfonia	API REST w wersji chmurowej; starsze instalacje on-premise – pliki wymiany	Starsze wdrożenia on-premise mogą nie mieć nowoczesnego API – potrzebna warstwa pośrednia

Niezależnie od wybranego ERP, im starsza wersja systemu i im mniej rozwinięte jego natywne API, tym większe znaczenie ma warstwa pośrednia (middleware) – nie tylko jako most techniczny, ale jako miejsce, w którym fizycznie egzekwowana jest logika idempotencji i reguły własności danych opisane wyżej.

• Brak jednoznacznego właściciela pola. Jeśli status zamówienia może być edytowany zarówno w SugarCRM, jak i w ERP, prędzej czy później pojawi się rozbieżność, którą trudno wytłumaczyć bez przeglądania logów integracji.
• Synchronizacja bez logiki ponawiania i idempotencji. Każdy błąd sieciowy bez odpowiedniej obsługi kończy się duplikatem, a nie powtórzeniem tej samej operacji.
• Mapowanie pól „na oko”, bez dokumentacji. Różnice w strukturze danych między SugarCRM a Comarch, SAP czy Symfonią – na przykład inny format statusów zamówienia – prowadzą do cichych błędów mapowania, które ujawniają się dopiero w raportach finansowych.
• Testowanie integracji bezpośrednio na danych produkcyjnych. Brak osobnego środowiska testowego to najszybsza droga do duplikatów, których nie da się łatwo cofnąć bez ryzyka utraty innych, poprawnych zmian.
• Ignorowanie przypadków brzegowych: anulowane zamówienia, korekty faktur, częściowa realizacja dostawy. Integracja zaprojektowana tylko pod „szczęśliwą ścieżkę” (nowe zamówienie → faktura) zawodzi przy pierwszej korekcie lub anulacji.

Projektowanie integracji SugarCRM z ERP (Comarch, SAP lub Symfonia) zaczyna się nie od wyboru narzędzia integracyjnego, tylko od decyzji, kto jest właścicielem którego rekordu na każdym etapie jego cyklu życia. Techniczne mechanizmy – zewnętrzne identyfikatory, idempotencja, logika konfliktów – mają sens dopiero wtedy, gdy ten podział jest jasny i spisany, a nie ustalany ad hoc przy każdym zgłoszeniu błędu.

Zanim zlecisz zespołowi IT budowę integracji, zadaj sobie jedno pytanie: czy potrafisz jednoznacznie wskazać, który system ma „ostatnie słowo” w sprawie statusu każdego zamówienia – i czy ta odpowiedź jest taka sama dla działu handlowego, księgowości i magazynu?

Jeśli zainteresował Cię ten temat, skontaktuj się z nami. Chętnie odpowiemy na Twoje pytania.