# Jak działa integracja EDI z ERP? Do integracji EDI z ERP stosuje się trzy popularne drogi: interfejs programistyczny (API), tabele interfejsowe w bazie danych lub wymianę plików. Która pasuje, decyduje zwykle sam ERP: to, co już oferuje, prawie zawsze wychodzi taniej niż budowanie czegoś nowego. Ważniejsze od drogi technicznej jest często przyporządkowanie danych podstawowych, czyli który numer artykułu, który klient i która jednostka są rozumiane tak samo po obu stronach. ## Gdzie integracja z ERP znajduje się w procesie EDI Rozwiązanie EDI ma dwie strony. Na zewnątrz komunikuje się z partnerem, w jego formacie i przez jego kanał transmisji (zob. [Kanały transmisji](https://edi-service.eu/pl/baza-wiedzy/kanaly-transmisji-edi/)). Do wewnątrz komunikuje się z Państwa ERP. Pomiędzy nimi jest mapowanie, które tłumaczy zamówienie EDIFACT na strukturę zrozumiałą dla ERP, a w drugą stronę fakturę z ERP na INVOIC partnera. Partner nie widzi nic ze strony ERP. Dla niego liczy się tylko to, czy komunikaty docierają na czas i w komplecie. Dla Państwa strona ERP decyduje o tym, czy zamówienia zakładają się jako zlecenia bez pracy ręcznej i czy awizo wysyłki i faktura powstają automatycznie. Niektórzy dostawcy rozliczają więc integrację z ERP osobno; niemiecki EDI+EXPERTS podaje na przykład w cenniku „individuelles Angebot” (ofertę indywidualną). ## Trzy drogi integracji EDI z ERP ### Przez API lub webhook Wiele nowszych systemów ERP oferuje interfejs programistyczny przez HTTP, często jako REST API. Rozwiązanie EDI zakłada wtedy zlecenie bezpośrednio wywołaniem, a ERP od razu odpowiada sukcesem lub błędem. W drugą stronę ERP może uruchomić webhook: przy zdarzeniu, na przykład „dostawa zaksięgowana”, wywołuje adres oprogramowania EDI. Ważna jest obsługa powtórzeń. Jeśli połączenie zerwie się po wysłaniu, rozwiązanie EDI nie wie, czy zlecenie zostało założone. Dlatego norma HTTP (RFC 9110) wyróżnia metody idempotentne, których powtórzenie ma taki sam skutek jak pojedyncze wywołanie. W praktyce oznacza to: każde zamówienie potrzebuje unikalnego klucza, żeby druga próba nie utworzyła zdublowanego zlecenia. ### Przez tabele interfejsowe (staging w bazie danych) Wiele systemów ERP, zwłaszcza starszych lub branżowych, ma własne tabele importowe. Oprogramowanie EDI zapisuje zamówienie jako rekordy w tych tabelach, często osobno nagłówek i pozycje, i ustawia pole statusu. Program w ERP pobiera rekordy, sprawdza je, zakłada zlecenie i zapisuje wynik z powrotem. Zaleta: ERP zachowuje kontrolę nad swoimi regułami kontroli, a status każdego rekordu da się prześledzić. Wada: rozwiązanie EDI potrzebuje dostępu do bazy danych, a program pobierający w ERP musi działać. Nigdy nie należy zapisywać bezpośrednio do właściwych tabel zleceń ERP. Omija się w ten sposób jego kontrole, a aktualizacja ERP może niezauważenie zepsuć integrację. ### Przez pliki Prawie każdy ERP potrafi wczytywać i zapisywać pliki, zwykle jako CSV, XML lub JSON. Oprogramowanie EDI zapisuje plik w folderze, na serwerze plików lub przez SFTP, a ERP importuje go według harmonogramu. W drugą stronę ERP eksportuje dokumenty dostawy lub faktury jako plik, który rozwiązanie EDI pobiera. Pliki są odporne i łatwe do sprawdzenia, bo można je otworzyć i przeczytać. Za to informacja zwrotna przychodzi z opóźnieniem, a błędy importu widać często dopiero w logu ERP. Dlatego warto ustalić stałe reguły: unikalne nazwy plików, zapis pod nazwą tymczasową i dopiero potem zmiana nazwy, osobne foldery dla sukcesów i błędów. ### IDoc jako przypadek szczególny W środowiskach SAP popularny jest IDoc (Intermediate Document). SAP opisuje go jako kontener do wymiany danych między systemami SAP a systemami zewnętrznymi, składający się z nagłówka, segmentów danych i rekordów statusu. IDoc jest więc raczej formatem niż osobną drogą; przesyła się go, zależnie od konfiguracji, jako plik lub przez interfejs. ## Trzy drogi w porównaniu | | API lub webhook | Tabele interfejsowe | Plik | |---|---|---|---| | Informacja zwrotna | natychmiast | gdy ERP przetworzy rekord | z opóźnieniem, często przez log | | Szukanie błędów | przez kody odpowiedzi i logi | status każdego rekordu w tabeli | odczyt pliku, folder błędów | | Wymaganie po stronie ERP | udokumentowane API | tabele importowe i program pobierający | funkcja importu i eksportu | | Dostęp dla oprogramowania EDI | sieć i dane dostępowe do API | dostęp do bazy, najlepiej tylko do tych tabel | folder lub konto SFTP | | Unikanie zdublowanych zleceń | unikalny klucz dla każdej operacji | unikalny klucz w tabeli | unikalne nazwy plików, archiwizacja po imporcie | | Dla kogo | nowoczesne systemy ERP, ERP w chmurze | ERP z istniejącymi tabelami importowymi | prawie każdy ERP, także starszy | ## Mapowanie danych podstawowych to właściwa praca Większość błędów w integracji EDI z ERP nie powstaje w technice, lecz przy przyporządkowaniu numerów i jednostek. - Numery artykułów: partner zamawia ze swoim numerem materiału lub z GTIN, a ERP zna Państwa własny numer artykułu. GS1 opisuje GTIN jako numer, którym firma jednoznacznie oznacza swoje jednostki handlowe. Potrzebna jest utrzymywana tabela przyporządkowań, w ERP lub w rozwiązaniu EDI. - Partnerzy i miejsca dostaw: partner podaje kupującego, miejsce dostawy i odbiorcę faktury zwykle przez GLN. ERP pracuje z numerami klientów i adresami dostaw. Każdy GLN musi być przypisany do rekordu, inaczej towar trafi w złe miejsce. Więcej na stronie [GLN i inne identyfikatory](https://edi-service.eu/pl/baza-wiedzy/numer-gln-identyfikatory/). - Jednostki: partner zamawia w sztukach, ERP prowadzi artykuł w kartonach po dwanaście sztuk. Bez przeliczenia ilości i ceny się nie zgadzają. - Ceny i warunki: jeśli cena w zamówieniu różni się od ceny w ERP, musi być ustalone, która ma pierwszeństwo i kto dostaje powiadomienie. ## Obsługa błędów i testy Dla każdego błędu warto zaplanować ścieżkę. Zamówienie z nieznanym numerem artykułu nie może ani zniknąć, ani zostać założone w połowie. Powinno trafić na listę błędów z oryginalnym plikiem i komunikatem w zrozumiałym języku, żeby ktoś mógł je poprawić i wczytać ponownie. Kto dostaje jakie powiadomienie, powinno być ustalone przed startem. Integrację należy najpierw testować na firmie testowej lub w środowisku testowym ERP. Warto przejść tam prawdziwe przykłady ze specyfikacji partnera, także te nieprzyjemne: anulacje, dostawy częściowe, nieznane artykuły, zdublowane komunikaty. Dopiero gdy te przypadki działają poprawnie, integracja trafia do firmy produkcyjnej. Które punkty specyfikacji są przy tym ważne, pokazuje [lista kontrolna specyfikacji EDI](https://edi-service.eu/pl/baza-wiedzy/specyfikacja-edi-lista-kontrolna/). ## Co edi-service.eu oferuje po stronie ERP edi-service.eu łączy Państwa ERP przez trzy ogólne adaptery: adapterem REST i webhook, tabelami interfejsowymi w bazie danych oraz adapterem plikowym dla CSV, XML lub JSON. Gotowy adapter dla konkretnego produktu ERP nie wchodzi w zakres, podobnie jak zmiany w samym ERP. AI konfiguruje przyporządkowanie najpierw w trybie TEST, do pracy produkcyjnej przechodzi dopiero po Państwa zatwierdzeniu. Co obejmuje stała cena, opisuje sekcja [Cena](https://edi-service.eu/pl/#preis). Jeśli chcą Państwo wyjaśnić, czy Państwa ERP oferuje jedną z trzech dróg, można [wysłać zapytanie](https://edi-service.eu/pl/zapytanie/). ## Najczęstsze pytania ### Jakiego interfejsu potrzebuje mój ERP do EDI? ERP potrzebuje sposobu na przyjmowanie zleceń i wydawanie dostaw lub faktur: API, tabel importowych lub interfejsu plikowego. Prawie każdy ERP oferuje co najmniej import plików. Jakie drogi są dostępne, podaje dokumentacja ERP lub wie o tym opiekun systemu. ### Czy sam ERP musi rozumieć EDIFACT? Nie. Tłumaczenie między EDIFACT lub VDA a formatem ERP przejmuje oprogramowanie EDI. ERP widzi tylko własną strukturę, na przykład plik CSV lub wywołanie API. ### Co to jest staging w bazie danych? Staging oznacza, że komunikaty przekazuje się przez tabele pośrednie w bazie danych. Rozwiązanie EDI do nich zapisuje, a program w ERP odczytuje, sprawdza i księguje. Dzięki temu reguły kontroli ERP pozostają w mocy. ### Jak uniknąć zdublowanych zleceń? Każdy komunikat potrzebuje unikalnego klucza, na przykład partner plus numer zamówienia. Oprogramowanie EDI i ERP sprawdzają przed założeniem, czy taki klucz już istnieje. Chroni to także wtedy, gdy partner wyśle to samo zamówienie dwa razy. ## Źródła - IETF: „RFC 9110, HTTP Semantics”, (dostęp 16.10.2026) - SAP: „IDocs (SAP Library)”, (dostęp 16.10.2026) - GS1: „Global Trade Item Number (GTIN)”, (dostęp 16.10.2026) - GS1: „Global Location Number (GLN)”, (dostęp 16.10.2026) - EDI-Experts Service GmbH: „Preise”, (dostęp 16.10.2026)