Integracja ERP z systemem magazynowym: jakie dane wymieniać

Dlaczego spójność danych między ERP a magazynem decyduje o integracji

Integrację ERP z systemem magazynowym (WMS) zaczyna się od katalogu wymienianych danych, a nie od wyboru technologii łączącej systemy. Rozproszone informacje — w różnych systemach albo na papierze — powodują błędy, duplikację i brak pełnego obrazu sytuacji. Opóźniają decyzje i obniżają efektywność.

Bez bieżącego, dokładnego wglądu w dostępne zapasy pojawiają się niedobory albo nadmierne gromadzenie towaru. Skutek to dodatkowe koszty i utrudniona realizacja zamówień. Gdy WMS, ERP, TMS i e-commerce działają niezależnie, powstają silosy informacyjne, które uniemożliwiają spójne zarządzanie łańcuchem dostaw.

Dlatego przed integracją trzeba odpowiedzieć na trzy pytania dla każdego zbioru danych: kto jest jego źródłem (ERP czy WMS), w którym kierunku on płynie i z jaką częstotliwością — zdarzeniowo czy według harmonogramu. Bez tego ustalenia dwa systemy policzą ten sam fakt niezależnie, np. stan magazynowy albo ilość przyjętą, i żaden wynik nie będzie wiarygodny.

Na polskim rynku działa system klasy ERP Grupy Kapitałowej Comarch SA, z którego korzysta prawie 3700 firm z różnych branż, w tym przedsiębiorstwa produkcyjne. Obecna jest także Symfonia, wdrażana m.in. w firmach wielooddziałowych.

Co ERP wysyła do systemu magazynowego, a co WMS odsyła do ERP

Podział danych wynika z podziału procesów. ERP prowadzi zamówienia zakupu i sprzedaży, rozliczenia i księgowość. WMS organizuje pracę fizyczną w magazynie.

Do WMS trafiają dane podstawowe i zlecenia, a z WMS wracają potwierdzenia wykonania. Typowy przepływ ERP → WMS obejmuje indeksy towarowe, jednostki miary i przeliczniki, kody kreskowe oraz dane kontrahentów.

Do wykonania trafiają też zamówienia zakupu (do przyjęcia), zamówienia sprzedaży (do wydania) i zlecenia przesunięć między lokalizacjami lub magazynami. Typowy przepływ WMS → ERP to potwierdzone przyjęcia i wydania, wykonane przesunięcia, korekty stanów oraz raport bieżących ilości w rozbiciu na lokalizacje, partie i statusy jakościowe.

Trzecia grupa to dane zwrotne sterujące: statusy dokumentów i zadań, informacje o błędach oraz aktualizacje rezerwacji. ERP musi je znać, aby nie obiecywać klientowi towaru już zablokowanego.

Obowiązuje zasada jednego źródła prawdy dla każdego atrybutu. Nazwa i jednostka miary zwykle powstają w ERP (lub w systemie PIM), a ilość fizyczna i lokalizacja — w WMS. Jeśli oba systemy pozwalają edytować ten sam atrybut, integracja nadpisze zmiany i wygeneruje konflikty zamiast je rozwiązać.

Przepływ danych podstawowych jest jednokierunkowy: ERP przekazuje je do WMS przed pierwszym zadaniem. Potwierdzenia wykonania płyną z WMS do ERP po zdarzeniu. Stany magazynowe mogą być aktualizowane w czasie rzeczywistym, np. przez narzędzia automatyzujące ceny i stany, takie jak SmartPrice.

Dane kluczowe wymieniane między ERP a WMS

Dane podstawowe i identyfikacja towaru

Dane podstawowe towaru to warunek techniczny integracji: bez nich terminal nie odczyta kodu, a WMS nie przypisze towaru do lokalizacji. Minimalny zakres obejmuje unikalny indeks i nazwę, jednostkę miary podstawowej oraz przeliczniki na jednostki zbiorcze (np. sztuka–karton–paleta).

W zakres wchodzą też kody kreskowe przypisane do konkretnej jednostki, status towaru (aktywny, zablokowany, wycofany) oraz cechy logistyczne wpływające na składowanie i kompletację: strefa składowania, wymagania temperaturowe, oznaczenia towarów niebezpiecznych, wskaźniki rotacji, wymiary i masa.

Kody kreskowe muszą pasować do urządzeń pracujących w magazynie. Terminale danych to bezprzewodowe, przenośne urządzenia do zbierania i przetwarzania danych w produkcji, logistyce i magazynie.

Mają czytnik kodów, klawiaturę, dotykowy wyświetlacz, baterię oraz obudowę zapewniającą poprawne działanie w trudnych warunkach przemysłowych. Pracują pod Androidem i komunikują się przez Bluetooth oraz Wi-Fi.

Występują jako terminale ręczne, wózkowe i przemysłowe tablety. Modele z czytnikami do odczytu kodów z dalszej odległości stosuje się w magazynach wysokiego składowania.

Obsługują odczyt kodów 1D i 2D. Dlatego dane podstawowe powinny określać, jaki kod jest nośnikiem jakiej jednostki i jaka ilość się za nim kryje.

Do kolektora trzeba też wysłać dane kontekstowe, nie tylko sam indeks: skrócony opis czytelny na małym ekranie, lokalizację źródłową i docelową, numer zadania oraz oczekiwaną ilość. Bez tego operator zeskanuje kod, ale nie będzie wiedział, jaką operację ma wykonać.

Najważniejsze dane podstawowe towaru dla integracji WMS–ERP

Stany magazynowe, rezerwacje i dostępność

Stany magazynowe to obszar, w którym integracja najczęściej zawodzi, bo „stan” znaczy co innego w każdym systemie. WMS powinien być źródłem ilości fizycznej w rozbiciu na lokalizacje, partie i numery seryjne, a ERP — ilości dostępnej handlowo, czyli pomniejszonej o rezerwacje.

Do ERP przekazuje się stany bieżące po każdym zdarzeniu lub w ustalonym interwale. W drugą stronę płyną rezerwacje z zamówień sprzedaży, aby magazyn nie skompletował towaru już obiecanego innemu klientowi.

Warto rozróżnić w wymianie co najmniej cztery liczby: ilość fizyczną, ilość zarezerwowaną, ilość dostępną do sprzedaży oraz ilość w drodze, np. z potwierdzonego, ale jeszcze nieprzyjętego dokumentu. Jeśli systemy nie operują tym samym słownikiem pojęć, użytkownik w ERP i operator w WMS będą widzieć inne liczby dla tego samego towaru.

Stan w czasie rzeczywistym bywa automatyzowany przez narzędzia takie jak SmartPrice, które automatyzują ceny i stany magazynowe. Nie zwalnia to z ustalenia, kto jest źródłem prawdy dla ilości fizycznej, rezerwacji i dostępności.

Różnice w rozumieniu 'stanu magazynowego' między ERP a WMS

Dokumenty i operacje magazynowe

Dokumenty i operacje to główny kanał przepływu transakcyjnego. Z ERP do WMS powinny trafiać zlecenia: przyjęcia towaru (na podstawie zamówienia zakupu lub awizacji dostawy), wydania (na podstawie zamówienia sprzedaży), przesunięcia między lokalizacjami i magazynami oraz zlecenia inwentaryzacji.

Z WMS do ERP wracają potwierdzenia wykonania: faktycznie przyjęta lub wydana ilość, data i godzina, lokalizacja, partia lub numer seryjny, numer nośnika logistycznego i identyfikator operatora.

Każdy komunikat musi nieść identyfikator pozwalający jednoznacznie sparować pozycję po obu stronach — numer dokumentu źródłowego wraz z numerem pozycji. Bez tego system nie rozpozna, czy potwierdzenie dotyczy całego dokumentu, czy jego części, i nie obsłuży przyjęć częściowych ani dostaw realizowanych w kilku etapach.

Trzeba też ustalić, który system tworzy dokument rozbieżności, gdy ilość faktyczna różni się od zamówionej, oraz gdzie powstaje wynikająca z tego korekta.

Dokumenty sprzedaży po stronie ERP mogą być powiązane z KSeF — Krajowym Systemem e-Faktur. To rządowa platforma służąca do wystawiania, odbierania i przechowywania faktur ustrukturyzowanych.

Przepływ danych przy przyjęciu towaru z zamówienia zakupu

Dane zbierane mobilnie: terminale, skany i potwierdzenia

Praca z kolektorem generuje strumień danych, który musi być kompletny, zanim trafi dalej do ERP. Pojedyncze zdarzenie skanowania obejmuje zwykle odczytany kod, ilość, lokalizację źródłową i docelową, numer zadania lub dokumentu, znacznik czasu, identyfikator operatora oraz status potwierdzenia (np. przyjęte, brak towaru, uszkodzone).

Te same terminale obsługują kody 1D i 2D, komunikują się przez Wi-Fi lub Bluetooth. W magazynach wysokiego składowania stosuje się czytniki dalekiego zasięgu.

Dane z terminala trafiają najpierw do WMS, który waliduje je względem danych podstawowych i zlecenia: czy kod istnieje, czy ilość nie przekracza oczekiwanej, czy lokalizacja jest właściwa. Dopiero zwalidowane zdarzenie powinno być przekazane do ERP — przenosi to kontrolę jakości danych na moment ich powstania, a nie na etap uzgadniania sald.

Osobno trzeba ustalić tryb pracy urządzeń. Praca online oraz praca z buforowaniem lokalnym, gdy zasięg sieci jest chwilowo niedostępny, wymagają innego zabezpieczenia przed zdublowaniem skanu.

Terminale danych wiodących producentów, m.in. Zebra, Datalogic i Cipherlab, obsługują odczyt kodów 1D i 2D oraz komunikację Bluetooth i Wi-Fi. Dane z tych urządzeń trafiają najpierw do WMS, gdzie są walidowane.

Dane o błędach, korektach i rozbieżnościach

Integracja bez obsługi danych zwrotnych zamienia problem z danymi w przestój operacyjny. Każdy komunikat wychodzący z WMS powinien mieć identyfikator korelacji i status: nowy, wysłany, potwierdzony, odrzucony.

Odrzucenie musi zawierać powód zrozumiały dla operatora — nieistniejący indeks, niezgodną ilość, zablokowany towar, ujemny stan — i trafiać do kolejki do ponowienia lub ręcznej korekty. Ponowienie tego samego komunikatu nie może powodować podwójnego zaksięgowania; zapobiega temu idempotencja oparta na identyfikatorze zdarzenia lub numerze dokumentu.

Osobno trzeba rozstrzygnąć korekty i różnice inwentaryzacyjne: WMS zna stan fizyczny po inwentaryzacji, ale to ERP musi zaksięgować różnicę w ujęciu wartościowym. Ustalenie, kto inicjuje korektę, jaki dokument powstaje po każdej stronie i jak oznaczyć korektę jeszcze nieprzyjętą przez drugi system, pozwala uniknąć sytuacji, w której stan w magazynie i stan w księgowości rozjeżdżają się bez śladu w logu.

Jeżeli korekta zawiera dane osobowe, np. identyfikator operatora, przetwarzanie wymaga podstawy z RODO, np. art. 6 ust. 1 lit. b albo lit. f. Korekty dokumentów sprzedaży powinny być spójne z KSeF.

Dane dla e-commerce i TMS oraz ustalenie zakresu wymiany

Kanały sprzedaży i transport to kolejni odbiorcy tych samych danych. Sklep internetowy potrzebuje bieżących stanów i statusów realizacji, aby nie sprzedawać towaru, którego fizycznie nie ma.

TMS potrzebuje informacji o gotowości przesyłki: liczby i typu nośników, masy, wymiarów oraz okna wysyłki. Sam WMS wspiera rozwój e-commerce i usprawnia procesy logistyczne, o ile dane o stanach i operacjach są spójne z resztą systemów.

Zakres wymiany warto ustalać kryteriami, a nie liczbą pól: specyfiką procesów (czy magazyn obsługuje partie, serie, numery seryjne i kontrolę jakości), elastycznością systemu i możliwością jego skalowania oraz zgodnością z wymogami prawnymi. Wybór systemu ERP w Polsce powinien uwzględniać zgodność z obowiązującymi przepisami prawa.

Rozpoczęcie od wąskiego zakresu krytycznego — indeksów i kodów, stanów z rezerwacjami oraz potwierdzeń przyjęć i wydań — pozwala uruchomić integrację. Dopiero potem można rozszerzać ją o partie, TMS i kanały e-commerce bez przebudowy fundamentu.

Zgodność prawna w Polsce obejmuje ustawę o rachunkowości oraz RODO. W materiałach źródłowych pojawia się wdrożenie Symfonia eDokumenty i KSeF Plus.