← Članci · EDI & SAP

EDI i SAP 1. dio: Kako međusobno komuniciraju EDI i SAP? – Arhitektura EDIFACT, X12 i IDoc

U prvom dijelu serije detaljno prikazujemo arhitekturu integracije SAP-a i EDI-ja: ulogu middleware konvertera, sintaksu EDIFACT i ANSI X12, IDoc strukture te WE20 profile partnera.

SAP je jedan od najčešće korištenih ERP sustava među međunarodnim proizvodnim kompanijama, distributerima i dobavljačima u lancima opskrbe. Međutim, vanjski poslovni partneri – maloprodajni lanci, pružatelji logističkih usluga (3PL) i inozemni kupci – rijetko komuniciraju izravnim SAP formatom. Umjesto toga, koriste standarde elektroničke razmjene podataka (EDI): u Europi pretežito UN/EDIFACT (u FMCG sektoru posebno GS1 podskup EANCOM), a u Sjevernoj Americi ANSI ASC X12. U ovoj seriji od četiri dijela detaljno pratimo kako poslovni dokumenti putuju između sustava partnera i SAP-a te gdje se u praksi najčešće javljaju integracijski problemi.

Prvi dio postavlja temelje arhitekture: uloge sudionika, usporedbu sintakse poruka u EDIFACT-u i ANSI X12 te ključne postavke unutar SAP sustava potrebne za stabilan rad B2B EDI komunikacije.

Referentni scenarij koji prati cijelu seriju

Kako bismo izbjegli apstraktne koncepte, serija se temelji na konkretnom i u praksi vrlo čestom opskrbnom lancu:

  • Uzorak Proizvođač d.o.o. – proizvođač hrane i pića koji koristi SAP S/4HANA (predstavlja interni SAP sustav).
  • Trgovački Lanac d.d. – maloprodajni lanac koji naručuje prema standardu EANCOM D.96A s dostavom u svoj središnji distribucijski centar (DC).
  • Skladišna Logistika d.o.o. – vanjski logistički partner (3PL) koji skladišti i otprema robu za proizvođača, komunicirajući putem EDIFACT WHSORD i INVRPT poruka.
  • US Importer Inc. – američki veleprodajni kupac koji narudžbenice šalje prema standardu ANSI ASC X12 (verzija 004010).

Proizvod u primjeru je paket od 6 boca mineralne vode s GTIN oznakom 5991234000025 i SAP brojem materijala MAT-100045. GLN brojevi (Global Location Number) sudionika prate GS1 pravila, a konverzijski sloj u produkciji automatski provjerava ispravnost kontrolnih znamenki.

Zašto je za SAP potreban konverzijski sloj (middleware)?

SAP izvorno ne obrađuje i ne stvara izravne tekstualne nizove u formatima EDIFACT ili X12. SAP-ov interni format za razmjenu podataka je IDoc (Intermediate Document). IDoc je strogo tipizirana, hijerarhijska struktura sastavljena od segmenata koji odgovaraju poslovnim objektima u SAP-u: narudžba kupca obrađuje se kao osnovni IDoc tip ORDERS05, otpremnica kao DELVRY07, a račun kao INVOIC02.

Zbog toga svaka SAP–EDI integracija zahtijeva konverzijski sloj (EDI konverter / middleware). To može biti SAP-ova integracijska platforma (SAP Integration Suite / Cloud Integration, nekadašnji PI/PO), namjenski integracijski poslužitelj treće strane ili pružatelj EDI usluga u oblaku. Bez obzira na model, middleware obavlja pet ključnih funkcija:

  1. Sigurna B2B komunikacija: razmjena podataka s partnerima putem protokola AS2 (RFC 4130), SFTP, OFTP2 ili VAN mreža, uz enkripciju, digitalno potpisivanje i obradu kriptografskih potvrda o primitku (MDN / EERP).
  2. Sintaksna provjera i potvrde: provjera ispravnosti ulaznih poruka prema standardima te automatsko slanje tehničkih i funkcionalnih potvrda (EDIFACT CONTRL, ANSI X12 997/999).
  3. Mapiranje podataka (data mapping): preslikavanje segmenata vanjskog EDI-ja u odgovarajuće segmente IDoc-a prema specifikacijama implementacije (MIG).
  4. Rješavanje i nadopuna matičnih podataka: povezivanje vanjskih identifikatora (GLN, DUNS) s internim SAP šiframa kupaca i dobavljača (KUNNR/LIFNR), vanjskih GTIN kodova sa SAP brojevima materijala (MATNR) te pretvorba ISO mjernih jedinica u interne SAP jedinice.
  5. Prijenos u SAP i nadzor: razmjena IDoc dokumenata sa SAP-om putem tRFC veze, SOAP/HTTP IDoc-XML ili datotečnih portova uz praćenje statusa obrade.

Isti dokument u dva različita standarda

Iako UN/EDIFACT i ANSI X12 rješavaju iste poslovne zahtjeve, sintaksa i način odvajanja podataka znatno se razlikuju. Sljedeći primjeri prikazuju zaglavlja iste narudžbenice u oba standarda:

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 – definicija separatora (separator podkomponente :, separator elementa +, decimalna točka ., znak za otpuštanje ?, terminator segmenta ').
  • UNB – zaglavlje omotnice: identifikator znakovnog skupa (UNOD = ISO 8859-2 / srednjoeuropski), GLN pošiljatelja i primatelja (oznaka 14 = GS1 kod), datum, vrijeme i referentni broj.
  • UNH … UNT – zaglavlje i završetak pojedinačne poslovne poruke. Segment UNT navodi ukupan broj segmenata koji se provjerava pri analizi cjelovitosti prijenosa.
  • UNZ – završetak omotnice koji potvrđuje ukupan broj poruka u pošiljci.

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 – fiksno zaglavlje kontrole razmjene. Separatori su određeni svojom točnom pozicijom u nizu: separator elemenata je 4. znak (*), separator pod-elemenata je pretposljednji znak (>), a znak kraja segmenta je na kraju retka (~).
  • GS … GE – funkcionalna grupa koja objedinjuje povezane transakcije iste vrste (PO = narudžbe).
  • ST … SE – početak i kraj pojedinačnog skupa transakcija, u ovom slučaju narudžbenice 850.

Usporedba ključnih tipova poruka

Šest glavnih logističkih i prodajnih procesa obrađenih u ovoj seriji preslikavaju se na sljedeće standardne poruke:

Poslovni procesUN/EDIFACTANSI X12SAP tip poruke / IDoc osnovni tipDio serije
Narudžbenica (PO)ORDERS850ORDERS / ORDERS052. dio
Potvrda narudžbe (POA)ORDRSP855ORDRSP / ORDERS052. dio
Najava pošiljke (ASN)DESADV856DESADV / DELVRY073. dio
Nalog za otpremu iz skladištaWHSORD940SHPORD / DELVRY073. dio
Izvještaj o stanju zalihaINVRPT846Prilagođeni / LOISTD3. dio
Komercijalni računINVOIC810INVOIC / INVOIC024. dio

Važno je naglasiti da su u SAP-u logički tip poruke i osnovni IDoc tip dva odvojena pojma. Primjerice, struktura ORDERS05 koristi se i za ulazne narudžbe (ORDERS) i za izlazne potvrde narudžbi (ORDRSP), dok DELVRY07 prenosi i najavu pošiljke (DESADV) i nalog skladištu (SHPORD). Logiku obrade određuje dodijeljeni profil partnera i procesni kod.

Ključne konfiguracijske postavke unutar SAP-a

Na strani SAP sustava konfiguracija EDI sučelja oslanja se na nekoliko standardnih transakcija:

KomponentaTransakcijaUloga u sustavu
Definicija portaWE21Određuje tehnički komunikacijski kanal između SAP-a i middlewarea (tRFC, XML HTTP, datotečni port).
Profil partneraWE20Definira po partneru i tipu poruke: izlazni IDoc tip, odredišni port, pravila pakiranja i ulazni procesni kod (process code).
Određivanje izlazaNACE / BRF+ upravljanje izlazomUpravlja uvjetima nastanka izlaznih EDI poruka (npr. pri knjiženju računa). U S/4HANA sustavu BRF+ je moderni standard za prodaju i nabavu.¹
Praćenje IDoc-aWE02 / WE05, BD87Pregled hijerarhije statusa, provjera sadržaja segmenata i ponovna obrada pogrešnih IDoc-ova.
Alat za testiranjeWE19Omogućuje inženjerima ručno kreiranje, kopiranje i simulaciju ulaznih i izlaznih IDoc-ova tijekom testiranja mapiranja.

Najvažniji statusi IDoc-a koje treba pratiti u redovnom radu su: 64 (ulazni dokument spreman za obradu), 53 (poslovni dokument uspješno proknjižen), 51 (pogreška u obradi, npr. nedostaju matični podaci) te izlazni 03 (uspješno predano vanjskom portu). Broj IDoc-ova zaustavljenih u statusu 51 ključni je pokazatelj stabilnosti rada EDI sustava.

Potvrde o primitku: razine verifikacije

U profesionalnoj razmjeni podataka primitak poruke potvrđuje se na tri zasebne razine:

RazinaUN/EDIFACTANSI X12Što potvrđuje?
Prijenosna razinaAS2 MDN (potpisan), OFTP2 EERPPotvrđuje da je datoteka neizmijenjena stigla na poslužitelj i uspješno dešifrirana.
Sintaksna razinaCONTRL997 / 999, TA1Potvrđuje da je poruka usklađena s gramatikom standarda i obaveznim segmentima.
Aplikacijska razinaAPERAK824Potvrđuje je li odredišni ERP sustav uspješno obradio ili poslovno odbio dokument.

Česta zabluda u poslovanju jest uvjerenje da pozitivna potvrda CONTRL ili 997 znači da je narudžba već unesena u SAP. Ona potvrđuje samo sintaksnu ispravnost na ulaznim vratima (gatewayu) – odgovarajući IDoc u SAP-u i dalje može zapeti u statusu 51.

Najčešće pogreške i izazovi u praksi

  • Problemi s kodiranjem znakova: Zadana EDIFACT kodna stranica UNOC (ISO 8859-1) ne podržava dijakritičke znakove (č, ć, ž, š, đ). Za točne nazive partnera i gradova potrebno je koristiti UNOD (ISO 8859-2) ili verziju sintakse 4 s UNOW (UTF-8). U suprotnom u SAP ulaze nečitljivi nazivi ili upitnici.
  • Nedostajući profili partnera: Ako u transakciji WE20 nije definiran tip poruke za novog partnera, IDoc se zaustavlja sa statusom 56 prije nego što dođe do aplikacijske logike.
  • Zanemarivanje negativnih potvrda: Ako sustav nema automatska upozorenja za negativne CONTRL ili 997 poruke, dobavljač može danima vjerovati da su računi isporučeni, dok su u stvarnosti odbačeni na vratima partnera.
  • Miješanje testnih i produkcijskih oznaka: Oznaka testnog prijenosa u UNB segmentu ili X12 ISA15 (T umjesto P) sitan je detalj, no pogrešno usmjerena testna narudžba u produkcijskom SAP sustavu može pokrenuti stvarnu pripremu robe u skladištu.

Sažetak

Uspješna integracija SAP-a s vanjskim B2B partnerima uvijek se oslanja na pouzdan konverzijski sloj zadužen za prijenos, provjeru sintakse, mapiranje podataka i rješavanje matičnih podataka. Iako EDIFACT i ANSI X12 koriste različitu sintaksu, oba se standarda jednostavno i pouzdano preslikavaju u standardni SAP-ov IDoc model.

U drugom dijelu serije detaljno ćemo obraditi proces s najvećim volumenom: narudžbenicu (ORDERS / 850) i potvrdu narudžbe (ORDRSP / 855), prateći segmente izravno do IDoc strukture ORDERS05.

Planirate implementaciju SAP EDI sučelja ili želite pregled postojećih integracija? Zatražite savjetovanje ili provjerite svoje EDIFACT datoteke putem našeg besplatnog alata EDIFACT Validator.

¹ U starijim sustavima SAP ECC upravljanje izlaznim porukama temelji se isključivo na NACE tehnici uvjeta. U S/4HANA sustavu NACE je zadržan radi kompatibilnosti, dok je BRF+ preporučeno rješenje za nove implementacije.