4; Formátum - konverzió

Mindenki ismeri az ügyviteli rendszer vagy vállalatirányítási rendszer,

rövidítve ERP fogalmát. Ez egy olyan szoftver, ami összefogja a vállalat
működését a beszerzéstől, a raktárnyilvántartásig, elvégzi a számlázást,
a bérszámfejtést és megfelelő kiegészítő modulok segítségével képes
elektronikus dokumentumokat kezelni. Az EDI szempontjából a
dokumentumkezeléssel foglalkozunk.
A piaci kínálatban különböző vállalatirányítási rendszerek léteznek és
ezek többsége egymástól eltérő belső dokumentumformátumot használ.
Az EDI szempontjából ennek a jelentősége az, hogy a feldolgozás során
a formátumok bármelyike szabványos üzenetté alakítható. Szinte minden
belső használatú fájlból lehet szabványos üzenetet generálni és fordítva,
ha az adattartalom megfelelő. Így biztosítható, hogy bármely egyedi
rendszerrel rendelkező vállalat csatlakozhat az EDI világához.
A legtöbb esetben alapesetben egy ügyviteli szoftver még nem alkalmas
elektronikus adatcserére, mert a belső adattartalma ritkán alkalmas
szabványos EDI-üzenetek generálására. Tehát az első feladat az, hogy a
rendszerből kinyert fájlt fel kell tölteni a szabványos üzenethez
szükséges adattartalommal. Amikor elektronikus dokumentumról
beszélünk, el kell vonatkoztatnunk az eddig általánosan ismert papír
alapú dokumentumoktól. Nem feltétlenül igaz, hogy egy papíron létező
dokumentumot át tudunk ültetni közvetlenül elektronikus formába.
A kereskedelmi példáknál maradva, egyszerű dolgunk van egy
megrendelő, egy árukatalógus vagy egy raktárjelentés esetén. Ekkor a
partnerrel kell megegyeznünk az adatcsere tartalmáról. Viszont egy
számla elkészítésénél az adott ország szabályait kell betartani. Tehát
összegezve, a formátumkonverzió lényege, hogy az azonosan értelmezett
adattartalom megtartása mellett a további feldolgozáshoz szükséges

1
formátumra alakítsuk az adott fájlt.
Ezt a munkafolyamatot gondos előkészítés után, a megfelelő
cégspecifikus dokumentumok ismeretében lehet elvégezni. Léteznek erre
a célra speciális programok, de egy nagy gyakorlatú programozó, aki jól
ismeri az adatcsere sajátosságait akár C# vagy java
fejlesztőkörnyezetben is elvégezheti.
A formátumkonverzió lényegét egy egyszerű példán fogjuk szemléltetni.
Itt a beérkező szabványos EDIFACT formátumból, egy CSV (comma
separated value - vesszővel elválasztott értékek) formátummá történő
fordítást látunk, ahol az egyes adatmezőket ';' karakterrel választottuk el.

BGM+220+91731111'
DTM+137:20090622:102'
DTM+2:20090626:102'
NAD+SU+5990035745005::9'
NAD+BY+5990020010002::9'
NAD+DP+5990020011603::9'
CUX+2:HUF:9'
LIN+1++5999509872629:EN'
PIA+1+700819:IN'
PIA+1+1987262:SA'
IMD+B++:::IRATGYUJTO'
QTY+21:32:PCE'
PRI+AAA:468.0000'
LIN+2++5999509872551:EN'
PIA+1+609203:IN'
PIA+1+7987255:SA'
IMD+B++:::SIGMA PENZT.SZAL'
QTY+21:2:PCE'
PRI+AAA:471.0000'

Megrendelő EDIFACT formátumban

2
 F10;001;91731111;2009/06/22;2009/06/26;HUF;21875;
F12;002; SU;5990035745005;
F12;003;BY;5990020010002;
F12;004;DP;5990020011603;
T10;005;001;5999509872629;700819;1987262;32.00;DB;468;IRATGYUJTO;
T10;006;002;5999509872551;609203;7987255;2.00;DB;471;SIGMA PENZT.SZAL;

Megrendelő CSV formátumban

Mi a legfontosabb, amit észre kell venni a két adatsorban? Az, hogy az

adattartalom megegyezik. Emellett mi a legfeltűnőbb különbség? Az,
hogy különböznek a formátumok, az egyes struktúrák másképpen
különböztetnek meg egyes adatokat.
Mire is gondolunk? Az EDIFACT fájl első sora ez: BGM+220+ 91731111'.
Részletesen, BGM - bigining of message, az üzenet kezdete,
elválasztójel, 220 - kódtábla szerint ez rendelést jelent, elválasztójel,
dokumentum azonosító, itt rendelés száma. A házi szabványunk szerint
készült CSV-ben ebből csak egy adatot a rendelés számát jelenítjük meg,
az első sor harmadik mezőjében. A CSV-ben nincsenek adatminősítők,
az egyes adatok jelentését az elfoglalt helyük szerint azonosítjuk be. Ezt
a logikát követve az első sor negyedik elemeként az adott dokumentum
keletkezésének idejét helyezzük el ( 2009/06/22 ), ami az EDIFACT
szabvány szerinti fájlban a következő formában jelenik meg:
DTM+137: 20090622 :102' a kódtábla szerint az idő megadásánál a 137, a
dokumentum keletkezésének dátuma, a 102 pedig egy formátumminősítő
(CCYYMMDD).
Ha ezt a pár adatot sikerült beazonosítani, könnyedén meglelhetjük
mindkét fájlban a következő adatokat is: A CUX mindig egy pénznemet
ad meg, Az EN-el egy termék vonalkódját jelezzük, PIA-IN a saját

3
cikkszámunk, PIA-SA a partner cikkszáma, QTY+21 a rendelt
mennyiséget és a mennyiségi egységet tartalmazza, az IMD egy rövid
szöveges leírása az adott cikknek, a PRI+AAA pedig a termék nettó árát
jelenti.
Ha ezek az adatkeresések sikeresek voltak, rögtön észre kell vegyünk
egy másik különbségek az egyes adatformátumokban! Ha azt
feltételezzük, hogy ez a CSV formátum egy ERP rendszer által
beolvasható fájl, akkor a fordítás során kell gondoskodni arról, hogy az
egyes adatelemek milyen formátumban jelennek meg. A különbségek
nyilvánvalóak. A dátumnál 20090622 - ből 2009/06/22 - re kell alakítani. A
rendelt mennyiségnél az 2-ből 2.00 lesz, az árnál a 471.0000 -ből 470, a
mennyiségi egységnél a PCE (peace - darab) -ból DB lett. Ezeket a
formátumváltásokat a fordítói munka előtt részletesen tisztázni kell,
hogy feldolgozható fájl keletkezzen.
Hasonló a feladat, ha XML formátumban jelenítjük meg az adatokat.

4
 <?xml version="1.0" encoding="ibm852"?>
<fejlec>
<elado>
<eladogln>5990035745005</eladogln>
</elado>
<vevo>
<vevogln>5990020010002</vevogln>
</vevo>
<szallitasicim>
<szallitasicimgln>5990020011603</szallitasicimgln>
</szallitasicim>
<megrendeles>
<azonosito>91731111</azonosito>
<kiallitasdatum>20100714</kiallitasdatum>
<szallitasdatum>20100727</szallitasdatum>
<penznem>HUF</penznem>
</fejlec>
<tetelek>
<tetel id="1">
<eankod>5999509872629</eankod>
<sajatkod>700819</sajatkod>
<partnerkod>1987262</partnerkod>
<termeknev>IRATGYUJTO</termeknev>
<rendeltmenny>32</rendeltmenny>
<nettoegysegar>468</nettoegysegar>
<tetel id="2">
<eankod>5999509872551</eankod>
<sajatkod>609203</sajatkod>
<partnerkod>7987255</partnerkod>
<termeknev>SIGMA PENZT.SZAL</termeknev>
<rendeltmenny>2</rendeltmenny>
<nettoegysegar>471</nettoegysegar>
</tetelek>
</megrendeles>

Megrendelő XML formátumban

A formátumkonverzió az EDI egyik legfontosabb része, amennyiben

ilyen típusú feladattal találkoznánk érdemes szakember véleményét

5
kérni.