EDI és abas 1. rész: Architektúra, EDP/FOP-interfész és az abas–EDIFACT konverzió szabályai

Az abas ERP Magyarországon a gyártó, fém- és műanyagipari, autóipari beszállító, valamint nagykereskedelmi középvállalatok egyik legelterjedtebb vállalatirányítási rendszere. Üzleti partnereik – nemzetközi autóipari Tier-1/OEM vevők, barkács- és kiskereskedelmi áruházláncok, logisztikai szolgáltatók – azonban nem az abas belső adatstruktúráit várják, hanem szabványos UN/EDIFACT üzeneteket (a kereskedelemben jellemzően az EANCOM, az autóiparban pedig az ODETTE/VDA-gyökerű EDIFACT subseteket). Négyrészes sorozatunkban lépésről lépésre bemutatjuk az abas–EDIFACT konverzió szabályait, az interfész-architektúrát és a leggyakoribb éles üzembeli buktatókat.

Az első részben lefektetjük a technikai alapokat: hogyan épül fel az adatcsere az abas ERP (Vartab, EDP, FOP/EFOP, abas EDI-interfész) és a külső EDI-konverter között, milyen szintaktikai és üzleti szabályok vonatkoznak az EDIFACT borítékra, és hol szoktak elcsúszni a projektek már az első üzenet bekötésekor.

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

Hogy a konverziós szabályokat valósághű iparági környezetben vizsgálhassuk, a négy részen keresztül egy tipikus hazai abas-felhasználó folyamatait követjük végig:

Pannon-Autóalkatrész Kft. – magyarországi fém- és műanyagipari gyártó és forgalmazó középvállalat, amely abas ERP-t használ. Ő a „mi” oldalunk (GLN: 5990000000108).
EuroAuto Tier-1 GmbH – németországi autóipari rendszerbeszállító vevő, amely keretszerződés alapján UN/EDIFACT D.96A / D.07A lehívásokat (DELFOR, DELJIT) küld, és szigorú csomagolási hierarchiával ellátott szállítólevelet (DESADV), valamint számlát (INVOIC) vár (GLN: 4012345000016).
Barkács-Lánc Zrt. – hazai barkács- és műszaki áruházlánc, amely EANCOM D.96A szerint küld egyedi megrendeléseket (ORDERS) a központi elosztóraktárába (GLN: 5990000000207, raktár GLN: 5990000000214), és ORDRSP, DESADV, illetve INVOIC üzeneteket fogad.

A példában szereplő termék egy sajtolt féktartó konzol és annak kiskereskedelmi szerelőkészlete: belső abas azonosítószáma (nummer) A-40210, keresőszava (such) FEKKONZOL-40, GTIN-kódja 5991234004023, az EuroAuto vevői cikkszáma pedig EA-99812-B.

Hogyan jut ki és be az adat az abas ERP-ből?

Az abas ERP objektumorientált adatbázis-architektúrára épül, amelynek gerincét a Vartab (változótábla) adja. Minden törzsadatnak (vevő, cikk, csomagolóeszköz) és minden bizonylatnak (vevői rendelés, keretrendelés/lehívás, szállítólevél, számla) fejszintű (Head) és táblázatszintű (Table) mezői vannak, amelyekre német és angol változónevekkel is hivatkozhatunk, sőt a standardot egyedi y... (felhasználói) mezőkkel bővíthetjük.

Az abas nem közvetlenül az EDIFACT karakterfolyamot állítja elő a bizonylat mentésekor, hanem egy kétlépcsős integrációs architektúrát használ, amelyben az abas belső interfésze és egy EDI-konverter (middleware) osztozik a feladatokon:

Belső abas EDI-interfész és FOP/EFOP eseménykezelés: Amikor egy bizonylat (pl. szállítólevél vagy számla) az abasban elkészül, egy FOP (Flexible Oberflächenprogrammierung) vagy Java alapú EFOP eseménykezelő ellenőrzi az üzleti előfeltételeket, majd az abas EDI-modulon (vagy dedikált export Infosystemen) keresztül strukturált köztes állományt (XML, strukturált flat-file vagy JSON) állít elő.
EDP (Electronic Data Processing) / REST API adatkapcsolat: Bejövő irányban a külső konverter az abas EDP-interfészén (vagy az abas REST API-n / EDI-import táblákon) keresztül hozza létre vagy módosítja az abas objektumokat – pontosan úgy, mintha egy felhasználó töltené ki a képernyőmaszkot, beleértve az összes mezőszintű FOP-validációt.
EDI-konverter (middleware) és kommunikációs átjáró: A konverter végzi a fizikai B2B kommunikációt (AS2, OFTP2, SFTP), a szintaktikai ellenőrzést, az EDIFACT szegmensek és az abas köztes struktúra közötti leképezést (mapping), valamint a szintaktikai nyugták (CONTRL) kezelését.

Réteg / Komponens	Feladat az abas–EDIFACT folyamatban	Tipikus eszköz / technológia
Adatbázis és törzsadatok	Bizonylatok, vevő–cikk keresztreferenciák, egyedi `y...` EDI-jelzők tárolása	abas Vartab (Fej + Táblázat mezők)
Üzleti szabályok és triggerek	Kötelező mezők ellenőrzése mentéskor, automatikus export indítása	FOP / EFOP (Event Handler)
Alkalmazási interfész	Tranzakcióbiztos írás és olvasás az abas adatbázisba üzleti logikával	abas EDP, abas EDI-Schnittstelle, REST API
Konverzió (Mapping)	abas köztes struktúra ↔ UN/EDIFACT (EANCOM / ODETTE subset)	Külső EDI-konverter / szolgáltatói platform
B2B csatorna	Titkosított adatátvitel, aláírás, kézbesítési nyugták (MDN / EERP)	AS2, OFTP2 (autóipar), SFTP, VAN

Az EDIFACT boríték és a konverzió alapszabályai

Akár kereskedelmi láncnak küldünk EANCOM üzenetet, akár autóipari vevőnek ODETTE/VDA-alapú EDIFACT fájlt, az üzenet külső „borítékja” (envelope) szigorú szintaktikai szabályokat követ:

UNA:+.? '
UNB+UNOD:3+5990000000207:14+5990000000108:14+261021:0830+00000451++ORDERS'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+BL-2026-88412+9'
DTM+137:20261021:102'
...
UNT+18+1'
UNZ+1+00000451'

1. Elválasztójelek és a feloldójel (escape) szabálya

Az UNA:+.? ' sor rögzíti az EDIFACT öt vezérlőkarakterét: komponenselválasztó (:), adatelem-elválasztó (+), tizedesjel (.), feloldójel/escape (?) és szegmenslezáró ('). Az abasból érkező szöveges mezőkben (például cikk-megnevezésben vagy szállítási megjegyzésben) gyakran szerepel a + vagy a : jel (pl. Csavar M8+anyával 1:2). Szabály: az abas exportnak nem szabad kézzel csonkítania ezeket a szövegeket; a konverter feladata, hogy minden vezérlőkarakter elé automatikusan beszúrja a ? feloldójelet (Csavar M8?+anyával 1?:2).

2. Tizedesjel és számformátumok

Magyar és német abas-környezetben a képernyőn és a riportokban a tizedeselválasztó gyakran a vessző (12,50), és előfordulhat ezres tagolás is. Az EDIFACT szabványban (ha az UNA 4. karaktere .) kizárólag a pont elfogadott tizedesjelként, ezres elválasztó pedig egyáltalán nem szerepelhet, különben a fogadó parser szintaktikai hibával elutasítja az üzenetet. Az EDP/export rétegben ezért mindig gépi, lokalizációfüggetlen számformátumot kell használni.

3. Azonosítók szétválasztása: belső kulcs vs. külső EDI-kód

Az abasban minden rekordnak van belső adatbázis-azonosítója (pl. (184,0,0)), azonosítószáma (nummer, pl. 70045) és keresőszava (such). Ezeket a belső azonosítókat a külső partner nem ismeri. Az EDIFACT UNB és NAD szegmensekben kizárólag nemzetközi vagy a partner által kiosztott azonosító szerepelhet:

Kiskereskedelemben a 13 jegyű GLN (14-es minősítő az UNB-ben, ::9 a NAD-ban);
Autóiparban a DUNS-szám, ODETTE-azonosító vagy a vevő által nekünk kiosztott beszállítói kód (NAD+SU+987654::92).

A 4 részes sorozat üzenettérképe

A sorozat következő részeiben az alábbi üzleti folyamatokat és azok abas ↔ EDIFACT leképezési szabályait vesszük végig:

Folyamat	EDIFACT üzenet	Irány	abas ERP objektum / folyamat	Sorozat
Egyedi vevői megrendelés	`ORDERS`	Vevő → abas	Vevői rendelés (Sales Order) létrehozása EDP-n keresztül	2. rész
Rendelés-visszaigazolás	`ORDRSP`	abas → Vevő	Vevői rendelés visszaigazolása (állapot, mennyiség, határidő)	2. rész
Szállítási / gyártási lehívás	`DELFOR` / `DELJIT`	Vevő → abas	Keretrendelés (Blanket Order) és szállítási lehívás (LAB/FAB)	2. rész
Szállítólevél (ASN)	`DESADV`	abas → Vevő	Szállítólevél (Lieferschein) + csomagolási hierarchia / SSCC	3. rész
Kereskedelmi számla / Jóváírás	`INVOIC`	abas ↔ Vevő	Számla (Rechnung), Jóváírás, illetve Self-Billing egyeztetés	4. rész

Nyugtaszintek: mikor tekinthető feldolgozottnak egy üzenet?

Az abas–EDIFACT integráció üzemeltetésének alapfeltétele, hogy különbséget tegyünk a három visszaigazolási szint között:

Kommunikációs nyugta (AS2 MDN / OFTP2 EERP): Csak azt igazolja, hogy a titkosított fájl megérkezett a partner szerverére.
Szintaktikai nyugta (EDIFACT CONTRL): A fogadó EDI-konverter igazolja vissza, hogy az üzenet megfelel az EDIFACT nyelvtannak (UCI / UCM szegmensek).
Alkalmazási / ERP szintű feldolgozás (APERAK vagy belső EDP-státusz): Azt jelzi, hogy az abas EDP-interfész ténylegesen létrehozta-e a rendelést vagy frissítette-e a lehívást. Ha egy cikk zárolva van az abasban, a CONTRL pozitív lesz, de az EDP-import hibára fut!

Gyakori buktatók a gyakorlatban

Karakterkódolás (UNOC vs. UNOD / UNOW): A nyugat-európai sablonokból átvett UNOC (ISO 8859-1) nem tartalmazza a magyar ő és ű (valamint a közép-európai č, ł, ř) karaktereket. Ha az UNB-ben nem UNOD:3 (ISO 8859-2) vagy UNOW:4 (UTF-8) szerepel, a magyar telephelynevek és megjegyzések sérülnek.
Mezőhossz-csonkolás és ékezetes bájtszám: Az EDIFACT NAD szegmens név- és utcamezői 35 karakterre (an..35) korlátozottak, míg az abasban egy megnevezés vagy címmező ennél hosszabb lehet. UTF-8 használatakor ügyelni kell arra, hogy a vágás karakter- és ne bájthatáron történjen, és a 35 karakter feletti rész a következő C080/C059 komponensbe csorduljon át.
Interaktív FOP-üzenetek a háttérfolyamatban: Klasszikus abas-buktató, amikor egy meglévő képernyő-FOP figyelmeztető ablakot (box vagy menu utasítást) dob fel például hitelkeret-túllépéskor vagy eltérő csomagolási egységnél. Ami a grafikus felületen (GUI) egy kattintás az ügyintézőnek, az a háttérben futó EDP-folyamatot megakasztja vagy megszakítja. Szabály: az FOP-kódban mindig vizsgálni kell a futási módot (háttér/EDP vs. interaktív), és EDI-import esetén a figyelmeztetést naplózni vagy dedikált hibastátusz-mezőbe (pl. yedierr) írni kell.
Teszt és éles környezet összecsúszása: Az UNB szegmens 11. adateleme (0035 = 1) jelzi a tesztüzenetet. Ha a konverter ezt nem vizsgálja, egy partner által küldött tesztlehívás az éles abas mandantban felülírhatja a valódi gyártási tervet.

Összefoglalás

Az abas ERP rugalmas Vartab- és FOP/EDP-architektúrája kiváló alapot ad az automatizált adatcseréhez, de a stabil működéshez a külső EDIFACT konverziót és a belső abas-validációt szigorúan szét kell választani. A konverternek kell kezelnie a szabványos szintaxist, a karakterkódolást és az azonosító-fordítást, míg az abas FOP-szabályoknak felügyelet nélkül (headless módban) is üzembiztosan kell futniuk.

A következő részben a bejövő igényeket vesszük górcső alá: megnézzük, hogyan lesz az EANCOM ORDERS üzenetből abas vevői rendelés és ORDRSP visszaigazolás, valamint hogyan kezeljük az autóipari DELFOR és DELJIT lehívások kumulált mennyiségeit (FZ-számait).

Ha abas ERP rendszeréhez keres megbízható EDI-konverziós megoldást, kérjen kötelezettségmentes ajánlatot, vagy tesztelje EDIFACT állományait ingyenes EDIFACT-validátorunkkal.