Integracja ENOVA z systemem magazynowym - harmonogram i obsługa błędów

Integracja ENOVA z systemem magazynowym Studio WMS.net opiera się na tym, że obie aplikacje działają na serwerze bazodanowym Microsoft SQL Server. Według opisu wymiana istotnych informacji odbywa się online na poziomie bazy MS SQL i obejmuje kartoteki towarowe i kontrahentów oraz dokumenty magazynowe. ENOVA jest systemem ERP firmy Soneta z Krakowa.

Artykuł nie powtarza opisu modułu magazynowego enova365 ani zasad jego konfiguracji, które znajdują się w tekstach o module Handel i Magazyn oraz o dostosowaniu enova365 do firmy. Skupia się na mechanizmie: jak przekazuje się kartoteki, jak wędrują dokumenty, kiedy działa harmonogram i co dzieje się z błędem. Nazwy tabel i procedur w przykładach są ilustracją i nie opisują struktury baz żadnego z systemów.

Integracja ENOVA z WMS - zakres wymiany na poziomie bazy

Wspólny serwer SQL pozwala pominąć pliki pośrednie. Dane trafiają do drugiej strony po zatwierdzeniu transakcji, bez eksportu do CSV i importu z katalogu. Zaleta jest oczywista: nie ma opóźnienia wynikającego z cyklu plikowego, a każdy system zna stan drugiego zaraz po zapisie. Cena to sprzężenie wersji. Zmiana modelu danych po aktualizacji ERP może zmienić widoki i zapytania, z których korzysta integracja, dlatego przy każdej aktualizacji powtarza się testy wymiany na kopii bazy. Zasady takich testów opisuje artykuł o programie enova ERP.

Wymiana dotyczy kilku obiektów, a każdy z nich ma własny kierunek i klucz dopasowania. Poniższy podział jest typowy dla połączenia ERP z systemem magazynowym i wymaga potwierdzenia w projekcie konkretnego wdrożenia.

Reguła: odczyt z bazy ERP wykonuje się przez widoki lub konto tylko do odczytu, a zapis ścieżką dopuszczoną przez producenta ERP. Bezpośredni INSERT do tabel ERP omija jego kontrole spójności.

Wymianę przez bazę porównuje się zwykle z wariantem opartym na interfejsie API i kolejkach komunikatów, który opisuje artykuł o integracji WMS z ERP. Oba podejścia rozwiązują ten sam problem, ale różnią się miejscem, w którym leży kontrola poprawności danych.

Kartoteki towarowe i kontrahenci - klucze i zmiany przyrostowe

Najczęstszy błąd wymiany kartotek to źle dobrany klucz. Jeśli WMS rozpoznaje towar po symbolu, a magazynier lub handlowiec zmieni symbol w ERP, po drugiej stronie powstanie nowa kartoteka i stara zostanie z historią stanów. Dlatego do dopasowania używa się stałego identyfikatora technicznego. Symbol i EAN służą wtedy tylko do wyszukiwania. Jednostki miary wymagają osobnej uwagi: przelicznik opakowania zbiorczego na sztuki musi być taki sam po obu stronach, inaczej przyjęcie dwunastu kartonów daje w ERP dwanaście sztuk. Szersze omówienie danych podstawowych znajduje się w artykule o kartotekach magazynowych.

Kartotek nie przesyła się w całości przy każdym przebiegu. Wystarczy przekazać tylko rekordy zmienione od ostatniej synchronizacji, a moment ostatniego przebiegu zapisać w tabeli pomocniczej, tak zwanym znaczniku granicznym.

DECLARE @od datetime2 =
    (SELECT ostatnia_synchronizacja FROM dbo.wymiana_stan WHERE obiekt = 'kartoteka');

SELECT t.id_techniczny, t.symbol, t.nazwa, t.ean, t.jednostka, t.data_modyfikacji
FROM erp.dbo.towar_widok AS t
WHERE t.data_modyfikacji >= @od
ORDER BY t.data_modyfikacji;

Warunek z operatorem większe lub równe jest celowy. Dwie zmiany mogą mieć identyczny znacznik czasu, a granica ustawiona ostro pominęłaby drugą. Powtórne przetworzenie tego samego rekordu nie szkodzi, jeśli zapis po stronie docelowej jest operacją typu upsert, na przykład instrukcją MERGE opisaną w Microsoft Learn. Znacznik graniczny aktualizuje się dopiero po zatwierdzeniu całej partii, żeby przerwany przebieg powtórzył pracę zamiast ją zgubić.

Zamówienia oraz dokumenty PZ i WZ - cykl i statusy

Dokumenty przekazuje się przez tabelę pośrednią, w której jeden wiersz opisuje jedno zdarzenie do przekazania. Dzięki niej nadawca nie czeka na odbiorcę, a odbiorca może przetwarzać zdarzenia we własnym tempie. Unikalny klucz na parze typ dokumentu i numer źródłowy zapobiega utworzeniu dwóch wierszy dla tego samego dokumentu. Mechanizm odrzucania powtórek opisano szerzej w artykule o programie enova ERP.

CREATE TABLE dbo.kolejka_wymiany (
    id            bigint IDENTITY PRIMARY KEY,
    typ           varchar(20)   NOT NULL,      -- 'PZ', 'WZ', 'ZAMOWIENIE'
    klucz_zrodla  varchar(50)   NOT NULL,      -- numer dokumentu w systemie źródłowym
    status        varchar(12)   NOT NULL DEFAULT 'nowy',
    proby         tinyint       NOT NULL DEFAULT 0,
    blad          nvarchar(400) NULL,
    utworzono     datetime2     NOT NULL DEFAULT SYSDATETIME(),
    CONSTRAINT uq_kolejka UNIQUE (typ, klucz_zrodla)
);

Cykl przyjęcia zaczyna się od zamówienia zakupu w ERP, które trafia do WMS jako oczekiwana dostawa. Magazynier skanuje towar, a po zakończeniu przyjęcia WMS zapisuje w kolejce potwierdzone PZ z ilością rzeczywistą. Dostawa częściowa daje kilka dokumentów PZ do jednego zamówienia, więc ERP musi umieć łączyć je z jednym źródłem. Cykl wydania działa odwrotnie: zamówienie sprzedaży tworzy zlecenie kompletacji, a potwierdzone WZ zamyka rezerwację w ERP. Korekty wymagają osobnego traktowania. Korekta ilościowa wydania nie jest zwykłym zdarzeniem nowego typu, lecz dokumentem powiązanym z pierwotnym, więc w kolejce zapisuje się typ korekty i klucz dokumentu wyjściowego. Bez niego odbiorca nie ustali, którą warstwę wyceny ma skorygować. Typy dokumentów i ich obieg opisuje artykuł o dokumentach magazynowych w WMS, a skutek dla ilości omawia tekst o stanach magazynowych.

Harmonogram wymiany - tryb cykliczny i okna zamknięć

Słowo online bywa rozumiane na trzy sposoby, a każdy z nich daje inny profil ryzyka. Wybór zależy od tego, jak szybko druga strona musi widzieć zmianę i jak bardzo wolno ją uzależnić od dostępności partnera.

Zadanie cykliczne jest najbezpieczniejszym kompromisem, bo przerwa w łączności nie zatrzymuje pracy magazynu. Na serwerze SQL uruchamia je usługa SQL Server Agent. Wersja Express nie zawiera tej usługi, więc zadanie zastępuje harmonogram systemu Windows albo usługa działająca w aplikacji. Poniższy przykład tworzy zadanie wywołujące procedurę przetwarzającą kolejkę co pięć minut. Mechanizm opisuje dokumentacja SQL Server Agent w Microsoft Learn.

EXEC msdb.dbo.sp_add_job @job_name = N'Wymiana_ERP_WMS';

EXEC msdb.dbo.sp_add_jobstep @job_name = N'Wymiana_ERP_WMS',
     @step_name = N'Przetworz kolejke', @subsystem = N'TSQL',
     @command = N'EXEC dbo.przetworz_kolejke_wymiany;', @database_name = N'WMS';

EXEC msdb.dbo.sp_add_jobschedule @job_name = N'Wymiana_ERP_WMS', @name = N'Co 5 minut',
     @freq_type = 4, @freq_interval = 1, @freq_subday_type = 4, @freq_subday_interval = 5;

EXEC msdb.dbo.sp_add_jobserver @job_name = N'Wymiana_ERP_WMS';

Reguła: dokument z okresu zamkniętego w ERP nie jest ponawiany automatycznie. Trafia do kolejki błędów z kodem przyczyny, a decyzję podejmuje osoba odpowiedzialna za księgi.

Obsługa błędów wymiany - ponawianie i uzgadnianie stanów

Błędy wymiany dzielą się na dwie klasy, które wymagają odmiennej reakcji. Błąd przejściowy zniknie sam po chwili, a trwały wymaga interwencji i ponawianie go tylko zaśmieca kolejkę. Klasyfikacja na podstawie kodu błędu SQL Server i treści komunikatu pozwala procedurze zdecydować, czy wystarczy ponowić próbę.

BEGIN TRY
    EXEC dbo.zapisz_dokument_w_erp @id_kolejki = @id;
    UPDATE dbo.kolejka_wymiany SET status = 'przetworzony' WHERE id = @id;
END TRY
BEGIN CATCH
    UPDATE dbo.kolejka_wymiany
    SET proby  = proby + 1,
        blad   = LEFT(ERROR_MESSAGE(), 400),
        status = CASE WHEN ERROR_NUMBER() = 1205 AND proby < 5
                      THEN 'nowy' ELSE 'blad' END
    WHERE id = @id;
END CATCH;

Ponawianie nie zastępuje uzgadniania. Nawet poprawnie działająca kolejka może zostawić różnicę, na przykład po ręcznej korekcie w jednym systemie. Dlatego raz na dobę porównuje się stany towarów po obu stronach i pomija pozycje, które mają nierozliczone wiersze w kolejce, bo ich różnica jest oczekiwana. Pozostałe rozbieżności wskazują błąd wymiany albo operację wykonaną poza integracją i wymagają wyjaśnienia jeszcze tego samego dnia.

Numery seryjne i CRM.net - dodatkowe kanały wymiany

Studio SN2Enova i numery seryjne

Ewidencja numerów seryjnych w programie ERP enova ułatwia zarządzanie magazynem i obsługę klientów. Program pozwala rejestrować numery przy przyjęciu towaru i prowadzić stany dla produktów z numerami, dzięki czemu widać, ile sztuk z konkretnym numerem leży w magazynie. Integracja z aplikacją Studio SN2Enova, czyli Serial Number to Enova, działa na danych pobranych z systemu enova. Dane odczytuje się metodą Read Only, co chroni bazę ERP przed zmianą. Aplikacja rejestruje numery seryjne urządzeń w powiązaniu z dokumentami magazynowymi pobranymi z enova. Skanowanie numeru opisuje artykuł o skanowaniu numeru seryjnego.

Odczyt tylko do odczytu jest własnością konta bazodanowego, a nie samej aplikacji. Konto usługi otrzymuje rolę czytającą i jawny zakaz zapisu, więc błąd w programie nie zmieni danych ERP. Poniższy przykład pokazuje taką konfigurację.

CREATE USER sn2enova_odczyt FOR LOGIN sn2enova_odczyt;
ALTER ROLE db_datareader ADD MEMBER sn2enova_odczyt;
DENY INSERT, UPDATE, DELETE ON SCHEMA::dbo TO sn2enova_odczyt;

CRM.net i wspólne kartoteki

W obszarze CRM SoftwareStudio oferuje integrację z programem enova w zakresie wspólnej bazy kartotek kontrahentów i pracowników oraz oznaczeń MPK. Istnieje też możliwość przekazywania danych o wynagrodzeniach do list płac pracowników, których ewidencja prowadzona jest w module CRM.net. Kontrahent pozostaje wtedy jednym rekordem z jednym właścicielem, a MPK działa jak słownik, którego wartości utrzymuje ERP. Podział ról przy wielu systemach omawia artykuł o integracjach programu WMS z innymi systemami.

Uruchomienie integracji - testy i odbiór

Odbiór integracji opiera się na scenariuszach z danymi firmy, a nie na pokazie danych przykładowych. Cztery scenariusze pokrywają główne ryzyka i warto je wykonać na kopii bazy, zanim wymiana ruszy na produkcji.

1. Test kartotek - przebieg wsadowy na kopii bazy i porównanie liczby rekordów oraz losowej próby pól po obu stronach.
2. Test przyjęcia - dostawa kompletna oraz częściowa, także z nadwyżką, z kontrolą dokumentów PZ w ERP.
3. Test wydania - zamówienie z pełną i niepełną kompletacją oraz korektą po WZ.
4. Test awarii - wyłączenie drugiej strony na czas przetwarzania i sprawdzenie, czy kolejka ponawia, a nie duplikuje.

Osobne konta usługowe dla każdego kierunku wymiany upraszczają diagnozę. Gdy błąd pojawia się w dzienniku serwera, nazwa konta od razu wskazuje, czy zapis pochodzi z przekazywania kartotek, czy z potwierdzania dokumentów magazynowych. Hasła kont przechowuje się poza kodem zadań, a zakres uprawnień ogranicza do obiektów, które dana część integracji faktycznie wykorzystuje.

Po każdej aktualizacji ERP te same scenariusze wykonuje się ponownie i porównuje wynik z poprzednim przebiegiem. Podobny układ wymiany dla innego programu księgowo-handlowego pokazuje artykuł o wymianie dokumentów WMS z Wapro. Opis systemu i jego modułów udostępnia producent na stronie enova.pl, a Studio WMS.net prezentuje serwis SoftwareStudio.