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:
- 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).
- Sintaksna provjera i potvrde: provjera ispravnosti ulaznih poruka prema standardima te automatsko slanje tehničkih i funkcionalnih potvrda (EDIFACT CONTRL, ANSI X12 997/999).
- Mapiranje podataka (data mapping): preslikavanje segmenata vanjskog EDI-ja u odgovarajuće segmente IDoc-a prema specifikacijama implementacije (MIG).
- 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.
- 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 (oznaka14= GS1 kod), datum, vrijeme i referentni broj.UNH…UNT– zaglavlje i završetak pojedinačne poslovne poruke. SegmentUNTnavodi 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žbenice850.
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 proces | UN/EDIFACT | ANSI X12 | SAP tip poruke / IDoc osnovni tip | Dio serije |
|---|---|---|---|---|
| Narudžbenica (PO) | ORDERS | 850 | ORDERS / ORDERS05 | 2. dio |
| Potvrda narudžbe (POA) | ORDRSP | 855 | ORDRSP / ORDERS05 | 2. dio |
| Najava pošiljke (ASN) | DESADV | 856 | DESADV / DELVRY07 | 3. dio |
| Nalog za otpremu iz skladišta | WHSORD | 940 | SHPORD / DELVRY07 | 3. dio |
| Izvještaj o stanju zaliha | INVRPT | 846 | Prilagođeni / LOISTD | 3. dio |
| Komercijalni račun | INVOIC | 810 | INVOIC / INVOIC02 | 4. 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:
| Komponenta | Transakcija | Uloga u sustavu |
|---|---|---|
| Definicija porta | WE21 | Određuje tehnički komunikacijski kanal između SAP-a i middlewarea (tRFC, XML HTTP, datotečni port). |
| Profil partnera | WE20 | Definira po partneru i tipu poruke: izlazni IDoc tip, odredišni port, pravila pakiranja i ulazni procesni kod (process code). |
| Određivanje izlaza | NACE / BRF+ upravljanje izlazom | Upravlja 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-a | WE02 / WE05, BD87 | Pregled hijerarhije statusa, provjera sadržaja segmenata i ponovna obrada pogrešnih IDoc-ova. |
| Alat za testiranje | WE19 | Omoguć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:
| Razina | UN/EDIFACT | ANSI X12 | Što potvrđuje? |
|---|---|---|---|
| Prijenosna razina | AS2 MDN (potpisan), OFTP2 EERP | Potvrđuje da je datoteka neizmijenjena stigla na poslužitelj i uspješno dešifrirana. | |
| Sintaksna razina | CONTRL | 997 / 999, TA1 | Potvrđuje da je poruka usklađena s gramatikom standarda i obaveznim segmentima. |
| Aplikacijska razina | APERAK | 824 | Potvrđ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 koristitiUNOD(ISO 8859-2) ili verziju sintakse 4 sUNOW(UTF-8). U suprotnom u SAP ulaze nečitljivi nazivi ili upitnici. - Nedostajući profili partnera: Ako u transakciji
WE20nije definiran tip poruke za novog partnera, IDoc se zaustavlja sa statusom56prije 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
UNBsegmentu ili X12ISA15(TumjestoP) 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.