EDI i SAP cz. 1: Jak komunikują się ze sobą EDI i SAP? – Architektura EDIFACT, X12 i IDoc

SAP to jeden z najczęściej wybieranych systemów ERP wśród międzynarodowych przedsiębiorstw produkcyjnych, dystrybutorów i sieci handlowych. Partnerzy biznesowi – sieci detaliczne, operatorzy logistyczni (3PL) czy kontrahenci zagraniczni – rzadko jednak porozumiewają się wewnętrznym formatem SAP. Zamiast tego stosują standardy elektronicznej wymiany danych (EDI): w Europie głównie UN/EDIFACT (w sektorze FMCG przede wszystkim podzbiór EANCOM), a w Ameryce Północnej ANSI ASC X12. W czteroczęściowej serii artykułów szczegółowo omawiamy przepływ dokumentów handlowych pomiędzy systemami partnerów a środowiskiem SAP oraz wskazujemy newralgiczne punkty projektów integracyjnych.

W pierwszej części przedstawiamy fundamenty architektury: rolę uczestników procesu, porównanie składni EDIFACT i ANSI X12 oraz kluczowe ustawienia w systemie SAP niezbędne do stabilnego uruchomienia komunikacji B2B.

Scenariusz referencyjny w naszej serii

Aby omówić procesy na konkretnym, powtarzalnym w praktyce przykładzie, cała seria opiera się na spójnym łańcuchu dostaw:

• Wzorcowy Producent Sp. z o.o. – producent branży spożywczej pracujący na systemie SAP S/4HANA (reprezentuje środowisko wewnętrzne SAP).
• Sieć Handlowa S.A. – sieć supermarketów składająca zamówienia w standardzie EANCOM D.96A z dostawą do centralnego magazynu dystrybucyjnego.
• Logistyka Magazynowa Sp. z o.o. – zewnętrzny operator logistyczny (3PL) zarządzający zapasami i wysyłkami producenta za pośrednictwem komunikatów EDIFACT WHSORD i INVRPT.
• US Importer Inc. – amerykański kontrahent wysyłający zamówienia handlowe w standardzie ANSI ASC X12 (wersja 004010).

Przykładowym produktem jest zgrzewka wody mineralnej (6 sztuk) o numerze GTIN 5991234000025 i numerze materiału SAP MAT-100045. Numery lokalizacyjne GLN uczestników procesu spełniają wymogi standardu GS1, co umożliwia weryfikację cyfr kontrolnych na poziomie konwertera.

Dlaczego SAP wymaga warstwy konwersji EDI?

System SAP nie przetwarza bezpośrednio surowych strumieni EDIFACT ani ANSI X12. Wewnętrznym, ustrukturyzowanym formatem wymiany danych w SAP jest IDoc (Intermediate Document). IDoc to ściśle typizowana, hierarchiczna struktura złożona z segmentów odpowiadających obiektom biznesowym SAP: zamówienie klienta trafia do systemu jako typ podstawowy ORDERS05, dostawa wychodząca jako DELVRY07, a faktura sprzedaży jako INVOIC02.

Z tego względu każde środowisko SAP–EDI wymaga warstwy konwersji (konwertera EDI / oprogramowania middleware). Może to być platforma SAP (SAP Integration Suite / Cloud Integration, dawniej SAP PI/PO), dedykowany serwer integracyjny lub certyfikowany operator chmurowy EDI. Niezależnie od wybranego modelu technologicznego, platforma realizuje pięć fundamentalnych zadań:

1. Bezpieczna komunikacja B2B: obsługa protokołów AS2, SFTP, OFTP2 czy sieci VAN, w tym szyfrowanie, podpisy cyfrowe oraz weryfikacja kryptograficznych potwierdzeń doręczenia (MDN / EERP).
2. Kontrola składni i generowanie potwierdzeń: walidacja strukturalna przychodzących komunikatów oraz automatyczne odsyłanie potwierdzeń technicznych i funkcjonalnych (EDIFACT CONTRL, ANSI X12 997/999).
3. Mapowanie danych (data mapping): przekształcanie pętli segmentów EDI na odpowiednie struktury segmentów IDoc w oparciu o specyfikacje implementacyjne partnerów (MIG).
4. Rozstrzyganie i uzupełnianie danych podstawowych: powiązanie zewnętrznych identyfikatorów (GLN, DUNS) z kartotekami odbiorców/dostawców SAP (KUNNR/LIFNR), kodów GTIN z numerami materiałów SAP (MATNR) oraz kodów jednostek miar ISO z wewnętrznymi kluczami SAP.
5. Integracja z SAP: przekazywanie dokumentów IDoc za pośrednictwem tRFC, serwisów Web / IDoc-XML HTTP lub portów plikowych wraz z bieżącym monitorowaniem statusów.

Ten sam dokument w dwóch różnych standardach

Choć UN/EDIFACT i ANSI X12 realizują te same cele biznesowe, różnią się konstrukcją koperty i sposobem separacji danych. Poniżej zestawiono nagłówki tego samego zamówienia zakupu w obu formatach:

EDIFACT (EANCOM D.96A)

UNA:+.? '
UNB+UNOD:3+5990000000023:14+5990000000016:14+261014:0815+00000123'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+PO-458812+9'
...
UNT+15+1'
UNZ+1+00000123'

• UNA – definicja separatorów (separator komponentu :, separator elementu +, separator dziesiętny ., znak modyfikacji/ucieczki ?, terminator segmentu ').
• UNB – nagłówek zbioru (interchange header): identyfikator składni (UNOD = ISO 8859-2 / Europa Środkowa i Wschodnia), numery GLN nadawcy i odbiorcy (kwalifikator 14 = GS1), data, czas i numer referencyjny.
• UNH … UNT – koperta pojedynczego komunikatu. Segment UNT zawiera liczbę segmentów weryfikowaną przez parser w celu potwierdzenia integralności transmisji.
• UNZ – zwiastun zbioru weryfikujący łączną liczbę komunikatów w przesyłce.

ANSI ASC X12 (004010)

ISA*00*          *00*          *ZZ*USBUYER        *ZZ*HUMANUF        *261014*0815*U*00401*000000123*0*P*>~
GS*PO*USBUYER*HUMANUF*20261014*0815*123*X*004010~
ST*850*0001~
BEG*00*SA*PO-US-77120**20261014~
...
SE*7*0001~
GE*1*123~
IEA*1*000000123~

• ISA – nagłówek kontrolny o stałej szerokości pól. Separatory są definiowane przez pozycję w strukturze: separator elementów to 4. znak (*), separator subelementów to przedostatni znak (>), a znak końca segmentu znajduje się na końcu wiersza (~).
• GS … GE – koperta grupy funkcjonalnej łączącej transakcje powiązane dziedzinowo (PO = grupa zamówień).
• ST … SE – nagłówek i zwiastun zestawu transakcji, w tym przypadku zamówienia zakupu 850.

Zestawienie najważniejszych komunikatów

Sześć podstawowych procesów logistyczno-handlowych opisywanych w tej serii mapuje się następująco:

Warto pamiętać, że w systemie SAP logiczny typ komunikatu oraz typ podstawowy IDoc to dwa odrębne pojęcia. Przykładowo struktura ORDERS05 obsługuje zarówno przychodzące zamówienia (ORDERS), jak i wychodzące potwierdzenia (ORDRSP), natomiast DELVRY07 jest nośnikiem zarówno awiza wysyłki (DESADV), jak i zlecenia dla magazynu 3PL (SHPORD).

Konfiguracja modułu EDI w systemie SAP

Prawidłowe działanie interfejsu EDI w SAP opiera się na kilku kluczowych transakcjach konfiguracyjnych:

Kluczowe statusy IDoc w codziennym monitoringu to: 64 (komunikat wejściowy gotowy do zaksięgowania), 53 (dokument biznesowy utworzony poprawnie), 51 (błąd przetwarzania aplikacji, np. brak indeksu materiałowego) oraz wyjściowy 03 (przekazano do portu zewnętrznego). Liczba dokumentów zatrzymanych w statusie 51 to podstawowy miernik stabilności środowiska EDI.

Potwierdzenia: poziomy weryfikacji

W profesjonalnej komunikacji EDI potwierdzenie odebrania danych odbywa się na trzech niezależnych poziomach:

Częstym błędem operacyjnym jest przekonanie, że pozytywne potwierdzenie CONTRL lub 997 oznacza poprawne utworzenie zamówienia w SAP. Oznacza ono jedynie poprawność gramatyczną pliku na bramie transmisyjnej – dokument IDoc w SAP może wciąż wymagać interwencji w statusie 51.

Typowe błędy i wyzwania wdrożeniowe

• Niewłaściwa strona kodowa: Domyślny zestaw znaków EDIFACT UNOC (ISO 8859-1) nie obsługuje polskich znaków diakrytycznych. Dla polskich nazw i adresów konieczne jest zastosowanie UNOD (ISO 8859-2) lub wersji 4 składni z UNOW (UTF-8). W przeciwnym razie w kartotekach partnerów pojawią się znaki zapytania lub zniekształcone dane.
• Brakujące wpisy w profilach partnerów: Brak przypisanego typu komunikatu w transakcji WE20 skutkuje natychmiastowym zatrzymaniem dokumentu ze statusem 56 przed przekazaniem do logiki aplikacyjnej.
• Ignorowanie negatywnych komunikatów zwrotnych: Brak monitorowania negatywnych potwierdzeń CONTRL lub 997 powoduje, że dostawca żyje w przekonaniu o doręczeniu faktury, podczas gdy została ona odrzucona przez bramę klienta.
• Mylenie środowisk testowych z produkcyjnymi: Flaga testowa w segmencie UNB lub znacznik ISA15 (T zamiast P) musi być precyzyjnie kontrolowana, by testowe zamówienie w systemie produkcyjnym nie wywołało realnej wysyłki magazynowej.

Podsumowanie

Skuteczna integracja SAP z partnerami handlowymi B2B zawsze wymaga dedykowanej warstwy konwertera odpowiedzialnej za transport, kontrolę składni, mapowanie oraz uzupełnianie danych podstawowych. Zarówno EDIFACT, jak i ANSI X12 z powodzeniem integrują się ze standardową strukturą dokumentów IDoc.

W drugiej części serii przeanalizujemy najbardziej obciążony proces: obsługę zamówienia zakupu (ORDERS / 850) i potwierdzenia zamówienia (ORDRSP / 855), śledząc strukturę segmentów aż do poziomu IDoc ORDERS05.

Planujesz audyt środowiska EDI w SAP lub podłączenie nowego partnera handlowego? Skonsultuj się z naszymi ekspertami lub zweryfikuj poprawność swoich plików w naszym bezpłatnym narzędziu Walidator EDIFACT.

¹ W starszych systemach SAP ECC sterowanie komunikatami wyjściowymi opiera się wyłącznie na technice warunków NACE. W S/4HANA mechanizm NACE jest nadal wspierany dla zachowania kompatybilności wstecznej, podczas gdy BRF+ pozostaje rozwiązaniem rekomendowanym.