Integracja awizacji dostaw z Comarch ERP XL i enova365

Autor: Adam Siemiątkowski, SoftwareStudio Group Sp. z o.o.

Numer zamówienia i dane kontrahenta powstają w ERP, więc awizacja nie powinna ich wpisywać od nowa. Informacja o faktycznym przebiegu rozładunku powstaje w systemie awizacji i musi wrócić do dokumentu przyjęcia. Integracja obejmuje oba kierunki.

Ogólny opis wymiany z ERP i WMS zawiera artykuł integracja ERP z systemem awizacji. Ta strona zawęża temat do Comarch ERP XL i enova365, a mechanizmy pokazuje na poziomie bazy danych.

Jakie dane wymieniają awizacja i ERP

Zakres wymiany ustala specyfikacja integracji. Poniższa tabela pokazuje typowy układ, który potwierdza się z działem logistyki i dostawcą ERP.

Studio VSS.net

Numer dokumentu i numer zamówienia w awizacji

Zakładka Dane ewidencyjne zawiera numer dokumentu i numer zamówienia. W projekcie integracyjnym te pola wypełnia ERP, a nie użytkownik portalu.

Jeśli obiekt korzysta z własnego WMS, ta sama warstwa wymiany obsługuje przyjęcia. Opis połączenia z magazynem znajduje się w artykule jak VSS łączy się z WMS i ERP, a własny system magazynowy producenta to Studio WMS.net.

Które systemy ERP obsługujemy i w jakim stanie

Poniższa tabela rozróżnia integracje wdrożone od tych, które realizujemy jako projekt po analizie. Dla systemów bez gotowego konektora wskazuje, kto dostarcza interfejs.

Doświadczenie wdrożeniowe deklarujemy tylko tam, gdzie istnieje zakończona integracja. Dla pozostałych systemów opisujemy mechanizm i przyjmujemy, że wiążący zakres powstaje po otrzymaniu dokumentacji interfejsu.

Comarch ERP XL - API producenta i licencje stanowiskowe

Zapis do Comarch ERP XL idzie wyłącznie przez API producenta. Dzięki temu numeracja dokumentów i walidacje ERP nie są omijane, a aktualizacja wersji XL nie psuje integracji. API działa na maszynie z systemem Windows, na której zainstalowano klienta XL, i zużywa licencję stanowiskową.

• Zapis - dokumenty tworzone wyłącznie przez CDN_API, bez bezpośrednich instrukcji INSERT do tabel ERP.
• Odczyt - zapytania SQL wykonywane kontem bazy z uprawnieniem tylko do odczytu.
• Licencje - logowanie do ERP na czas jednej paczki dokumentów i wylogowanie po niej, co oszczędza współbieżne licencje XL.
• Sieć - usługa działa w sieci klienta i nawiązuje wyłącznie połączenia wychodzące przez HTTPS, więc nie wymaga otwarcia portu z Internetu.

Brak publikowanego punktu dostępowego ma znaczenie przy wymaganiach dyrektywy NIS2. Licencje XL oraz prace po stronie dostawcy ERP leżą po stronie klienta, a dopóki dostawca nie udostępni dokumentacji interfejsu, szacunek czasu zawiera margines niepewności.

Dla Comarch ERP Optima wymianę planujemy przez Sferę. Licencję Sfery kupuje klient, a wariant Optimy w chmurze Comarch ma ograniczenia, które sprawdzamy w analizie.

Kolejka wymiany z ponawianiem i brak duplikatów

Połączenie z ERP bywa niedostępne, na przykład po restarcie usługi albo w oknie serwisowym. Komunikat do ERP nie może wtedy zniknąć ani zostać wysłany dwa razy. Rozwiązuje to tabela wysyłkowa, nazywana w literaturze wzorcem outbox.

Komunikat do ERP powstaje w tej samej transakcji co zmiana statusu awizacji. Bez tego awaria między zapisem a wysyłką zostawia status bez komunikatu albo komunikat bez statusu.

Każdy komunikat dostaje unikalny identyfikator, a proces wysyłający ponawia próbę do czasu potwierdzenia. Po wznowieniu łączności ERP nie tworzy drugiego dokumentu, bo rozpoznaje powtórzony identyfikator. Kilka procesów wysyłających może pracować równolegle, ponieważ każdy pobiera tylko wiersze, których nie zablokowała inna sesja.

-- SQL Server (T-SQL): pobranie partii komunikatów do wysłania do ERP
SELECT TOP (50) Id, MessageId, Payload
FROM dbo.OutboxErp WITH (UPDLOCK, READPAST, ROWLOCK)
WHERE Status = 'oczekuje'
ORDER BY Priority DESC, Id;

-- PostgreSQL (platforma GT): ta sama operacja
SELECT id, message_id, payload
FROM outbox_erp
WHERE status = 'oczekuje'
ORDER BY priority DESC, id
LIMIT 50
FOR UPDATE SKIP LOCKED;

Oba zapytania są uproszczonym przykładem wzorca, a nazwy tabel mają charakter poglądowy. Działanie wskazówek blokad opisuje dokumentacja wskazówek tabelowych T-SQL oraz klauzula FOR UPDATE w PostgreSQL.

Na platformie StudioSystemGT kroki wymiany zapisuje się w silniku RunSteps jako pliki YAML, a zapytania jako wersjonowane codeSQL. Zmiana mapowania pola polega więc na podmianie pliku konfiguracji, bez restartu i bez okna serwisowego.

enova365 - warstwa XML i REST

Dla enova365 nie mamy gotowego konektora. Wymianę budujemy na warstwie XML i REST, którą steruje się parametrami: nowa integracja oznacza nowy wiersz konfiguracji, a nie nowy kod. Każde wywołanie zapisuje się w pełnym logu wymiany, dzięki czemu błąd mapowania da się odtworzyć.

Zakres interfejsu enova365 oraz ewentualne moduły dodatkowe ustala partner enova. Do projektu potrzebujemy od niego opisu dostępnych metod i konta w środowisku testowym.

Studio VSS.net

Kartoteka kontrahentów synchronizowana z ERP

Lista kontrahentów w kartotekach portalu. W projekcie integracyjnym kod i nazwa kontrahenta pochodzą z ERP, więc kartoteka nie rozchodzi się z systemem finansowym.

Microsoft Dynamics 365 i Dataverse

Dla Dynamics 365 przewidujemy wymianę przez Dataverse Web API z uwierzytelnianiem aplikacyjnym w Microsoft Entra ID. Integracja działa wtedy bez konta interaktywnego, a uprawnienia nadaje się aplikacji, nie osobie. Specyfikację interfejsu opisuje dokumentacja Dataverse Web API.

To opis mechanizmu, a nie zapowiedź gotowego produktu. Wdrożenie przebiega jako osobny projekt, który zaczyna się od specyfikacji.

Przebieg i koszt projektu integracyjnego

Projekt zaczyna się od specyfikacji technicznej z mapowaniem pól. Dopiero po niej zespół otrzymuje dokumentację interfejsu i dostęp do środowiska testowego, więc czas całości zależy od dostawcy ERP.

Orientacyjną pracochłonność integracji z ERP, systemem finansowo-księgowym i SAP podaje cennik systemu awizacji. Miejsce integracji w całym wdrożeniu opisuje artykuł o wdrożeniu systemu awizacji etapami, a wymagania infrastrukturalne strona o wymaganiach technicznych.