EDI és SAP 1. rész: Hogyan beszél egymással az EDI és az SAP? – EDIFACT, X12 és IDoc

Az SAP a hazai nagyvállalatok és a nemzetközi ellátási láncok beszállítóinak egyik leggyakoribb vállalatirányítási rendszere. Partnerei – kiskereskedelmi láncok, logisztikai szolgáltatók, tengerentúli vevők – viszont nem SAP-ul, hanem EDI-ül kommunikálnak: Európában jellemzően EDIFACT (az FMCG-szektorban annak GS1-alváltozata, az EANCOM), Észak-Amerikában ANSI ASC X12 szabvány szerint. Négyrészes sorozatunkban végigkövetjük, hogyan jut el egy üzleti dokumentum a partner rendszeréből az SAP-ba és vissza, és hol szoktak elcsúszni a projektek.

Az első rész az alapokat fekteti le: kik a szereplők, hogyan néz ki ugyanaz az üzenet EDIFACT-ban és X12-ben, és mit kell beállítani az SAP-oldalon ahhoz, hogy egy EDI-kapcsolat egyáltalán működhessen.

A példa, amely végigkíséri a sorozatot

Hogy ne elvont fogalmakról beszéljünk, a sorozat egy kitalált, de a gyakorlatban nagyon jellemző szcenárióra épül:

• Mintagyártó Kft. – magyar élelmiszer-gyártó, S/4HANA-t használ. Ő a „mi” oldalunk.
• Láncáruház Zrt. – hazai kiskereskedelmi lánc, EANCOM D.96A szerint rendel, és a központi elosztóraktárába kéri a szállítást.
• Raktár-Log Kft. – külső logisztikai szolgáltató (3PL), amely a Mintagyártó készletét tárolja és szállítja ki. Vele EDIFACT WHSORD és INVRPT üzenetekkel kommunikálunk.
• US Importer Inc. – amerikai vevő, amely X12 004010 szerint küldi a megrendeléseit.

A termék egy 6 darabos karton ásványvíz, GTIN-je 5991234000025, SAP-anyagszáma MAT-100045. A szereplők GLN-azonosítói (Global Location Number) a példában 599000000001x formájúak. Minden azonosító kitalált, de az ellenőrző számjegyek helyesek – egy éles projektben a konverter is ellenőrzi ezeket.

Miért nem „beszél EDIFACT-ul” az SAP?

Az SAP saját, belső adatcsere-formátuma az IDoc (Intermediate Document). Az IDoc szigorúan tipizált, szegmensekből álló struktúra, amely az SAP üzleti objektumaihoz igazodik: egy vevői megrendelés ORDERS05, egy szállítás DELVRY07, egy számla INVOIC02 alaptípusú IDocként lép be a rendszerbe vagy hagyja el azt. Az SAP szabványosan nem állít elő és nem dolgoz fel közvetlenül EDIFACT- vagy X12-üzenetet.

Ezért minden SAP–EDI integrációban van egy konverziós réteg (EDI-konverter, middleware). Ez lehet SAP-termék (SAP Integration Suite, korábban PI/PO), lehet harmadik féltől származó integrációs platform, vagy egy EDI-szolgáltató felhőben futó konvertere. A feladat mindhárom esetben ugyanaz:

1. Kommunikáció a partnerrel (AS2, SFTP, OFTP2, VAN), titkosítással, aláírással és kézbesítési igazolással (MDN).
2. Szintaktikai feldolgozás: a beérkező EDIFACT- vagy X12-állomány validálása, a szabványos nyugták (CONTRL, 997/999) visszaküldése.
3. Leképezés (mapping) az EDI-struktúra és az IDoc között, partnerenkénti eltérésekkel.
4. Adatkiegészítés törzsadatokból: GLN-ből SAP-vevőszám, GTIN-ből anyagszám, mértékegységkód-konverzió. (Erről a 4. részben részletesen írunk.)
5. Átadás az SAP-nak (jellemzően RFC/tRFC, IDoc-XML HTTP-n keresztül vagy fájlport) és monitorozás.

Ugyanaz az üzenet két szabványban

Az EDIFACT és az X12 hasonló problémát old meg, de eltérő szintaxissal és szóhasználattal. Nézzük meg ugyanannak a megrendelésnek a „borítékját” mindkét szabványban.

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 – az elválasztójelek definíciója (komponens :, adatelem +, tizedesjel ., feloldójel ?, szegmensvég ').
• UNB – az interchange (adatcsomag) fejléce: karakterkészlet (UNOD = ISO 8859-2), küldő és fogadó GLN (14 = GS1-azonosító), dátum, idő, egyedi azonosító.
• UNH … UNT – egy üzenet eleje és vége. Az UNT tartalmazza az üzenet szegmenseinek számát, amelyet a fogadó oldal ellenőriz.
• UNZ – az interchange zárása az üzenetek számával.

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 – fix hosszúságú interchange-fejléc. Az elválasztójeleket a pozíciójuk határozza meg: az elemelválasztó a 4. karakter (*), a komponenselválasztó az utolsó előtti (>), a szegmensvég pedig az ezt követő karakter (~).
• GS … GE – funkcionális csoport. Az X12 egy köztes szintet is használ, amely azonos típusú tranzakciókat fog össze (PO = megrendelések).
• ST … SE – maga a tranzakció (transaction set), itt az 850-es megrendelés.

Az üzenettípusok megfeleltetése

A sorozatban az alábbi hat üzleti folyamatot tárgyaljuk. Ez a táblázat a térképünk:

Érdemes megfigyelni, hogy az SAP-ban az üzenettípus és az IDoc-alaptípus két külön fogalom. Az ORDERS05 alaptípust a beérkező megrendelés (ORDERS) és a kimenő visszaigazolás (ORDRSP) is használja, a DELVRY07 pedig a szállítólevél (DESADV) és a raktári megbízás (SHPORD) hordozója is. A feldolgozási logikát az üzenettípus határozza meg.

Mit kell beállítani az SAP-ban?

Egy EDI-kapcsolat SAP-oldali konfigurációja néhány jól körülhatárolható elemből áll. Ezek ismerete akkor is hasznos, ha a beállítást az SAP-csapat végzi, mert a hibák jelentős része itt keresendő.

Az IDoc-státuszok közül a legfontosabbak: 64 (bejövő, feldolgozásra kész), 53 (bejövő, az alkalmazásbizonylat létrejött), 51 (bejövő, hibás – például ismeretlen anyag vagy vevő), és kimenő oldalon 03 (átadva a portnak). A tapasztalatunk szerint egy jól működő EDI-üzemeltetés egyik legfontosabb mutatója, hogy hány IDoc ragad 51-es státuszban, és mennyi idő alatt kerülnek feldolgozásra.

Nyugták: ki mit igazol?

A „megkaptuk az üzenetet” többféle dolgot jelenthet. Egy professzionális EDI-kapcsolatban ezeket a szinteket külön kezelik:

Gyakori félreértés, hogy egy pozitív CONTRL vagy 997 azt jelenti, hogy a megrendelés bekerült az SAP-ba. Valójában csak annyit jelent, hogy a konverter szintaktikailag helyesnek találta az üzenetet. Az IDoc ettől még elakadhat 51-es státuszban.

Gyakori hibák a gyakorlatban

• Karakterkódolás. Az EDIFACT-ban sokszor alapértelmezett UNOC (ISO 8859-1) nem tartalmazza az ő és ű betűket. Magyar címek és terméknevek esetén UNOD (ISO 8859-2) vagy – 4-es szintaxisverziónál – UNOW (UTF-8) szükséges. Ellenkező esetben az SAP-ba „Gyõr” vagy „Gy?r” kerül.
• Hiányzó vagy rossz partnerprofil. Új partner vagy új üzenettípus bevezetésekor a WE20 bejegyzés hiánya miatt az IDoc el sem jut az alkalmazásig (56-os státusz).
• Nyugták figyelmen kívül hagyása. Ha senki nem figyeli a negatív CONTRL- és 997-nyugtákat, a partner napokig azt hiheti, hogy a számláit befogadták.
• Teszt- és éles rendszer keveredése. Az UNB teszt-jelzője, illetve az ISA15 (T/P) értéke apróság, de egy tesztmegrendelés az éles SAP-ban valódi kiszállítást indíthat el.

Összefoglalás

Az SAP és az EDI-partnerek között mindig van egy konverziós réteg, amely a kommunikációt, a szintaktikai ellenőrzést, a leképezést és a törzsadatok feloldását végzi. Az EDIFACT és az X12 ugyanazokat az üzleti folyamatokat fedi le, eltérő szintaxissal. Az SAP-oldalon pedig az IDoc, a partnerprofil és az output-meghatározás alkotja a kapcsolat gerincét.

A következő részben a legforgalmasabb üzenetpárt, a megrendelést (ORDERS / 850) és a visszaigazolást (ORDRSP / 855) vesszük sorra, szegmensről szegmensre egészen az ORDERS05 IDocig.

Ha a saját SAP–EDI környezetét szeretné átvilágíttatni, vagy új partnert kell bekötnie, kérjen kötelezettségmentes ajánlatot. EDIFACT-üzeneteit pedig ingyenesen ellenőrizheti EDIFACT-validátorunkkal.

¹ ECC-ben a kimenő üzeneteket kizárólag a klasszikus feltételtechnika (NACE) vezérli. S/4HANA-ban a klasszikus NACE-megoldás továbbra is használható, és a migrált rendszerekben gyakran meg is marad.