Elektronikus adatcsere alkalmazása a kormányzatban TARTATOMJEGYZÉK 1. BEVEZETÉS... 1

Elektronikus adatcsere alkalmazása a kormányzatban

TARTATOMJEGYZÉK

1. BEVEZETÉS ..................................................................................................................................................... 1 2. EDI ALAPISMERETEK .................................................................................................................................. 3 2.1. MIÉRT AZ ELEKTRONIKUS ADATCSERE?......................................................................................................... 3 2.1.1. A telefax és az E-mail sajátosságai ....................................................................................................... 3 2.1.2. Az EDI sajátosságai .............................................................................................................................. 4 2.2. MI AZ EDI? ................................................................................................................................................... 6 2.2.1. Az elektronikus adatcsere definíciója ................................................................................................... 6 2.2.2. Hol célszerû EDI-t alkalmazni? ............................................................................................................ 6 2.2.3. Az EDI rendszerek felépítése ................................................................................................................. 7 2.2.4. EDI szabványok................................................................................................................................... 13 3. AZ UN/EDIFACT SZABVÁNY ..................................................................................................................... 15 3.1. TÖRTÉNELMI HÁTTÉR .................................................................................................................................. 15 3.2. A UN/EDIFACT SZERVEZET STRUKTÚRÁJA ............................................................................................... 15 3.3. NYUGAT-EURÓPAI EDIFACT TANÁCS ....................................................................................................... 16 3.4. ÜZENETFEJLESZTÉSI CSOPORTOK................................................................................................................. 17 3.5. UN/EDIFACT ÉPÍTÕKOCKÁK ..................................................................................................................... 18 3.5.1. UN/EDIFACT katalógusok.................................................................................................................. 18 3.5.2. Egy UN/EDIFACT üzenet bemutatása ................................................................................................ 19 3.5.3. Adatcserék ........................................................................................................................................... 19 3.5.4. Funkcionális csoportok ....................................................................................................................... 19 3.5.5. Üzenetek (vagy tranzakciók)................................................................................................................ 20 3.5.6. Szegmensek.......................................................................................................................................... 20 3.5.7. Kiszolgáló szegmensek ........................................................................................................................ 22 3.5.8. Adatelemek .......................................................................................................................................... 24 3.5.9. Az üzenet állapota ............................................................................................................................... 28 3.5.10. Üzenet alkatrészek (subset-ek)........................................................................................................... 28 3.5.11. Üzenet keretrendszerek...................................................................................................................... 29 3.5.12. UN/EDIFACT kísérleti és egységes tartalomjegyzékek ..................................................................... 30 3.5.13. Alternatív karakterkészletre vonatkozó rendelkezés .......................................................................... 31 3.5.14. Biztonsági szabványok a UN/EDIFACT-ban..................................................................................... 31 4. EDI SZOFTVEREK........................................................................................................................................ 32 4.1. EDI ÁTJÁRÓK (EDI GATEWAY-EK, SZERVEREK) .......................................................................................... 32 4.2. EDI MUNKAÁLLOMÁSOK ............................................................................................................................. 34 4.3. WEB EDI SZOFTVEREK ............................................................................................................................... 34 5. AZ ADATBIZTONSÁG KEZELÉSE............................................................................................................ 35 5.1. AZ ADATBIZTONSÁG ELEMEI ........................................................................................................................ 35 5.2. SZIMMETRIKUS ÉS ASZIMMETRIKUS KULCS KEZELÉSI ELJÁRÁSOK, ELEKTRONIKUS KÖZJEGYZÉS................. 37 5.3. ASZIMMETRIKUS KULCSKEZELÉSI ELJÁRÁS X.400, X.500 KÖRNYEZETBEN ................................................. 38 6. A KORMÁNYZATI EDI PROJEKTEK SORÁN ELVÁRT SZABVÁNYOK ......................................... 40 6.1. EDIFACT ................................................................................................................................................... 40 6.2. X.400 .......................................................................................................................................................... 40 6.3. X.500 .......................................................................................................................................................... 40

i


7. JOGI HÁTTÉR ............................................................................................................................................... 41 7.1. A JOGI SZABÁLYOZÁS ÁLTALÁNOS PROBLÉMÁI ............................................................................................ 41 7.2. EDI PROJEKTEKKEL KAPCSOLATOS SZERZÕDÉSEK....................................................................................... 41 7.3. ADATCSERE SZERZÕDÉS .............................................................................................................................. 42 7.4. AZ EDI SZERZÕDÉS TECHNIKAI TARTALMA ................................................................................................. 42 7.5. ÜZENETMEGVALÓSÍTÁSI KÉZIKÖNYV........................................................................................................... 43 7.6. HÁLÓZATI SZOLGÁLTATÁSOK SZERZÕDÉSE.................................................................................................. 43 8. EDI AZ EU-BAN ............................................................................................................................................. 44 8.1. STATISZTIKAI ADATGYÛJTÉSSEL KAPCSOLATOS PROJEKTEK ........................................................................ 45 8.2. SZOCIÁLIS ELLÁTÁSSAL, MUNKAÜGGYEL KAPCSOLATOS PROJEKTEK ........................................................... 48 8.3. A NEMZETKÖZI SZÁLLÍTMÁNYOZÁSSAL, VÁM ÉS ADÓZÁSSAL KAPCSOLATOS PROJEKTEK .......................... 49 9. IDEGEN KIFEJEZÉSEK MAGYARÁZATA (GLOSSARY)..................................................................... 50

ii

1.

BEVEZETÉS

Jelen ajánlás a Miniszterelnöki Hivatal Informatikai Helyettes Államtitkárának megbízásából készült. Hazánk EU csatlakozása, NATO tagsága és egyre aktívabb részvétele más nemzetközi szervezetek munkájában ugyancsak elıtérbe állítja az EDI alkalmazását, mint olyan technikai megoldást, amelynek segítségével - a jogi és eljárási harmonizáción felül - Magyarország beilleszkedhet a mind nagyobb tömegő információ (adat) cseréjét jelentı nemzetközi kapcsolatrendszerbe.

Az informatikai társadalom A kilencvenes években az informatika mind szélesebb körben jelenik meg az állampolgárok és a gazdasági élet szereplıinek mindennapi életében, valamint mindennapi kapcsolataikban az ıket kiszolgáló állammal. Az informatika fejlıdése ma már visszahat a társadalom fejlıdésére is azáltal, hogy az államhatalom és az állampolgárok, gazdasági szereplık viszonyrendszerében új szolgáltatásokat, minıségileg is magasabb szintő lehetıségeket kínál. A fejlett országokban kiterjedt kutatások folynak az “informatikai társadalom” hatásairól. Ezek a hatások egyaránt érintik a személyeket, a gazdálkodó szervezeteket és az állami intézményeket. Az informatikai társadalom elsısorban nem azt jelenti, hogy az állampolgárok többsége rendelkezik Internet (vagy bármilyen más számítógépes) hozzáférési lehetıséggel, hanem azt, hogy az állam, a kormányhivatalok, az önkormányzatok és a közigazgatás egyéb szereplıi (pl. társadalombiztosítás) olyan saját belsı informatikai rendszereket alkalmaznak, amelyekkel képesek a hozzájuk fordulók elektronikus úton történı informálására, sıt az ügyek egy részében kiszolgálására is. Mivel az állampolgár nem feltétlenül tudja, hogy ügyében melyik hivatal az illetékes, az esetenként a konkrét ügyben több hivatal is érintve van, a fenti követelmény azt is jelenti, hogy az egyes hivataloknak (azok informatikai rendszereinek) együtt kell mőködniük egymással. Az együttmőködés vagy azt feltételezi, hogy a rendszereket egységes informatikai koncepciók alapján, egységes eszközparkra építve alakították ki, vagy - mivel az elızı feltétel irreális szükségessé teszi e rendszerek között az egységes kapcsolatrendszer kialakítását. E kapcsolatrendszer eszköze az EDI (Electronic Data Interchange), amely a kapcsolódás típusaira és az adatok struktúrájára nézve nemzetközi szabványoknak megfelelıen, az alkalmazott számítástechnikai eszközöktıl független módon teszi lehetıvé az információcserét különbözı informatikai rendszerek között. Az EDI nemcsak az államigazgatási rendszerek egymás közti adatcseréjét, hanem e rendszerek és a nagyvállalatok közti adatkapcsolatokat is biztonságosabbá és átláthatóvá teszi - pl. a kötelezı adatszolgáltatások.

Az elektronikus kereskedelem Az elektronikus kereskedelem általános fogalom, amely a kereskedelmi tranzakciók informatikai eszközökkel, számítógép hálózatok közvetítésével történı lebonyolításán túl, a technikai eszközöket, módszereket és szolgáltatásokat is jelenti, amelyek az elektronikus társadalom más területein, így az államigazgatás elektronikus szolgáltatásaiban is felhasználhatók. A fejlett országokban egyre nagyobb teret kap az államigazgatási szervek on-line elérése, nem csupán az állampolgárok gyors és olcsó informálása céljából (honlapok fenntartása az aktuális információk, rendeletek, stb. közzétételére), hanem a tényleges ügyintézés eszközeként. Így jelentek meg az elektronikus rendszerek a központi 1


kormányzati-, és önkormányzati közbeszerzés területén, majd a rutinszerő adatszolgáltatásokban és az egyszerőbb ügyek intézésében is.

Az EDI Az EDI a nagytömegő adatok informatikai rendszerek közti (tehát nem személyek és számítógépek közötti), gyakori cseréjének eszköze, széleskörő partnerkapcsolati rendszerben. Az államigazgatásban tehát az EDI-nek az államhivatalok egymás közötti kapcsolat-rendszerében, valamint a gazdasági élet szereplıi (elsısorban nagyvállalatok) és az állami intézmények közötti adatcserében van meghatározó szerepe. Az EDI alkalmazása ott eredményez számottevı megtakarításokat, ahol több száz, esetleg több ezer résztvevıs partneri körben azonos eljárások szerinti adattovábbításra van szükség a dokumentum továbbítás biztonsági igényeivel, és ahol a partnerek mindegyike rendelkezik a saját feladatait segítı informatikai rendszerrel. A gazdálkodó szervezetek és az államigazgatás közti kapcsolatrendszer tipikusan ilyen modell, ahol az egyes résztvevık különbözı számítógépeken futó, eltérı alkalmazási rendszerekkel oldják meg feladataikat, és ezeket a rendszereket kell valamilyen egységes, szabványos úton, a manuális munka minimálisra csökkentésével, lehetıleg automatikusan összekapcsolni.

2

2.

EDI ALAPISMERETEK

2.1.

Miért az elektronikus adatcsere?

A különbözı üzleti vállalkozások hagyományosan papíron kommunikálnak egymással. Az ilyen kommunikáció kétféle formája ismert: a strukturálatlan (pl. üzenetek, emlékeztetık és levelek) és a strukturált (vételi megbízások, megrendelések, feladási értesítık, vámnyilatkozatok és más vámokmányok, engedélyek stb.). A strukturálatlan kommunikációk általában személyek közötti egyszeri, azaz alkalmi információcserét jelentenek, nem tartoznak a “business as usual” folyamatai közé. Ezzel szemben a kommunikáció strukturált formái általában részei a szervezet belsı életét befolyásoló folyamatoknak, ezeket az okmányokat az esetek többségében nem egy bizonyos személynek, hanem egy szervezet egészének továbbítják. Ily módon ezek a kommunikációk folyamatok közötti, vagy személy és folyamat közötti kommunikációként jellemezhetık. Amikor egy szervezet dönt arról, hogy javítani szeretné tevékenységének hatékonyságát vagy hatásfokát, a megvalósítandó célkitőzések szervezetenként általában nem azonosak. A szervezetek szeretnék olcsóbbá tenni mőködésüket, gyorsabban szeretnének mőködni, az eddiginél kevesebb problémával és rendkívüli eseménnyel szeretnék elvégezni feladataikat. A célok megvalósításának többféle módja létezik – a teljes üzletmenet felülvizsgálatától és újratervezésétıl a mindenkori gyakorlat kisebb módosításáig. A legáltalánosabb eszköz vagy technika azonban a számítástechnikai eszközök korábbinál kiterjedtebb alkalmazása, az emberek által manuálisan végzett feladatok gépesítése és – mindezek eredményeként – a papírmunka egy részének felszámolása (ami már önmagában is elegendı számos célkitőzés megvalósításához). Egyszerőbb a feladat akkor, ha a folyamat nem lépi túl egy bizonyos szervezet kereteit, a folyamatok többsége azonban a korábban már említett, papírmunka alapján mőködı kommunikációk valamelyikével kezdıdik vagy ér véget. Ezért amennyiben valóban javítani szeretnénk az addigi munkán és valóban változtatni akarunk bizonyos folyamatokon, szükség van valamilyen technikára, amely lehetıvé teszi az ilyen tevékenységek gépesítését, valamint megteremti annak feltételeit, hogy a különbözı szervezeteknél rendszerbe állított számítógépek kapcsolatot létesíthessenek egymással. Többféle ilyen technika létezik, leegyszerősítve azonban elmondható, hogy az elektronikus posta (E-mail) alkalmas a nem strukturált információk számítógépes átvitelére, az elektronikus adattovábbítás vagy adatcsere (EDI) kezeli a strukturált információk számítógépek közötti átvitelét. Ez utóbbi, strukturált információk átvitelét kell gépesíteni ahhoz, hogy hatékonyabbá tegyük folyamatainkat. 2.1.1. A telefax és az E-mail sajátosságai A strukturálatlan dokumentumok átvitelének egyre elterjedtebb eszköze a fax. Ez a mechanizmus lehetıvé teszi, hogy valamilyen szövegszerkesztı segítségével elkészítsünk egy dokumentumot és fax formátumban közvetlenül megküldjük azt a címzettnek úgy, hogy a dokumentumot nem nyomtatjuk ki. A fax – hagyományos fax használata esetén – egy papír recepiens (fogadó), de a dokumentum számítógépen is fogadható, ahol az operátor a képernyın, digitalizált formában megtekintheti a 3


dokumentumot. Ugyanakkor a címzett nem teheti át a fax képet egy szövegszerkesztı programba, nem eszközölhet módosításokat a fax szövegében, mielıtt tovább küldené azt egy harmadik személynek. (Ez természetesen nem vonatkozik azokra az esetekre, amikor egy olyan strukturált dokumentumról van szó, amelynek a formátumát a felek elızetesen egyeztették – ez esetben ez az EDI egy bizonyos formája, amely azonban nem teszi lehetıvé az EDI összes elınyének érvényesítését, hiszen a címzettnek szüksége van egy kifejezetten ennél a kereskedelmi partnernél használható fax értelmezı szoftverre.) Az érkezı fax formátuma általában nem teszi lehetıvé a szöveg közvetlen feldolgozását egy szövegszerkesztı programmal. Ezzel szemben egy E-mail dokumentum esetén a címzett amellett, hogy képes fogadni a dokumentumot, megtekinteni azt a képernyın, közvetlenül átdolgozhatja azt saját szövegszerkesztı programjával. Itt az a fontos, hogy miközben a fax és az E-mail az elektronikai átvitel segítségével lehetıvé teszi a gyors kapcsolatteremtés és üzenetváltás elınyeinek kihasználását, csak az E-mail biztosítja a dokumentum pontos fogadásának és szerkesztésének lehetıségét úgy, hogy nem szükséges ismételten leírni a szöveget. Ennyiben különbözik egymástól a fax és az E-mail, azaz ennyivel alkalmasabb az E-mail a számítástechnikai alkalmazásokban való felhasználásra. Mindkét példánál azonban valahonnan meg kell kapni vagy be kell léptetni az információt. A személyek közötti kommunikációban ez nem jelent gondot, azokban az esetekben azonban, amikor két szervezetnél léteznek olyan folyamatok, amelyeknek kommunikálniuk kell egymással, teljes gépesítésre van szükség, és ez esetben a legalkalmasabb eszköz az EDI. 2.1.2. Az EDI sajátosságai Az EDI a strukturált adatok két számítógép közötti cseréjének technikája; a módszer lehetıvé teszi, hogy az információt fogadó számítógép felhasználói programja az információ ismételt beírásának vagy a manuális beavatkozás minden egyéb formáinak mellızésével feldolgozza a kapott információt. Ennek köszönhetıen az EDI, az üzletmenet és az ügyviteli folyamatok hatékonyabbá tételének egyik fontos eszközévé vált. A meglévı ügyviteli folyamatok gépesítése során az EDI elkészíti az egyes forgalomban levı dokumentumok adatainak elektronikus változatát, és ehhez egy olyan struktúrát használ, amelyet a feladó és a címzett ügyviteli alkalmazásai egyaránt fel tudnak ismerni. A feladó alkalmazása automatikusan hozza létre ezt a strukturált dokumentumot, amelyet a címzett ügyviteli alkalmazása automatikusan fel tud dolgozni. (Ebben az összefüggésben az “ügyviteli alkalmazás” egy szervezeten belül a belsı folyamatok mőködtetéséhez vagy gépesítéséhez használt számítástechnikai alkalmazás.) Strukturálatlan elektronikus dokumentumok számítógépek közötti cseréje esetén ki lehet használni az információ gyors átvitelének elınyeit, általában azonban nem lehet kikerülni a dokumentumok ismételt leírását és a manuális beavatkozást. Az EDI különösen hatékony ott, ahol egynél több szervezettel azonos jellegő adatokat kell kicserélni; erre van szükség többek között akkor, ha egy kereskedı több különbözı szállítótól szerzi be az árut, vagy ha egy szállító több különbözı kereskedınek értékesíti portékáját. Mindegyik esetben számos ügyviteli jellegő dokumentum keletkezik a megrendelésektıl a számlákon keresztül a kifizetési bizonylatokig; ezeket a dokumentumokat különbözı szervezeteknek kell megküldeni, és ezek mindegyike a dokumentumok bármelyikének átvételét követıen alapvetıen azonos tevékenységeket végez. A dokumentumok struktúrája azonos és – ami talán még ennél is fontosabb – az egyes szervezetektıl befolyt információk is egy elızetesen egyeztetett, egységes

4

struktúrában érkeznek. Mindez azt jelenti, hogy az érkezı bizonylatok feldolgozásának gépesítése az összes meglevı és új EDI partner számára elınyös. Az EDI az adatátvitel költségeit tekintve akkor a leghatékonyabb, ha nagy és ismétlıdı adatállományok kicserélésére van szükség, és ehhez meghatározott adatfeldolgozó mőveleteket használnak, ami lehetıvé teszi a teljes gépesítést. Az alkalmazott folyamatok gépesítése az elektronikus adatcsere helyett elektronikus dokumentumcsereként értelmezhetı; a folyamatok ilyen értelmezése már önmagában is számos elınnyel jár. Az EDI azonban olyan indítómechanizmus lehet, amely lehetıvé teszi a már alkalmazott folyamatok felülvizsgálatát; esetenként sokkal hatékonyabb megoldás új adatcserék tervezése úgy, hogy az új adatcserék nem szükségszerően a meglevı bizonylat-mozgások alapján jönnek létre. Az 1. sz. ábrán négy olyan szervezetet mutatunk be, amelyek az EDI segítségével cserélik ki egymással adataikat. A kör jelzi egy EDI implementáció elméleti határait; a folyamat jobboldalt a szervezetek számítástechnikai alkalmazásai (és ily módon ügyviteli folyamatai) felé bıvül és nem áll meg a távközlési illesztıegységeknél (átjárók a fent hivatkozott ábrán). Az EDI hálózati szolgáltatásokat használ a strukturált adatok átviteléhez, miután azonban az EDI által használt hálózati vagy adatátviteli funkciók implementációnként változhatnak, a Hálózati Szolgáltatások az EDI határain belül önálló rétegként vannak feltüntetve. Az EDI arról “szól”, hogyan történik az adatok struktúrákba rendezése és feldolgozása, és nem érinti az adatátvitel módját.

Szervezet 1.

Szervezet 2.

EDI

Ügyviteli Alkalmazás

ÁTJÁRÓ

BELSÕ HÁLÓZAT

ÁTJÁRÓ

ÁTJÁRÓ Átjáró Munkaállomás Szervezet 4.

Ügyviteli Alkalmazás

EDI Szervezet 3.

1. sz. ábra: EDI koncepciók

Ez az ábra azt is jelzi, hogy az EDI réteg összeköti a különbözı szervezeteket és lehetıvé teszi a szervezetek közötti EDI kapcsolatot. Az EDI határa eléri a szervezetek belsı folyamatait; az EDI definiálja az információ kicserélésének módját. Az ábrán valóban látható, hogy a folyamatok túllépnek a szervezeti határokon, és ezt az EDI teszi lehetıvé. Az ábra jelzi továbbá, hogy az egyes szervezetek számítástechnikai rendszerei 5


és alkalmazásai akár teljesen eltérıek is lehetnek, az EDI akkor is képes meghatározni a rendszerek közötti kommunikáció módját. Ami nem látható az ábrán az az, hogy új szervezetek is csatlakozhatnak az “EDI közösséghez” úgy, hogy ez a körülmény semmilyen módon nem érinti a meglévı szervezetek implementációit, feltéve, hogy a szervezetek egységes EDI szabványokkal dolgoznak. Ez az EDI egyik legjelentısebb erıssége. Miután egy folyamatra vagy kereskedelmi partnerre tervezett implementáció elkészült, ez az infrastruktúra további ráfordítások nélkül vagy minimális ráfordítással minden más kereskedelmi partnerrel is használható.

2.2.

Mi az EDI?

2.2.1. Az elektronikus adatcsere definíciója Strukturált adatok szabványos elektronikus cseréje kettı vagy több, elızetesen egyeztetett üzenettovábbító szabványt használó számítógéprendszer között. Az EDI elsısorban elektronikus ügyviteli és nem technológiai szabvány a számítógépes ügyviteli alkalmazások között. Mivel alkalmazások közötti kommunikációról van szó, az EDI-hez kommunikációs alkalmazások (pl.: üzenettovábbítás) és protokollok kapcsolódnak a megfelelı kommunikációs szinteken. Az EDI az esetek többségében, olyan kommunikációs protokollokon futó alkalmazás, ami ügyviteli rendszerek között teremt szabványos kapcsolatot. 2.2.2. Hol célszerő EDI-t alkalmazni? Az EDI-t általános értelemben ott érdemes használni az elektronikus dokumentumkezelésben, ahol több résztvevı között nagymennyiségő kritikus adat rendszeres, szabványos és automatikus továbbításáról illetve cseréjérıl van szó. A szabványosság fıleg akkor kap jelentıséget, ha a kritikus adatok cseréjében számos szereplı vesz részt, a rendszer szereplıi alkalomszerően változhatnak és más és más informatikai rendszerrel rendelkezhetnek. A biztonságos (kritikus) adatkezelés akkor jelentıs, ha szükség van az elektronikus dokumentumok továbbításainak, konverzióinak nyomon követésére, a dokumentumok különbözı megjelenési formáinak archiválására, titkosítására. Az EDI rendszer szabványos és biztonságos kialakítása lehetıvé teszi a rendszerben résztvevık számának egyszerő bıvítését. Ezért érdemes EDI-t használni ott, ahol nagyszámú és igény esetén bıvülı közösség akar adatbiztos ügyviteli kapcsolatot teremteni. Szintén általános sajátosság, hogy az EDI használata alapvetıen “off-line” környezetben javasolt, vagyis az alkalmazások a strukturált adatok halmazát továbbítják egymást között, így tárol és továbbít off-line és nem interaktív on-line környezetrıl van szó. A kritikus dokumentumok jelentıs része, ilyen környezetben keletkezik, illetve továbbítódik. (pl.: szerzıdések, nyilatkozatok, jelentések, statisztikák, adóbevallások, vámárú nyilatkozatok, cégkivonatok, nyilvántartási lapok stb.) Vannak sajátos on-line területek, mint például információ szolgáltatás, regisztrációs rendszerek, stb, ahol nem érdemes EDI-t alkalmazni. További általános sajátossága az EDI alkalmazást igénylı környezetnek a tömeges és automatikus dokumentumkezelés és feldolgozás. Az EDI automatizmusai, nagy kapacitású adat konverziós és adat be- és kiviteli tulajdonságai az EDI alkalmazásának egyik legfontosabb elınye. 6

A rendszeres adatcsere szintén jellemzı az EDI-t igénylı környezetekre. A rendszeres adatcseréhez általában rendszeres adatfeldolgozás is kapcsolódik legalább az egyik oldalon, ami automatizmusokat igényel az adatbevitelben a hatékony feldolgozás érdekében. 2.2.3. Az EDI rendszerek felépítése A 2. sz. ábrán két szervezetet (A és B) mutatunk be; mindkettı az EDI-t használja két ügyviteli alkalmazás integrálására. A nagy árnyékolt nyíl jelzi az adatok és információk alkalmazások közötti mozgását; a nyíl lefelé haladó szakasza jelzi az A szervezet számítógépének függıleges funkcióhalmazát, felfelé mutató része – a B szervezet számítógépének hasonló funkcióhalmazát. Az 1-tıl 6-ig megszámozott rétegek (a szervezet neve alatti függıleges keretekben) jelzik az adatcserében közremőködı funkciókat. Az ábra közepén látható és “hálózati szolgáltatók” névvel jelölt keretcsoport utal a zárt vagy nyilvános hálózat szerepére az adatcserében. A hálózati funkciók két felsı kerete opcionális, ezt nem minden esetben használják. Az alkalmazás-alkalmazás kommunikáció létrejöttének elengedhetetlen feltétele, hogy a két szervezet megállapodjon egymással arról, hogy milyen implementációkat és szabványokat használnak a folyamat egyes funkcionális rétegeiben. A kereteket összekötı nyilak jelzik, milyen jellegő megállapodásra van szükség az egyes funkcionális rétegeknél, és példákkal szemléltetik az egyes rétegekre vonatkozó szabványok jellegét; ezek csupán jelzések, amelyek nem tekinthetık az egyetlen lehetséges választási lehetıségnek. A következı szakaszban áttekintést adunk az EDI implementáció egyes funkcionális rétegeirıl; kitérünk arra is, mit jelent mindez a megállapodások és a szabványok kiválasztásánál. A Szervezet

Ügyviteli adatfeldolgozás opciói

B Szervezet

Ügyviteli adatok definíciói

6. ÜGYVITELI ALKALMAZÁS

6. ÜGYVITELI ALKALMAZÁS

EDI üzenetek EDI szintaxis

5. EDI INTERFÉSZ

5. EDI INTERFÉSZ

Integritás Bizalmasság

4. BIZTONSÁG

4. BIZTONSÁG Hitelesség Megtagadás-mentesség

3. ÜZENETÁTVITEL 2. VONALMEGHAJTÓ 1. FIZIKAI CSATLAKOZÁS

X.435 X.400 TEDIS

Üzenetkapcsolt postafiók

X.25

PROTOKOLL KONVERZIÓ

DIGITÁLIS

ÁTVITELI szolgáltatások

ANALÓG

OFTP VÉDETT SDLC ASZINKR. ISDN SEBESSÉG

3. ÜZENETÁTVITEL 2. VONALMEGHAJTÓ 1. FIZIKAI CSATLAKOZÁS

HÁLÓZATI SZOLGÁLATOK

2. sz. ábra: EDI logikai modell

Tágan fogalmazva, az 1., 2. és 3. réteg az adatok számítógépek közötti átvitelére vonatkozik (távközlés), a 4., 5. és 6. réteg érinti az adatok tartalmára, szerkezetére és feldolgozására vonatkozó megállapodásokat. Az EDI implementációhoz a hat funkcionális réteg mindegyikénél szükség van a szabványokra vonatkozó valamilyen megállapodásra, nagyon gyakran azonban csak az 5. funkcionális rétegre vonatkozó szabványokat és megállapodásokat nevezik EDI szabványoknak. 7


2.2.3.1. Ügyviteli alkalmazás A két szervezetnek vagy intézménynek ügyviteli szinten meg kell állapodnia egymással az adatfeldolgozás opcióiról és az engedélyezett funkciókról. A megállapodásnak vonatkoznia kell a támogatott információáramlásra: mindegyik üzleti jellegő felszólítás elvezet- egy mővelet megerısítéséhez, lehetséges-e változtatás az eredeti felszólításban, vagy a folyamat csak a törlést és a megismételt benyújtást támogatja-e, stb.? Az ügyviteli folyamatról szóló megállapodásra semmilyen szabvány nem vonatkozik, a szabványokat azonban ennek ellenére beépítik az adatcsere-megállapodásokba. A támogatandó ügyviteli funkciók szintje befolyással lesz az egységes EDI üzenetek kiválasztására és az üzenetekben engedélyezhetı adatfeldolgozási funkciókódokra. Amennyiben egy szervezet csatlakozik az EDI felhasználók valamelyik már létezı közösségéhez és a közösség adatcsere-szerzıdése már él, az új tagoknak már csak korlátozott választási lehetıségei lehetnek abban, mit kell támogatniuk. Az EDI kapcsolatokban, olyan megállapodásra is szükség van, ami az adatcserébe bevont minden egyes adatmezı felhasználói leírását adja. Ennek a megállapodásnak az adatszerkezet – a mezı hossza és a tizedes helyek száma stb. – mellett ki kell terjednie az adatok értelmezésére, (pl.: alkatrészszámok, gépjármővezetıi jogosítványok számai, társadalombiztosítási számok, egy gépjármővezetıi jogosítványon feltüntetett szabálysértések, a gépjármő kategóriája). Az információ fent hivatkozott részeit kódolni kell valamilyen egyeztetett módon, amely nem feltétlenül egyezik az információ megjelenésével a már létezı felhasználói adatbázisokban. A megállapodás másik fontos része a numerikus értékek értelmezésének módja, pl.: tételek száma, súly (kg vagy tonna), vagy dátumok formátuma. Az UN/EDIFACT Trade Data Element Dictionary már számos adatelem kódját tartalmazza, nem lehet azonban elızetesen meghatározni az összes szükséges adat kódját, ezenkívül új kódokra is szükség lehet. 2.2.3.2. EDI interfész Az EDI interfész szintjén a szervezeteknek két dologban kell megállapodniuk egymással. El kell dönteniük, milyen EDI-szintaxis szabványt alkalmaznak, és melyik EDI üzenettovábbító szabványt használják. A szintaxis-szabvány kiválasztásánál abból indulunk ki, hogy a felhasználók többsége a UN/EDIFACT szabványt használja. Az üzenet szabványok (United Nations Standard Messages, UNSM) közül azokat az üzeneteket kell kiválasztani, amelyek a leginkább megfelelnek az adott ügyviteli környezet igényeinek. Meg kell állapodni arról is, hogy az üzenet melyik részét (subsetjét) fogják használni. A subset-ek pontos leírását üzenetmegvalósítási kézikönyvekben (Message Implementation Guidline) kell rögzíteni és ezek a partner egyezmény részét kell hogy képezzék. Amennyiben nincs alkalmas UNSM, új üzenetet kell definiálni. Az üzenet subset-ek kialakításáról és felhasználásuk módjáról, az üzenetek szerkezetérıl és fejlesztésérıl, valamint általában az üzenetek felhasználásáról lásd a 3. fejezetet – “UN/EDIFACT”. Az EDI interfész réteg a kimenı adatokat az egyeztetett UN/EDIFACT üzenet- és szintaxis-szerkezetbe fordítja és elıkészíti az adatok továbbítását, illetve elvégzi az UN/EDIFACT adatszerkezetben érkezı adatok konverzióját, azaz létrehozza azt a belsı (inhouse) adatállományt és rekordformátumot, amelynek a feldolgozását az ügyviteli alkalmazás végzi. 2.2.3.3. Biztonság Az adatcserében résztvevı partnereknek a biztonság különbözı vonatkozásairól kell megállapodniuk egymással: az elsı és legfontosabb – milyen szintő biztonságot igényel az adatátvitel. Nem feledkezhetünk meg arról, hogy a különbözı szervezetek közötti 8

EDI kommunikáció egyik elınye, hogy az EDI eredendıen biztonságosabb az on-line feldolgozásoknál, amely lehetıvé teszi, hogy más szervezetek számítógépei és termináljai közvetlenül elérjék a házon belül használt alkalmazásokat. Az EDI üzenetek a szervezet saját számítógépére érkeznek, és csak az üzenet adattartalma kerül át az ügyviteli alkalmazásra, ahol megtörténik az adatfeldolgozás. Egyeztetni kell az üzenet funkcióját, és csak azoknak az üzeneteknek a feldolgozására kerülhet sor, amelyek megfelelnek az egyeztetett szerkezetnek. Egyelıre nem ismert olyan módszer, amely lehetıvé tenné a hozzáférést az üzenetformátumban nem meghatározott adatokhoz vagy funkciókhoz. On-line rendszerben a hasonló biztonság megvalósításához lényegesen nagyobb körültekintéssel kell eljárni és többet kell tenni annak érdekében, hogy megvédjük a rendszer egyes részeit és az adatstruktúrát az illetéktelen hozzáféréstıl. Ezek az intézkedések jelentıs mértékben növelik a költségeket, az implementációs idıt és a szükséges számítógép-teljesítményt. Ez az egyik oka annak, hogy a meglévı EDI felhasználók jelentıs része a használt (EDI és üzenettovábbító) programok, illetve a szolgáltatók (VAN) eredendı biztonsági rendszerén kívül semmilyen egyéb biztonsági eszközt nem használ. Az EDI rendszerekben az egyéb biztonsági eszközök rendeltetése a két számítógép között úton levı üzenetek védelme. A mindenkori igények függvényében fel lehet építeni különbözı biztonságot nyújtó adatbiztonsági funkciókat. Léteznek különbözı védelmi megoldások, amelyek többek között szavatolják azt, hogy: • ne változtassák meg az úton levı adatokat – az adatok integritása • az üzenet egy engedélyezett partnertıl érkezzen – hitelesítés • a partner, aki továbbította az adatokat, a késıbbiekben nem tagadhatja le az adatok feladását – a letagadhatatlanság • semmilyen külsı személy nem nyerhet betekintést az adatokba – bizalmasság • az adatok nem érkezhetnek az eredetitıl eltérı sorrendben, és a rendszer kiszőri a hiányzó illetve felesleges tételeket –sorrendiség. A felsorolt biztonsági szintek mindegyikének megvalósításához szükség van az egyes üzenetek számítógépes feldolgozására, bizonyos ügyviteli feladatok ellátására, a biztonsági eljárások és eszközök szervezetek közötti egyeztetésére. Az alkalmazott mechanizmusok mindegyikéhez szükség van valamilyen titkos kulcsra – vagy a digitális aláírások elıállításához, vagy az adatok teljes kódolásához. A biztonság elérhetı szintjei közül a legköltségesebb az adatok bizalmas kezelése, ezért ezt csak abban az esetben kell alkalmazni, ha ez feltétlenül szükséges. Ebben az összefüggésben a “költséges” igény nemcsak a pénzre utal, hanem arra is, hogy ez esetben igényesebb elıkészítı munkára, azaz a kockázatok elemzésére és kezelésére van szükség. A biztonság bármely szintjének kiválasztása és megvalósítása esetén az érdekelt feleknek meg kell állapodniuk egymással az alkalmazott szabványokról és implementációkról. A mechanizmusok és az implementációs opciók részletesebb értelmezését lásd az 5. fejezetben – “Az adatbiztonság kezelése”. 2.2.3.4. Az 1. 2. és 3. távközlési rétegek Az EDI logikai modell 1. 2. és 3. rétegének (2. sz. ábra) az egyedüli funkciója a lefordított és biztosított EDI üzenetek eljuttatása az egyik számítógéprıl a másikra. Az átviteli mechanizmusok elkülönülnek az üzenetekre és az azok tartalmára vonatkozó eljárásoktól. Az EDI rendszerekben minden esetben távközlési eszközöket alkalmaznak az EDI formátumok továbbítására, az átvitelnek azonban különbözı megoldásai léteznek, ezért a feleknek meg kell állapodniuk egymással az alkalmas megoldás kiválasztásáról. 9


Az EDI rendszerek összeköttetésére távközlési vonalakat és hozzáadott értékő szolgáltatókat lehet alkalmazni. A szolgáltatók igénybevétele lehetıvé teszi a távközlési szabványok rugalmasabb kiválasztását, hiszen nincs szükség a két szervezet közötti közvetlen megállapodásra. Ez különösen fontos akkor, amikor az adatcserében kettınél több szervezet vesz részt, hiszen elıfordulhat, hogy az egyik szervezet választása nem felel meg a többinek. A szolgáltatók formátum konverzióra is képesek illetve biztosítják az EDI rendszer résztvevıinek kívánalmak szerinti csatlakoztatását. Az alábbi alfejezetekben az egyes kommunikációs rétegeket tekintjük át. Üzenetátvitel Az üzenetátviteli réteg az áthidaló pont az EDI szabványokban definiált rétegek és a modell távközlési rétegei között. E rétegnek az a funkciója, hogy megfelelı helyre címezze az EDI üzeneteket és gondoskodjék arról, hogy mindegyik üzenet elérje a megfelelı címzettet. Az üzenettovábbító rendszerek tárol és továbbít alapon, postafiókokon keresztül továbbítják az üzeneteket. A postafiókoknak címük van, ami alapján az üzeneteket meg lehet címezni. A rendszernek üzenettovábbító és tároló központjai vannak, amiken keresztül a feladó postafiókjától a címzett postafiókjáig az üzenetek kézbesítıdnek. Az érkezı üzenetek a postafiókokban addig tárolódnak, amíg azokat a címzett meg nem kapja. Az EDI-nél többféle eltérı üzenetátviteli protokollt alkalmaznak: • saját protokollok • közösségi protokollok • OSI protokollok A saját protokollokat az értéknövelt szolgáltatású hálózatokat mőködtetı szolgáltatók fejlesztették ki a saját EDI postafiók szolgáltatásaikban történı alkalmazásra. A közösségi szabványokat bizonyos EDI felhasználói csoportok hozzák létre. A legelterjedtebb, a de facto szabványnak minısülı ODETTE File Transfer Protocol (OFTP), amelyet az autógyártók felhasználói közössége hozott létre. Az E-mail rendszerekben használt OSI protokollokat nemzetközi szabványügyi testületek fejlesztették ki, általánosan elterjedt megnevezésük X.400 protokollok. Az X.400 a leggyakoribb levelezı protokoll az EDI alkalmazásoknál és a kormányzati rendszereknél is ez az elıírt szabvány a hivatalos dokumentumok elektronikus továbbításával kapcsolatban. Ezért az X.400 levelezı rendszer ismertetésére részletesebben kitérünk. Az X.400-as rendszer felépítését az alábbi ábra vázolja:

3.sz. ábra: X.400-as üzenetkezelõ rendszer (MHS) Az X.400-as rendszerekben a levelezı szoftverek (UA-k, RUA,-ak), a kijelölt MS-hez (Message Storehoz /mailbox/postaláda), illetve MTA-hoz (Message Transfer System) csatlakoznak. Az elküldött üzenetek kézbesítése az üzenettovábbító rendszer - az MTA segítségével történik, az MTA egyébként az üzenetkezelı rendszer (MHS - Message Handling System) része, és a megoldás kulcsszereplıje.

10

Az MHS több együttmőködı funkcionális egységet tartalmaz. Az üzenettovábbító központok (MTA) és az üzenettároló központok (MS) együttmőködésével valósul meg a tárol és továbbít alapú üzenetátvitel. Az üzenettároló központok (MS) tárolják az üzeneteket és az MTA-k végzik az üzenet továbbítással kapcsolatos teendıket. A felhasználói szoftverek (UA - User Agent) segítik a felhasználót az üzenetek elérésében, a küldemények szerkesztésében, elindításában. Az elérési egységek (AUs - Access Units) biztosítják a kapcsolatot a különbözı típusú kommunikációs rendszerek és szolgáltatások felé (pl.: fax, telex, stb). A felhasználói ügynökök a P2-es protokoll (peer to peer Interpersonal Messaging Protocol) segítségével tartják a kapcsolatot, ami az üzenet szerkezetét és a tartalmát definiálja. A P7-es protokoll (Message Store access protocol ) teremti meg a távoli ügynök és az üzenet központok (MSs) közötti kapcsolatot, hogy képes legyen a kliens az üzenetközpontok szolgáltatásainak igénybevételére. Az X.400-as szemlélet szerint az üzeneteknek borítékuk és tartalmuk van. A boríték, az MTS számára használható címzési információt tárolja, a tartalom pedig az üzenetet tartalmazza. Az MTS nem módosítja és nem vizsgálja az üzenetek tartalmát, csak elvégzi a szükséges tranzakciókat és az esetleg szükséges konverziókat. A PRMD (Private Message Domain) olyan speciális MTA és MS, ami alá több MTA tartozik és az MTA-k egymással csak a PRMD-n keresztül kommunikálnak. Az alárendelt MTA a PRMD-n keresztül tartják az ADMD-vel a kapcsolatot. MTA

ADMD

RUA-k

PRMD

MTA

RUA-k

MTA

RUA-k

PRMD

MTA

MTA

RUA-k

MTA

MTA

RUA-k

4.sz. ábra: Az X.400-as rendszer elemeinek kapcsolata A PRMD-k mivel több MTA-t is kiszolgálnak és a külvilággal is tartják a kapcsolatot nagyobb kiépítettségő gépeken futnak. A routing táblázatok átfogóbb kezelési lehetıségeket és nagyobb routing kapacitásokat biztosítanak. Az ADMD (Administrativ Message Domain) olyan speciális MTA és MS, ami alá több PRMD és MTA tartozik. A közvetlenül az ADMD alatt levı MTA-k általában nincsenek PRMD hálózatban. Az alárendelt PRMD-k és közvetlen MTA-k egymással, csak az ADMD keresztül kommunikálnak. Az ADMD jelentıs kiterjedéső X.400-as levelezı rendszerek központjaként kerül kialakításra. A nagyteljesítményő üzenettovábbítás és tárolás jelentıs processzor és tároló kapacitásokat igényel az ADMD géptıl. A nagyteljesítményő és sokrétő üzenetkezelés parallel feldolgozásokat igényel (UNIX környezet).

11


Telefon hálózat Internet

FAX GW Internet GW

FAX Exchange GW

MTA

Exchange rendszer

X.400 RUA-k

NOTES GW

Notes rendszer

5.sz. ábra: X.400 Gateway-ek X.400-as levelezı rendszerei a nyilvános ADMD-ken keresztül tartják a kapcsolatot. A nyilvános ADMD egymással, vagy globális szolgáltatón keresztül regisztrálva vannak, ami a levél címzések kölcsönös felismerését biztosítja. Az X.400 levelezı rendszerek más levelezı rendszerekkel is kapcsolatba hozhatók. Ilyenek például az Internet, MS Mail, MS Exchange, Lotus Notes, Groupwise, stb. levelezı rendszerek. A levélformátumok és címek konverzióját az X.400 és e levelezı rendszerek között úgynevezett Gateway-ek biztosítják. A gateway-ek általában különbözık az illeszteni kívánt rendszereknek megfelelıen. A legfontosabb ilyen Gateway az SMTP/POP Gateway, ami az Internet levelezést illeszti az X.400-as rendszerhez. Ez teszi lehetıvé, hogy az X.400-as rendszerbıl Internet címekre üzenetet küldhessünk, illetve az Internetrıl üzeneteket fogadhassunk. Hasonlóan, megfelelı gateway-ek segítségével Exchange és Notes levelezı rendszerek és kapcsolatba hozhatók az X.400-as levelezı rendszerrel.

Vonalmeghajtó A vonalmeghajtó protokoll meghatározza, milyen módon továbbítják a nyers adatokat egy kommunikációs vonalon, és milyen módon vezérlik, illetve ellenırzik a kapcsolatokat. A protokoll meghatározza az egyes karakterek vagy karaktercsoportok átvitelének módját, valamint azt, hogyan jelzik a fogadó félnek a karakterek egyes összefüggı csoportjainak elejét és végét. A protokoll rendelkezik továbbá arról is, hogyan történjen az adatátvitel során elrontott adatok kiszőrése és korrigálása. Ahhoz, hogy egy adatátvitel megvalósuljon, egy kapcsolat mindkét végén ugyanazt a protokollt kell alkalmazni. Számos közhasználatban levı protokoll létezik és ismert, ezek egy részét eredetileg egyes számítógépgyártó cégek fejlesztették ki, mára azonban alkalmazásuk annyira elterjedt, hogy de facto szabványokká váltak; a protokollok egy másik részét szabványügyi testületek hozták létre. Az EDI hálózatokban ajánlott legelterjedtebb protokollok a következık: •

aszinkron (elterjedt jelölése “async”), amely egy rendkívül egyszerő, a szükséges hardver csekély költsége miatt a személyi számítógépekrıl létrehozott feltárcsázásos csatlakozásoknál széles körben használt protokoll;

•

a szinkron protokollok különbözı formái, például az általában a bérelt vonalakon használt HDLC, SDLC vagy BSC;

•

X.25, egy alapvetıen a (zárt és nyilvános) csomagkapcsolt hálózatokban, de a bérelt vonalakon is használt ISO szabvány protokoll.

Fizikai csatlakozás Fizikai csatlakozás alatt a távközlésben használatos vonalakat értjük. A vonalak típusa számos lehet: telefon, bérelt, satellit, gsm, stb. A vonalak egyik legjellemzıbb tulajdonsága az átviteli szélességük, illetve sebességük. A vonalakra jellemzı még az adatátvitel alapvetı módja, az analóg illetve digitális átvitel, ami a vonalakat kezelı központok jellegétıl függ.

12

Saját vonali hálózat kialakításakor a feleknek egyeztetniük kell a vonalalak jellegét és a vonali meghajtók protokolljait. Hozzáadott értékő szolgáltató (VAN) alkalmazása esetén a felek szabadon választhatnak a vonali is vonalmeghajtói kialakítások tekintetében. Napjainkban sokszor az Internet szolgáltatásaival váltják ki a közvetlen vagy szolgáltatón keresztül létesítendı csatlakozásokat. Miközben az Internet feltétlen elınye a széleskörő hozzáférés lehetısége és az alacsony költség, körültekintıen kell gondoskodni a kapcsolódó számítástechnikai környezetek megfelelı védelmérıl (például a hozzáféréseket szabályozó “tőzfal”-ról) és a továbbított üzenetek védelmérıl (például a kódolás alkalmazásával – további részleteket lásd a 6. fejezetben – “Adatbiztonsági rendszerek”).

2.2.4. EDI szabványok Az EDI definíciója szabványok alkalmazására utal; nyilvánvaló, hogy a számítástechnikai alkalmazások közötti összes adatcserének ezeket a szabványokat kell alkalmaznia, ellenkezı esetben az adatcsere egyszerően nem jöhet létre. Az EDI vonatkozásában ez azt jelenti, hogy az adattovábbításoknál minden esetben nemzetközi, országos vagy ágazati keretek között egyeztetett szabványokat kell alkalmazni az EDI adatok fordításához. Négyféle, egymástól jól elkülönülı EDI szabványt különböztetünk meg: • szintaxis • üzenetek • adatszótár • kódok Az EDI szintaxis definiálja az adatátvitelhez alkalmazott karakterkészletet és meghatározza az adatmezık formátumának és csoportokká való szervezésének módját. A szintaxis ezen kívül meghatározza, hogyan kell elkülöníteni egymástól az adatmezıket, illetve hogyan lehet felismerni az egyes adatcsoportok elejét és végét. A szintaxis leginkább egy nyelv nyelvtani szabályaihoz hasonlítható; meghatározza, hogyan kell egymás mellé rakni a szavakat és kifejezéseket, nem rendelkezik azonban arról, hogyan használhatjuk fel a szavakat a szavak értelmének közvetítésére. Az EDI üzenet meghatározza, hogyan csoportosítsuk az adatmezıket úgy, hogy ezeket együtt eljuttassunk egy ügyviteli funkciót fogadó fél gépére. Egyazon adatszótár és szintaxis felhasználásával különbözı üzeneteket lehet összeállítani, amelyek alkalmasak különbözı ügyviteli funkciók továbbítására. Az adatszótár meghatározza az üzenetekben felhasznált adatmezık értelmét. Az üzenetekben felhasználható kódok definíciója része az adatszótárnak, ezek a kódok azonban annyira fontosak az EDI rendszerében, hogy önálló meghatározásuk is indokolt. A kódok segítségével konkrét értelmet kölcsönözhetünk az adatok egy bizonyos tételének; például egy tétel lehet egy dátum, a fogadó félnek azonban tudnia kell, hogyan formattálják a dátumot (nn/hh/éé vagy éééé/hh/nn), illetve milyen dátumról van szó (valaminek a kezdete, vége vagy valami elérhetıségének az idıpontja). Az adott adattétel értelmezéséhez szükséges ilyen jellegő minısítések hordozói a kódok. Az üzenetek felhasználásának módjáról és az EDI partnerek közötti együttmőködés sajátosságairól a felek egy kifejezetten erre a célra rendszeresített dokumentumban rendelkeznek; ez az Adatcsere-szerzıdés. Ez a dokumentum az EDI partnerség feltételeinek kiterjesztése; amikor a felek megállapodnak egymással az EDI használatáról, ebben a szerzıdésben rögzítik a kapcsolat jogi és mőszaki kereteit. A legelterjedtebb nemzetközi EDI szabvány az UN/EDIFACT; ez a Nemzetközi Szabványügyi Szervezet (ISO) egyetlen EDI szabványa, amely vonatkozik a szintaxisra és az üzenetekre; a szabvány részletes leírását lásd a 4. fejezetben – “UN/EDIFACT”. Az adatszótár szabványa az ISO 7372. Az új kezdeményezések többsége a UN/EDIFACT szabványt használja, ezért a jelen Ajánlás következı részében ezzel a szabvánnyal foglalkozunk; nem szabad azonban megfeledkezni arról sem, hogy az Egyesült Államokban általánosan elterjedt az ANSI X12 szabvány.

13


Noha az új kezdeményezéseknél általában a UN/EDIFACT szabványt alkalmazzák, napjainkban is elterjedt és használt üzenetek jelentıs része a régebbi United Nations Guidelines for Trade Data Interchange (UNTDI) szintaxis felhasználásával készült. Ezek közül a legjelentısebbek a TRADACOMS üzenetek, amelyeket annak idején az Article Numbering Association vezetett be a kiskereskedelmi forgalomban. Ma is létezik a UN/EDIFACT szintaxisnak megfelelı kompatibilis üzenetek rendszere, bizonyos szervezetek azonban még nem álltak át az új üzenetekre. Léteznek más üzenet- és szintaxisszabványok, többek között az UNTDI. Meg kell jegyezni, hogy mindig az adott közösség szempontjából legalkalmasabb szabványt kell kiválasztani és alkalmazni, tekintettel azonban a UN/EDIFACT használatára vonatkozó nemzetközi ajánlásokra, valamint figyelembe véve, hogy még az olyan nagy közösségekben is, amilyen például az ANSI X12 szabványok alkalmazásának nagy hagyományaival rendelkezı USA-beli EDI közösség, egyre erıteljesebben törekednek a UN/EDIFACT kompatibilitásra, egyre nyomósabb érvek szólnak a UN/EDIFACT kiválasztása és alkalmazása mellett.

14

3.

AZ UN/EDIFACT SZABVÁNY

Az UN/EDIFACT, a nemzetközi EDI szabvány megalkotására és bevezetésére tett határozott erıfeszítések eredménye. A világ különbözı térségei és a különbözı iparágak helyi EDI szabványokat alkalmaztak, illetve alkalmaznak. A kereskedelem azonban egyre inkább túllép az iparági és nemzeti határokon. Mindez a más szabványok használóit fokozatosan az egységes EDI nyelv az UN/EDIFACT használatára kényszeríti. Az UN/EDIFACT jelentıs és fontos lépés az egységes nyelvő EDI adatcsere megvalósításában. Az UN/EDIFACT több mint 175 üzleti bizonylat, dokumentum elektronikus leírását tartalmazza. Ezek a dokumentumok a különbözı üzleti tranzakciók széles körét ölelik át, a számláktól a pénzügyi fizetési megbízásokig, a munkavállalói biztosítás múltbeli káreseményeit ismertetı őrlaptól a veszélyes áruk bejelentéséig. Amennyiben alapos üzleti megfontolások miatt nincs szükség valamilyen más EDI szabvány alkalmazására, az egyetlen alkalmazandó szabvány az UN/EDIFACT.

3.1.

Történelmi háttér

1986-ban az ENSZ Európai Gazdasági Bizottsága (UN/ECE) és az Amerikai Nemzeti Szabványügyi Intézet (ANSI) X12 United Nations Joint EDI Group (UN/JEDI) néven felállított egy közös kutatócsoportot. Ezt a csoportot bízták meg az EDI új globális szabványának elkészítésével. A csoport tevékenységének eredményeként 1987-ben létrejött a United Nations Electronic Data for Administration, Commerce and Transport, amelynek rendkívül szerencsés rövidítése a UN/EDIFACT. 1987. szeptemberében a szabványt ISO 9735 szabványként elfogadta a Nemzetközi Szabványügyi Szervezet. A következı évben az (akkori) Európai Gazdasági Közösség az Európai Szabadkereskedelmi Társulás (EFTA) közremőködésével létrehozta a Trade Electronic Interchange Systems (TEDIS) szervezetet, amelynek célja általában az EDI alkalmazásának elısegítése a kereskedelmi kapcsolatokban, valamint az új UN/EDIFACT szabvány elterjesztése.

3.2.

A UN/EDIFACT szervezet struktúrája

A 6. sz. ábrán bemutatjuk a UN/EDIFACT szabvány nemzetközi elterjesztésének segítésével megbízott szervezet struktúráját. A szervezet a világ minden országban elfogadja a szabvány elterjesztéséhez nyújtott segítséget, noha nyilvánvaló, hogy a fejlett ipari országok képviselı országok járulnak hozzá a legtevékenyebben a szabvány globális bevezetéséhez. Ezt a munkát az egy-egy régióért felelıs referensek (raportırök) végzik. A raportır a kormánya által megbízott vagy kinevezett személy, akinek feladata saját joghatósága földrajzi térségében a UN/EDIFACT fejlesztési tevékenység kezdeményezése és összehangolása.

15


R ENSZ Közgyőlés

A P Gazdasági és Szociális Tanács

Regionális Gazdasági Bizottság

Afrikai EDIFACT Tanács Ázsiai EDIFACT Tanács

O R

UN/ECE

T

Ausztrália/Új-Zéland EDIFACT Tanács Közép- és Kelet-Európai EDIFACT Tanács

İ Kereskedelmi Szakbizottság

R Ö

WP.4

GE.1

K

Pánamerikai EDIFACT Tanács Nyugat-Európai EDIFACT Tanács

6.sz. ábra: ENSZ EDIFACT struktúra. (A WP.4 a 4. sz. Munka-csoport jele; a GE.1 az 1. sz. szakértıi csoport jele)

Mindegyik Raportır munkáját egy regionális Tanács segíti. Az Egyesült Királyság vonatkozásában illetékes testület a Nyugat-Európai EDIFACT Tanács, más néven WE/EB. Struktúráját a 5. sz. ábrán ismertetjük. A Tanács a Comite Europeen de Tormalisation (CEN), az Európai Szabványügyi Bizottság társult testülete.

3.3.

Nyugat-Európai EDIFACT Tanács

A WE/EB szervezeti keretei között mőködı három szakértıi csoport tesz jelentést a Technikai Koordinációs Szakbizottságnak: • • •

Támogató Csoportok Különleges Szakmai Csoportok Üzenetfejlesztési Csoportok (MDG)

A Támogató Csoportok felelısek a tájékoztatásért, a kódokért, az eljárásokért és a dokumentációért, valamint szakmai értékelésért. A Különleges Szakmai Csoportok felelısek az információ modellezéséért, az interaktív EDI feljövıben levı területéért, a biztonságért és a felhasználói implementációs irányelvekért. A jelen dokumentum szempontjából legnagyobb érdeklıdésre számot tartó csoport az MDG.

16

CEN

A T an ács eln ö ke : a R ap o rtı r T itk ársá g

M e n e d zs m e n t Iro d a

T e c h n ik a i K o o rd in ác ió s S za kb izo tts á g ( T C C)

T á m o g a tó c s o p o rto k

Ü ze n e tfe jle s zté s i C s o p o rto k

K ü lö n le g e s s za k m a i C s o p o rto k

7. sz. ábra: A Nyugat-Európai EDIFACT Tanács struktúrája

3.4.

Üzenetfejlesztési csoportok

Ahogyan errıl a nevük is tanúskodik, ezek a csoportok felelısek az új EDI üzenetek fejlesztéséért és a meglevı üzenetek módosításáért és felülvizsgálatáért. A csoportok igénybe veszik az összes tagállam közremőködését. Az egyes területeken végzett fejlesztési tevékenységek mellett az MDG felelıs a párhuzamos tevékenységek kiszőréséért. Ez az MDG, a Támogató Csoportok és a Különleges Szakmai Csoportok közös feladata és felelıssége. Az egyes csoportok tevékenységének területét a 8. sz. ábrán ismertetjük. MDG MD1 MD2 MD3 MD4 MD5 MD6 MD7 MD8 MD9 MD10 MD11 MD12 MD13

Tevékenységi területek Kereskedelem Közlekedés Vám és közvetett adók Pénzügy Építıipar Statisztika Biztosítás Utazás, idegenforgalom és szabadidı Egészségügy Társadalombiztosítás Jog és könyvvitel Közbeszerzés Hálózatkezelés 8. sz. ábra: MDG tevékenységi területek

Miután egyre több iparág és terület érdeklıdik az EDI iránt, különleges üzleti igényeik kielégítésére elkerülhetetlen további MDG felállítása.

17


3.5.

UN/EDIFACT építõkockák

A UN/EDIFACT üzenetek egy hierarchikus struktúra szerint épülnek fel a legkisebb összetevıktıl egészen egy kereskedelmi partnerrel megvalósuló adatcsere egységéig. Ezek az összetevık a legnagyobbtól a legkisebbig a következık: • adatcserék • funkcionális csoportok • üzenetek (vagy tranzakciók) • szegmensek • adatelemek. A UN/EDIFACT egy kitöltendı nyomtatványként is leírható: • Egyszerő adatelem: megfelelıje egy nyomtatvány egy kitöltendı kockája • Összetett adatelem: megfelelıje összefüggı kitöltendı kockák sorozata • Szegmens: megfelelıje egy nyomtatvány egy szakasza • Üzenet: megfelelıje egy teljes nyomtatvány • Funkcionális csoport: megfelelıje meghatározott számú nyomtatvány • Adatcsere: megfelelıje egy boríték kitöltött nyomtatványa vagy nyomtatványai. A borítékon fel van tüntetve a feladó címe, így a címzett láthatja, kitıl érkezett a boríték. Van ezenkívül egy postai bélyegzınek megfelelı jel, amely jelzi, mikor „adták fel” a borítékot. A UN/EDIFACT szintaxisa meghatározza egy üzenet összetevıi közötti kapcsolatot: : komponens adatelemeinek elválasztója + adatelem elválasztó ' szegmens záróelem A UN/EDIFACT egy katalógus sort használ a fent hivatkozott komponensek hivatalos definícióinak tárolására. A komponensek áttekintése elıtt érdemes szólni néhány szót ezekrıl a katalógusokról. 3.5.1. UN/EDIFACT katalógusok A UN/ECE nagy mennyiségben jelentet meg szabványokat, irányelveket és katalógusokat. Ezek együttes neve United Nations Trade Data Interchange Directory (UNTDID). Ezt az elızetesen egyeztetett eljárásoknak megfelelıen idırıl idıre kiegészítik vagy módosítják. Tartalma a következı: • • • • • • • •

18

UN/EDIFACT Application Level Syntax Rules (alkalmazói szint szintaxis szabályai) (ISO 9735) UN/EDIFACT Message Design Guidelines (üzenettervezési irányelvek) UN/EDIFACT Syntax Implementation Guidelines (szintaxis implementációs irányelvek) (SIG) UN/EDIFACT Data Element Dictionary (adatelem katalógus) (EDED), a United Nations Trade Data Elements Directory egyik alállománya (ISO 7372) UN/EDIFACT Code Lists (kódjegyzékek) (EDCL) UN/EDIFACT Composite Data Element Directory (összetett adatelem katalógus) (EDCD) UN/EDIFACT Segment Directory (szegmens katalógus) (EDSD) UN/EDIFACT United Nations Standard Messages (ENSZ egységes üzenetek) (UNSM) Directory (EDMD)

•

UNiform Rules of Conduct for the Interchange of Trade Data by Teletransmission (kereskedelmi adatok távátviteli cseréjének egységes szabályai) (UNCID).

3.5.2. Egy UN/EDIFACT üzenet bemutatása A 9. sz. ábrán bemutatunk egy egyszerő UN/EDIFACT üzenetet (tulajdonképpen egy adatcsere egyik különálló üzenetét), ez esetben egy PARTIN üzenetet, amely lehetıvé teszi, hogy a kereskedelmi partnerek kicseréljék egymással a helyre vonatkozó információkat és a kapcsolódó adminisztratív és operációs részleteket. UNB+UNOA:2+SENDER+RECEIVER+941224:2359+12345++PARTIN++++1’ UNH+0+PARTIN:D:93A:UN’ BGM++1+2’ DTM+7+199412242359+202’ FII+BK+12345678:UNIVERSAL EXPORT PLC+:::010203:::BANKEXPORT+MOSKVA’ RFF+VAT+123456789’ DTM+7+19950101’ NAD+MS+++ UNIVERSAL EXPORT PLC+PO BOX 007:WHITEHALL+LONDON+WC1 0AA’ CTA+AG+JAMES BOND’ COM+01811112222:TE’ UNS+D’ NAD+AG+++UNIVERSAL EXPORT (RUSSIA)+PO BOX 57+MOSKVA++SU’ DTM+7+19950101+102’ CTA+AG+IOSEF DZUGASHVILI’ COM+12345-GO:TX’ UNT+15+1’ UNZ+1+12345’ 9. sz. ábra: UN/EDIFACT üzenet minta

3.5.3. Adatcserék Az adatcserék olyan üzenetek vagy funkcionális csoportok összességei, amelyeket együttesen egyazon kereskedelmi partnernek szánnak. Az adatcsere a kereskedelmi partnerrel lebonyolított csere egy egysége, amely tartalmazza az értéknövelı szolgáltatású hálózatok által az üzenetek feladótól címzetthez való eljuttatásához használt címzési adatokat. Mindegyik adatcserét – a funkcionális csoport vagy üzenet két alacsonyabb hierarchikus szintjéhez hasonlóan – meghatározott kiszolgáló szegmensek határolják, amelyek jelzik az adatcsere elejét és végét. 3.5.4. Funkcionális csoportok A funkcionális csoportok hasonló jellegő üzenetek logikai összességei; ezek együttesen az üzleti dokumentumok csomagját alkotják. Mindegyik funkcionális csoportot – az üzenetekhez hasonlóan – meghatározott kiszolgáló szegmensek határolják, amelyek jelzik a funkcionális csoport elejét és végét. Minden funkcionális csoportot egyazon jelzı azonosít, amely utal a funkcionális csoportot alkotó üzenetekre. Megjegyzés: A funkcionális csoportok használata nem ajánlott! Elképzelhetı, hogy valamikor ezeket törlik a szabványból. A funkcionális csoportok nagyrészt bizonyos múltbeli okok miatt vannak jelen; a UN/EDIFACT elıdje, az ANSI X12 szabvány az észak-amerikai üzleti szokásoknak megfelelıen széles körben használja a funkcionális csoportokat. Az Észak-Amerikán kívül meghonosodott üzleti gyakorlat azonban általában nem használja a funkcionális csoportokat.

19


3.5.5. Üzenetek (vagy tranzakciók) Az üzenetek az együttesen egy üzleti dokumentumot alkotó szegmensek logikai összessége. Mindegyik üzenetet különálló kiszolgáló szegmensek határolják, amelyek jelzik az üzenet elejét és végét. A szegmensek a következı részben találhatóak. Mindegyik üzenet azonosítására egy önálló, hat karakterbıl álló jelzı szolgál. Ott, ahol ez lehetséges, ez a jelzı az üzleti dokumentum angol nyelvő neve; például az INVOIC az Invoice (számla) üzenet neve. Másutt a név nem ennyire egyértelmően utal az üzenetre – például, az IFTSTA az International Multimodal Status Report (nemzetközi multimodális helyzetjelentés) üzenet! Mindegyik üzenet leírása megtalálható a UN/EDIFACT United Nations Standard Message (UNSM) Directory-ban (EDMD). Ebben a katalógusban minden egyes tételnek van a tétel egyértelmő azonosítására alkalmas neve és kódja. A 10. sz. ábrán bemutatunk néhány példát. A katalógus egyes tételei az üzenetek mindegyikének teljes leírására utalnak, amelyek jelzik az üzeneten belül jelen levı (kötelezı vagy feltételes) szegmensek sorrendjét és állapotát. A leírások mindegyikénél egy egységes jelölést alkalmaznak az üzenet leírására. BAPLIE CONDPV CONITT CONQVA CREADV CUSCAR CUSREP DEBADV DELJIT IFCSUM IFTMBC IFTMBP IFTMIN IFTSTA INVOIC INVRPT ORDERS PARTIN PAYDUC PAYORD QUOTES REQOTE SUPCOT

Bayplan/Stowage Plan Occupied And Empty Locations Message (tároló helyek tervének foglalt és üres helyei üzenet) Direct Payment Valuation Message (közvetlen fizetés értékelése) Invitation To Tender Message (ajánlati felhívás) Quantity Valuation Message (mennyiségi értékelés) Credit Advance Message (jóváírási értesítés) Customs Cargo Report Message (vámhatósági rakomány-bejelentés) Customs Conveyance Report Message (vámátruházási jelentés) Debit Advice Message (terhelési értesítés) Just In Time Message Forwarding and Consolidation Summary Message (szállítmányozási és konszolidációs összesítı) Booking Confirmation Message (helyfoglalás visszaigazolása) Provisional Booking Message (elızetes helyfoglalás) Instruction Message (utasítás) International Multimodal Status Report Message (nemzetközi multimodális helyzetjelentés) Invoice Message (számla) Inventory Report Message (készletfelmérés) Purchase Order Message (vételi megbízás) Party Information Message (információ az üzletfélrıl) Payroll Deductions Advice Message (értesítés a bércsökkentı tételekrıl) Payment Order Message (fizetési megbízás) Quote Message (árajánlat) Request For Quote Message (árajánlat kérése) Superannuation Contributions Advice Message (Nyugdíjjárulék befizetési értesítés)

10. sz. ábra: UN/EDIFACT Message Directory (üzenetkatalógus) tételeinek mintája

3.5.6. Szegmensek A szegmensek az egyszerő és összetett adatelemek logikai összessége. Kétféle szegmens létezik: • kiszolgáló szegmensek • felhasználóiadat-szegmensek. Mindegyik szegmense egy három karakterbıl álló szegmens jelzıvel kezdıdik és egy szegmens végjellel ér véget.

20

Az egyes szegmensek leírását lásd a UN/EDIFACT Segment Directory-ban (EDSD). Ebben a katalógusban minden egyes tételnek van a tétel egyértelmő azonosítására alkalmas neve és kódja. A 11. sz. ábrán bemutatunk néhány példát. Az EDSD jelzi a szegmensben jelen levı (kötelezı vagy feltételes) adatelemek sorrendjét és állapotát. A leírások mindegyikénél egységes jelölést alkalmaznak a szegmens összetevıinek leírására: Ref.

az adatelem azonosítására alkalmas egyedülálló ID, mint az EDED-ben és az EDCD-ben Repr. az adat jellege, hossza és állapota (M/C) Név az adatelem neve, mint az EDED-ben és az EDCD-ben Megjegyzések szabadon formattált szöveg.

Ref. Név Funkció: Megjegyzés Az adatelemek jegyzéke

Repr.

DTM DATE/TIME/PERIOD Funkció: Dátum és/vagy idıpont vagy idıszak meghatározása. C507 DÁTUM/IDİPONT/IDİSZAK 2005 Dátum/idıpont/idıszak minısítı 2380 Dátum/idıpont/idıszak 2379 Dátum/idıpont/idıszak formátum minısítı

M M an..3 C an..35 C an..3

FII FINANCIAL INSTITUTION INFORMATION (pénzintézmény adatai) Funkció: Egy számla és egy hozzátartozó pénzintézmény azonosítása 3035 ÜZLETFÉL MINİSÍTİ C078 SZÁMLA AZONOSÍTÁS 3194 Számlatulajdonos száma C an..17 3192 Számlatulajdonos neve 3192 Számlatulajdonos neve 6345 Valuta, kódolt C088 INTÉZMÉNY AZONOSÍTÓ 3433 Intézmény nevének azonosítója 1131 Kódjegyzék minısítı 3055 Kódjegyzékért felelıs hivatal, kódolt 3434 Intézmény fiókszáma 1131 Kódjegyzék-minısítı 3055 Kódjegyzékért felelıs hivatal, kódolt 3432 Intézmény neve 3436 Intézmény fiókjának helye 3207 ORSZÁG, KÓDOLT C an..3 MOA MONETARY AMOUNT (pénzösszeg) Funkció: Egy pénzösszeg meghatározása C516 PÉNZÖSSZEG 5025 pénzösszeg jellegének minısítıje 5004 Pénzösszeg 6345 Valuta, kódolt 6343 Valuta módosító 4405 Állapot, kódolt

M an..3 C C an..35 C an..3 C an..3 C C an..11 C an..3 C an..3 D an..17 C an..3 C an..3 C an..70 C an..70

M M an..3 C n..18 C an..3 C an..3 C an..3

11. sz. ábra: UN/EDIFACT Segment Directory tételek mintája

Elképzelhetı a szegmensek egy bizonyos logikai csoportosítása, egy SEGMENT GROUP. Egy szegmenscsoport többféle vonatkozásban hasonlít egy összetett adatelemhez. Például logikus a név- és címadatok hozzárendelése (ezek a „NAD” 21


szegmensben jelenhetnek meg) a telefon adatokkal (amelyek a „COM” szegmensben jelennek meg), esetleg a referencia információkkal (ezek helye a „REF” szegmens). 3.5.7. Kiszolgáló szegmensek A UN/EDIFACT definiálja a szegmensek egy különleges csoportját, amelyben minden szegmens jelöléséhez „Uxx” jelzıt használnak. Ezeket általában az üzenetek, funkcionális csoportok és adatcserék elejének és végének jelölésére használják. Ezeknek a szegmensek a kölcsönös összefüggéseit a 12. sz. ábrán szemléltetjük. Csere

Csere

Csere

UNA

UNB

UNG

’

Üzenet

Üzenet

UNH

’

Adatszegmens

ADAT SZEGMENS

JELZİ

+

EGYSZERŐ ADATELEM

KÓD

’

FUNKCIONÁLIS CSOPORT

+

csak UNZ

’

Üzenet

UNE

’

Adatszegmens

UNT

’

vagy ÜZENETEK

’

ÖSSZETETT ADATELEM

Érték

COMP

Érték

:

Érték

12. sz. ábra: Az adatcsere komponensek összefüggései.

UNA UNB UNG UNH UNS

UNT UNE UNZ

22

Service String Advice (kiszolgáló sztring) Interchange Header (adatcsere fejrésze) Ennek a szegmensnek az elrendezését lásd a 13. sz. ábrán. Functional Group Header (funkcionális csoport fejrésze) Message Header (üzenet fejrész) Section Control (szegmens vezérlés) Ezt használják egy üzenet különbözı szegmenseinek (részeinek), többek között az adatok elıtti szegmens, az adatok és az adatok utáni szegmens különválasztására. A 9. sz. ábrán bemutatunk egy üzenetet, amely használja a fent hivatkozott szegmensek egyikét. Message Trailer (üzenet záró része) Functional Group Trailer (funkcionális csoport záró része) Interchange Trailer (adatcsere záró része)

Szegmen UNB INTERCHANGE HEADER s: Funkció: Egy adatcsere kezdeményezése, azonosítása és meghatározása REF.

REPR.

S001

NÉV M

MEGJEGYZÉSEK

SZINTAXIS AZONOSÍTÓ

0001

a4

M

Szintaxis azonosító

a3 nagybető ellenırzı intézmény és a1 utasítás szint

0002

n1

M

Szintaxis verzió száma

Minden új verziónál a szám eggyel növekszik

S002

M

ADATCSERE FELADÓ

0004

an..35

M

Feladó azonosítója

Az Adatcsere Szerzıdés meghatározza kódját vagy nevét

0007

an..4

C

Partnerazonosító kód módosítója

A feladó azonosító kódjával használják

0008

an..14

S003

C

Cím az ellenirányú üzenetküldéshez

M

ADATCSERE CÍMZETT

M

Címzett azonosítója

0010

an..35

0007

an..4

C

Partnerazonosító kód módosító

A feladó azonosító kódjával használják

0014

an..14

C

Cím az üzenetküldéshez

Amennyiben használják, általában az egyenes irányú üzenetküldés alcíme

M

DÁTUM/IDİPONT VAGY ELİKÉSZÍTÉS

M

Dátum

S004

Az Adatcsere Szerzıdés meghatározza kódját vagy nevét

0017

n6

0019

n4

M

Idıpont

HHMMSS

0020

an..14

M

ADATCSERE VEZÉRLİ REFERENCIA

Feladó által rendelt megkülönböztetı referencia

S005

YYMMDD

C

CÍMZETT REFERENCIÁJA/KULCSSZAVA

0022

an..14

M

Címzett referenciája/kulcsszava

Lásd az adatcsere szerzıdést

0025

an2

C

Címzett referenciája/minısítıje

Amennyiben az adatcsere szerzıdés meghatározza

0026

an..14

C

ALKALMAZÁS REFERENCIA

Esetenként az üzenet azonosítója, amennyiben az adatcsere csak egyfajta üzenetet tartalmaz

0029

a1

C

ADATFELDOLGOZÁS PRIORITÁS KÓDJA Akkor használják, ha meg van határozva az adatcsere szerzıdésben

0031

n1

C

NYUGTÁZÁS KÓDJA

=1, amennyiben a feladó kéri a nyugtázást

0032

an..35

C

KOMMUNIKÁCIÓS SZERZİDÉS ID

ID Amennyiben használják, az adatcserét vezérlı kommunikációs szerzıdés jellegének azonosítására szolgál

0035

n1

C

TESZTINDIKÁTOR

=1, amennyiben az adatcsere egy teszt

13. sz. ábra: UN/EDIFACT UNB szegmens

A UN/EDIFACT alapértelmezésként használja a korábban hivatkozott elhatároló karaktereket. Szükség esetén azonban ezek a „UNA” Service String Advice szegmens használatával módosíthatók. Nem szükséges, hogy a felhasználók rutinszerően tartalmazzák az ilyen karakterek valamelyikét. Jelenlétüket célszerő kerülni, amennyiben ez egyáltalán lehetséges. Amennyiben ez nem lehetséges, a kereskedelmi partnereket értesíteni kell az ilyen karakterek jelenlétérıl. Az EDI fordítóprogramok többsége képes kezelni ezeket a karaktereket, de egy értelmezı felülíró karakter képzıdik az ilyen karakterek „szabad” karakterrel való jelölésének kezeléséhez (az alapértelmezés szerint „?”). Az elhatároló karakter felhasználói adatokban való minden egyes elıfordulása alkalmával két karakter képzıdik. Ha valóban nem lehet elkerülni az elhatároló karakterek elıfordulását a felhasználói adatokban, és ennek következményeként a felhasználói adatokban megjelennek különbözı elválasztó karakterek, fontolóra kell venni a „UNA” szegmens használatát. Ez a szegmens megelızi a „UNB” szegmenset abban az adatcserében, amelyhez a „UNA” szegmens tartozik (lásd a 14. sz. ábrát). UNA:*,? #UNB*UNOA:1*SENDER*RECEIVER*19941224:2359*12345**PARTIN****1# 14. sz. ábra: UNA szegmens használata

23


A fenti példa jelzi az alábbi elválasztók felülvizsgálatát és cseréjét: • komponens adatelem – alapértelmezés „:” változatlan • adatelem – alapértelmezés „+” helyett „*” • decimális számábrázolás – alapértelmezés „.” helyett „,” • elválasztó karakter – alapértelmezés „?” változatlan • szegmens lezáró karakter – alapértelmezés „,” helyett „#”. 3.5.8. Adatelemek Háromféle adatelem ismert: • egyszerő • összetevı • összetett Az egyszerő adatelemek az adatok különálló tételei, például egy dátum; mindegyik adatelem jelölésére egy egyedülálló numerikus négykarakteres szám szolgál. Az összetevı adatelemek csoportokba rendezett egyszerő adatelemek. A csoport már összetett adatelemként ismert. Például egy cím alkothat egy összetett adatelemet úgy, hogy a cím minden egyes címsora összetevı adatelem. Az összes adatelemet két UN/EDIFACT katalógus definiálja: az egyik a UN/EDIFACT Data Element Directory (EDE), a másik a UN/EDIFACT Composite Data Element Directory (EDCD). Miután az EDI alapfilozófiája a manuális intervenció nélküli adatfeldolgozás, fontos az adatok minden egyes részletének egyértelmő értelmezése. Ennek egyik lehetséges módja, hogy minden egyes kódnak egy és csak egy értelmezése legyen. Ezen oknál fogva került sor a kódjegyzékek használatának bevezetésére. Ezeknek az egyértelmő értékeknek a megjelenítéséhez páratlan számokkal jelölt adatelemeket használnak. Ezek az elemek a páros számokkal jelölt adatelemekben tárolt felhasználói adatok minısítıi. Ezek a minısítık vagy a UN/EDIFACT Board által fenntartott listákról (a fent említett UN/EDIFACT Code Lists (EDCL)) közvetlenül kiválasztott, vagy az EDCL által megjelölt független kódjegyzékekbıl kiválasztott értékek. Ez utóbbi módszer feltétlen elınye, hogy a UN/EDIFACT Board mentesül attól, hogy világszerte saját maga gondozza mindegyik kód minden listáját!! A páratlan számokkal jelölt adatelemek egy része azt is jelzi, hogyan kell értelmezni a felhasználói adatokat. Egy EDCL tétel mintája a 14. sz. ábrán látható. 2379

Dátum/idı/idıszak formátum minısítı

Desc:

Egy dátum, egy dátum vagy idıpont vagy egy idıszak megjelenítésének specifikációja

Repr:

an..3

Kód

Formátum

2

DDMMYY

Naptári dátum: D = nap; M = hónap; Y = év

3

MMDDYY


101

YYMMDD


102

CCYYMMDD

Naptári dátum: C = évszázad; Y = év; M = hónap; D = nap

103

YYWWDD

Naptári hét napja: Y = év; W = hét; D = nap

105

YYDDD

Naptári nap: Y = év; D = nap

14. sz. ábra: A UN/EDIFACT kódlisták (EDCL) tétele (kivonat)

A páros számokkal jelölt adatelemeket használják azoknak a felhasználói adatoknak a tárolására, amelyeknek az értelmét az adatok minısítıi határozzák meg. Például a

24

„2380” adatelem definíciója értelmében „dátum/idı/idıszak” az EDED rendszerében. Milyen dátum/idı/idıszak? Ezt határozza meg egy „2005” minısítı adatelem („Dátum/idı/idıszak minısítı”), amelynek lehetséges értéke „7”, amelynek definíciója az EDCL rendszerében „Tényleges dátum/idı”. Ez még mindig nem teljesen egyértelmő, hiszen a UN/EDIFACT számos különbözı dátum/idıpont/idıszak formátumot engedélyez. A formátumot egy másik minısítı adatelem, a „2379” („Dátum/idı/idıszak formátum minısítı”) határozza meg. Ez már lehetıvé teszi, hogy az ügyviteli alkalmazás végre egyértelmően értelmezze a dátumot. A „2379” minısítı adatelemben a lehetséges érték „202”, az ezzel jelölt dátum/idı formátum „CCYYMMDDHHMM”. A 9. sz. ábrán látható az ilyen adatelemek néhány példája, többek között 4. Sorban („ DTM+7+199412242359+202’ ”). Ez a rendszer bonyolultnak tőnik, lehetıvé teszi azonban, hogy a felhasználó nagyfokú szabadságot élvezzen egy bizonyos cél megvalósításához szükséges adatok leírásánál – ez nem egy szabvány, amely mesterséges korlátozásokkal befolyásolja egy vállalkozás mőködését. Egyszerő adatelemek Az EDED lista tartalmazza az egyszerő adatelemek hivatalos definícióját, az alábbi paraméterekkel: • jel • név • leírás • adattípus • hossz. A definíció tartalmazhat a felhasználásra vonatkozó utalásokat. A jelölés négy numerikus karakterbıl áll. A 16. sz. ábrán bemutatunk néhány példát. Az adattípus és a hossz – együttesen ismertebb néven az ábrázolás – leírását egy egységes ábrázolás teszi lehetıvé: a alfabetikus karakterek n numerikus karakterek an alfanumerikus karakterek a3 3 alfabetikus karakter, rögzített hossz n3 3 numerikus karakter, rögzített hossz an3 3 alfanumerikus karakter, rögzített hossz a..3 3 alfabetikus karakter, változó hossz n..3 3 numerikus karakter, változó hossz an..3 3 alfanumerikus karakter, változó hossz A fentiekhez hasonlóan létezik az EDCD és az EDSD tételeiben való alkalmazás során használt adatelem-leírás formattálásának egységes módja. Az „ÖSSZETETT ADATELEM” megnevezése minden esetben nagybetőkkel jelenik meg. Egy „ADATELEM” leírása ugyancsak nagybetőkkel jelenik meg, kivéve azokat az eseteket, amikor létezik egy „összetevı adatelem”; ez utóbbi esetben az adatelem megnevezése kisbetőkkel jelenik meg.

25


jel Desc: Repr: Megjegyzés: 1000 Desc: Repr: 1001 Desc: Repr: Megjegyzés: 3207 Desc: szabványt. Repr: Megjegyzés: 3222 Desc: Repr:

név leírás ábrázolás a felhasználás módjára való utalás Dokumentum/üzenet neve Egyszerő azonosító, amely meghatározza egy dokumentum/üzenet funkcióját. an..35 Dokumentum/üzenet neve, kódolt Dokumentum/üzenet azonosítója, kóddal. an..3 Lásd TDED 5.1. Amennyiben belföldi kódra van szükség, ajánlott a 1131 és a 3055. Ország, kódolt Egy ország vagy egy másik földrajzi entitás nevének azonosítója, lásd az ISO 3166 an..3 Használja az ISO 3166 két alfa ország kódot. Vonatkozó hely/helyszín Az elsı hozzátartozó hely/helyszín név szerinti azonosítása. an.70 16.sz. ábra: UN/EDIFACT Adatelem-katalógus (EDED) tételek mintája

Összetett adatelemek Az összetett adatelemek abban térnek el az egyszerő adatelemektıl, hogy ezek az adatok tulajdonképpen egy „címkét” képeznek egy logikai csoport azonosítására. Ez EDCD-ben létezik ezeknek az adatoknak a hivatalos definíciója az alábbi jellemzıkkel: • jel • név • leírás • az összetevı adatelemek jegyzéke mindegyik adat ábrázolásával, beleértve az állapotot. A jel egy „C” karakterbıl és azt követı három numerikus karakterbıl áll. A 17. sz. ábrán bemutatunk néhány példát. Az összetett adatokban jelenlevı adatelemek állapota (Kötelezı vagy Feltételes) azért szükséges, hogy összekapcsolják az összetevıket, hiszen például egy dátum értelmének pontos jelölése nélkül, önmagában értelmezhetetlen.

26

jel név Desc: leírás adatelemek jegyzéke C002 DOKUMENTUM/ÜZENET NÉV Desc: A dokumentum/üzenet egy típusának kód vagy név szerinti azonosítása. A kód elınyösebb. 1001 Dokumentum/üzenet neve, kódolt C an..3 1131 Kódjegyzék minısítı C an..3 3055 Kódjegyzékért felelıs intézmény, kódolt C an..3 1000 Dokumentum/üzenet neve C an..35 C080 MÁSIK FÉL NEVE Desc: Egy tranzakcióban résztvevı másik fél név szerinti azonosítása, egy-öt sorban. A másik fél neve formattálható. 3036 Másik fél neve M an..35 3036 Másik fél neve C an..35 3036 Másik fél neve C an..35 3036 Másik fél neve C an..35 3036 Másik fél neve C an..35 3045 Másik fél nevének formátuma, kódolva C an..3 C507 DÁTUM/IDİ/IDİSZAK Desc: A meghatározott dátum/idı/idıszak típusa szempontjából releváns dátum és/vagy idıpont, vagy idıszak 2005 Dátum/idı/idıszak azonosító M an..3 2380 Dátum/idı/idıszak C an..35 2379 Dátum/idı/idıszak formátum minısítı C an..3 17. sz. ábra: UN/EDIFACT Composite Data Element Directory tételek mintája

A csak a kiszolgáló szegmensekben használt összetett adatelemek alosztálya (lásd a „Kiszolgáló szegmensek”) nem „C”, hanem „S” karakterrel kezdıdik. S004 Desc: 0017 0019

ELİKÉSZÍTÉS DÁTUMA/IDEJE Jelezni az elıkészítés dátuma és idejét Dátum M n6 Idı M n4 18. sz. ábra: UN/EDIFACT Composite Data Element Directory (EDCD) tétel mintája.

Ezt az összetett adatelemet használják egy kiszolgáló szegmensben. Összeillesztés Az egyszerő és az összetett adatelemek fogalmainak összeillesztésével és a fent hivatkozott példa felhasználásával elkészíthetjük az alábbi táblázatot. Egy dátumnak csak akkor van értelme, ha van egy jelzés arra vonatkozóik, mire utal a dátum és hogyan történt annak formattálása. Az elkészült összetett adatelem három egyszerő adatelemet tartalmaz: Jel C507 2005 2380 2379

Név DÁTUM/IDİ/IDİSZAK Dátum/idı/idıszak minısítı Dátum/idı/idıszak Dátum/idı/idıszak formátum minısítı

Érték nincs érték 7 199412242359 202

Ez egy üzenet részletében az alábbi módon jelenik meg: ...+7:199412242359:202+... aminek egyértelmő értelmezése, hogy a tényleges dátum és idı 1994. karácsonyeste éjfél elıtt egy perccel.

27


A „C507” összetett adatelem nem tartalmazhat értéket; ez csupán egy címke a fenti egyszerő adatelemek csoportosításához. 3.5.9. Az üzenet állapota Miután a UN/EDIFACT Tanácsa felismerte, hogy az üzenetek nem jelenhetnek meg semmilyen olyan formában, amely megfelel az összes felhasználó összes igényének, ezért elfogadott egy eljárást az üzenetek különbözı szinteken történı kibocsátására; az egyes szintek az üzenet stabilitásába vetett hitet tükrözik. Három ilyen szint létezik, ezekre a továbbiakban mint az üzenet állapotaira hivatkozunk: 0. állapot

Dokumentum tervezete Egy üzenet ezen a szinten még kialakulatlan, változik, kipróbálás céljára azonban már hozzáférhetı. Azokat a felhasználókat, akik problémákat vagy hiányosságokat fedeznek fel, felszólítják, hogy országuk kapcsolatrendszerén keresztül értesítsék a kibocsátó MDG-t. A kibocsátó megvizsgálja az összes összetevı esetleges módosításának lehetıségét.

1. állapot

Ajánlás tervezete Egy üzenet ezen a szinten már túl van a 0. állapoton és vélhetıen megfelel több felhasználó kereskedelmi igényeinek. Változtatásokra azonban továbbra is szükség van, noha nem valószínő, hogy ezek jellegüket tekintve radikálisak.

2. állapot

Ajánlás Egy üzenet ezen a szinten alkalmas a teljes körő kereskedelmi felhasználásra. Az üzenet legalább három éven keresztül változatlan marad. Az üzenetnek meg kell felelnie a felhasználók döntı többsége által támasztott kereskedelmi követelményeknek.

3.5.10. Üzenet alkatrészek (subset-ek) Miután a UN/EDIFACT igénybe veszi a lehetõ legtöbb érdekelt fél közremûködését és hozzájárulását, elkerülhetetlen, hogy egy adott üzenet az érintettek összes igénye alapján jöjjön létre. Ennek eredményeként egy üzenet többet tartalmaz annál, amire egy bizonyos félnek szüksége van. A nagy struktúrákat létrehozó különbözõ csoportok elhatározták, hogy kezelhetõ részekre bontják az így megalkotott üzeneteket. Így született a „részhalmaz” fogalma, amelyet a UN/EDIFACT az alábbiak szerint határozott meg: Egy iparágon vagy alkalmazáson belül használt egy bizonyos üzenetfajta kivonata. Ez a kivonat követi az adategységek elhagyásának szabályait, és a részhalmaz általában csak egy iparágon vagy alkalmazáson belül igényelt egységeket jelzi. Ennek a definíciónak a legfontosabb része az „egy iparágon vagy alkalmazáson belül”. Ezt használják országokra, vagy szélesebb földrajzi térségekre, valamint közösségekre vonatkozó részleges implementációk megfogalmazásához. Egy országban a kialakult üzleti gyakorlat és esetenként a törvényhozás engedélyezheti egy EDI üzeneten belül az információ megjelenítésének egy bizonyos „egységes” módját. Általában ezek az iparági és országcsoportok ellenırzik a részhalmazokat; ezek bocsátják ki a „saját” részhalmazaikra vonatkozó konkrét irányelveket. Íme az ilyen csoportok néhány példája:

28

UK EDIFACT Megállapodás a kereskedelmi üzenetekrıl Ez az ANA, a SITPRO és a Vám és Fogyasztási Adó Igazgatóság közös kezdeményezése, amely jelenlegi formájában meghatározza a különbözı UN/EDIFACT üzenetek egységes felhasználását. Az eddig kifejlesztett üzenetek a következık: INVOIC ORDERS TAXCON

Invoice Message (számlaüzenet) Purchase Order Message (vételi megbízás üzenet) Tax Control Message (adóellenırzés üzenet): ez egy nem szabványos üzenet, amelyet a Vám és Fogyasztási Adó Igazgatóság ajánlott az a forgalmi adó egyeztetéséhez az INVOIC üzenet felhasználása során.

EDIFICE

Az EDIFICE (EDI for companies with Interests in Computing and Electronics – EDI a számítástechnikában és elektronikában érdekelt vállalatok számára) meghatározta a fent hivatkozott INVOIC és ORDERS üzenetek konkrét felhasználási módjait; ezeket napjainkban Európa egész területén használják, de csak a tagok közötti kereskedelmi kapcsolatokban. Ez az alábbiakat tartalmazza: DESADV DELFOR DELJIT INVOIC INVRPT ORDCHG ORDERS ORDRSP PRICAT QUOTES REQOTE RESRPT

EANCOM

Dispatch Advice Message (feladási értesítés) Delivery Forecast Message (áruszállítási elırejelzés) Delivery Just-in-Time Message (Just in Time szállítás) Invoice Message (számla) Inventory Report Message (készletjelentés) Purchase Order Change Request Message (vételi megbízás módosításának kérése) Purchase Order Message (vételi megbízás) Purchase Order Response Message (vételi megbízás visszaigazolása) Price / Sales Catalogue Message (ár/eladási katalógus) Quote Message (árajánlat) Request for Quote Message (ajánlatkérés) Resale Report Message (viszonteladási jelentés) (még nem szabványos üzenet)

Az International (eredetileg European) Article Numbering Association (EAN) európai kezdeményezése egy egységes európai részhalmaz létrehozására. Az Egyesült Királyság kezdeményezése kompatibilis ezzel a kezdeményezéssel. Ez a megállapodás az alábbiakat tartalmazza DESADV GENRAL INVOIC ORDCHG ORDERS ORDRSP PARTIN PRICAT REMADV SLSFCT SLSRPT

Dispatch Advice Message (feladási értesítés) General Message (általános értesítés) Invoice Message (számla) Purchase Order Change Request Message (vételi mebízás módosításának kérése) Purchase Order Message (vételi megbízás) Purchase Order Response Message (vételi megbízás visszaigazolása) Party Information Massage (partner információ) Price / Sales Catalogue Message (ár/eladási katalógus) Remittance Advise Message (utalványozási értesítés) Sales Forecast Message (értékesítési elırejelzés) Sales Report Message (értékesítési jelentés)

3.5.11. Üzenet keretrendszerek Egy másik lehetséges megközelítés, ha megterveznek egy teljesen új üzenetkészletet, amelynek van egy közös szegmenskészlete, közösek az alkalmazási területek, majd ezt 29


a „vázlatot” kell kiterjeszteni a különbözı konkrét üzleti célokra. Ez a részhalmaz módszer fordítottja, hiszen utóbbi a nagy üzenetekbıl készíti el a kisebbet; ez a módszer a „törzsbıl” indul és onnan építkezik. Ezt a vázat „keretrendszernek” nevezzük, ezt a UN/EDIFACT az alábbiak szerint definiálja: egy funkcionális üzleti területre (vagy többfunkciós üzleti területre) vonatkozó összes csoport/szegmens sorrendben rendezett készletét magában foglaló és a szóban forgó területre definiált összes üzenetet alkalmazó minta. Pontosan ez történik többek között a nemzetközi szállítmányozás területén. A különbözı csoportok és társaságok együttesen határozták meg az elıforduló kereskedelmi ügyletekre vonatkozó minimum üzenetet, majd kiterjesztették ezt a különbözı üzleti tevékenységekre. Ennek alapján létrejöttek az IFTxxx mintát követı összefüggı üzenetek sorozata. Például: IFTMAN

Arrival Notice Message (érkezési értesítés)

IFTMBC

Booking Confirmation Message (helyfoglalás visszaigazolása)

IFTMBF

Firm Booking Message (végleges helyfoglalás)

IFTMBP

Provisional Booking Message (elızetes helyfoglalás)

IFTMCS

Instruction Contract Status Message (utasításszerzıdés állpota)

IFTMIN

Instruction Message (utasítás)

3.5.12. UN/EDIFACT kísérleti és egységes tartalomjegyzékek Érthetetlen módon létezik egy másik directory réteg, amely egy adott szinten tartalmazza az összes komponenst. Ezek két változatban jelennek meg: Draft (tervezet) és Standard (egységes). A directory mindkét fajtájának a formátuma azonos – „xyya”, ahol: X „D” – Draft, „S” – Standard Yy a kibocsátás éve A a tárgyi évben „A” karakterrel kezdıdı kibocsátás. 1993-ban az elsı Draft directory neve „D93A”, a másodiké „D93B”. Meg kell említeni, hogy ez az a terület, ahol súlyos zavarok fordulhatnak elı. A fent hivatkozott katalógusok mindegyike tartalmazza az összes egyéb katalógus (EDED, EDCD, EDSD és EDMD) összes definícióját, amelyek egy összefüggı készletet alkotnak. Fontos tudni, melyek ezek közül a használatban levı katalógusok (mikor veszi kezdetét valójában a UN/EDIFACT üzenetek felhasználása), hiszen elképzelhetı, hogy például egy adatelem értelmezése az egyik katalógusban nem azonos ugyanannak az adatelemnek az értelmezésével egy másik katalógusban. Ezért rendkívül lényeges, hogy minden érdekelt partner pontosan tudja, amelyek azok a katalógusok, amelyek egy adott idıpontban használatban vannak. Ennek hiánya jó esetben egy ellenséges légkör kialakulásával, rossz esetben konkrét üzleti veszteséggel járhat. Egy üzenet címzettjének az „S009 MESSAGE IDENTIFIER” (üzenet azonosító) adatelemmel jelzik, melyik katalógus van használatban.

30

3.5.13. Alternatív karakterkészletre vonatkozó rendelkezés Amikor elsı alkalommal hozták létre a UN/EDIFACT-ot, az egy üzeneten belül használható karaktereket az „A”-tól „Z”-ig terjedı nagybetős karakterekre, a „0” – „9” numerikus karakterekre és néhány speciális karakterre korlátozták. Ez mindaddig mőködött, amíg két kereskedelmi partner angol nyelven kereskedett egymással. A világon, de még az európai kontinensen is sok olyan nyelv létezik, amelyekben jelentıs mennyiségben használnak különleges betőket. Ezért többen szorgalmazták további alfabetikus karakterek használatának engedélyezését. Az ISO 9735 (1992-ben kibocsátott) szabvány 1. sz. módosítása a „UNB.S001.0001 Syntax Identifier” adatelemek vonatkozásában az alábbi kódokat definiálta (lásd a „UNB” szegmens elrendezését a 13.sz. ábrán): •

UNOA „A” – „Z” nagybetők, „0” – „9” numerikus karakterek és bizonyos különleges karakterek.

•

UNOB „A” – „Z” nagybetők, „0” – „9” numerikus karakterek és bizonyos különleges karakterek, bizonyos ki nem nyomtatható karakterek és néhány különleges karakter.

•

UNOC Latin ABC az alábbi nyelvek támogatásával: dán, holland, angol, finn, francia, német, izlandi, ír, olasz, norvég, portugál, spanyol és svéd. Lásd ISO 8859-1.

•

UNOD Latin ABC az alábbi nyelvek támogatásával: albán, cseh, angol, magyar, lengyel, román, szerb-horvát, szlovák és szlovén. Lásd ISO 8859-2.

•

UNOE Latin/cirill ABC az alábbi nyelvek támogatásával: bolgár, fehérorosz, angol, macedón, orosz, szerb-horvát és ukrán. Lásd ISO 8859-5.

•

UNOF Latin/görög ABC a görög nyelv támogatásával. Lásd ISO 8859-7.

3.5.14. Biztonsági szabványok a UN/EDIFACT-ban Az összes UN/EDIFACT felhasználó legnagyobb közös aggálya a biztonság. Ez az aggály nem azonos az adatátvitelnél jelentkezı aggodalmakkal – ez a terület nem tartozik a UN/EDIFACT szabvány hatálya alá; ez az üzenet és az adatcsere szintjén jelentkezı félelem. 1994-ig nem létezett semmilyen elfogadott módszer a UN/EDIFACT biztonsági problémáinak kezelésére. Mára azonban már léteznek a UN/EDIFACT szintjén (szemben az adatcsere szintjével) elfogadott biztonsági irányelvek. Ezek az irányelvek lehetıvé teszik az alábbiakkal kapcsolatos félelmek feloldását: • • • •

üzenet hitelesítése üzenet tartalmának integritása üzenet (feladás és átvétel) megtagadásának lehetetlenné tétele üzenet-sorrend.

Az EDI felhasználók egy részének egy másik súlyos aggálya a titoktartás. A biztonság egyéb vonatkozásinak részletes elemzését lásd az 5. Fejezetben – „Az adatbiztonság kezelése”. E tárggyal itt a továbbiakban nem foglalkozunk.

31


4.

EDI SZOFTVEREK

Az EDI szoftverek a 2.2.3 fejezetben ismertetett EDI rendszer felépítésben az EDI Interfész rétegen helyezkedik el. A szoftverek legjellemzıbb része az EDI konverter, ami az EDI üzenetek kétirányú fordítását végzi. Az EDI szoftverhez modulárisan kommunikációs szoftver modulok is kapcsolódnak, amik az üzenettovábbítási és távközlési funkciókat látják el (2-es, 3-as réteg). Az EDI szoftver kapcsolatát az ügyviteli alkalmazással, a konverziót, és a kommunikációt, EDI ütemezı szoftver modulok vezérelhetik az EDI szoftverben. Az EDI nagyrészt független az operációs rendszertıl. Az egyetlen megfontolásra érdemes mozzanat ez esetben az operációs rendszer által használt karakterkészlet-kódolás. Az UN/EDIFACT olyan karakterkészletet ír le, amely alapvetıen megegyezik az American National Standard Code for Information Interchange (ASCII) rendszerrel. Amennyiben az EDI szoftvert futtató számítógép egy másik kódolót használ, ezt valahol konvertálni kell. Erre többféle megoldás kínálkozik: • • •

a vonali protokoll-meghajtó funkcióinak részeként, amennyiben az EDI szoftvert a központi számítógépen installálják a központi számítógép és az átjáró gép között a házon belül adatállomány-átvitel részeként a hálózati szolgáltató postafiókjában. Bizonyos VAN szolgáltatók a szolgáltatás részeként ajánlják a karakter konverziót.

Az EDI szoftvereknek rengetek fajtája van, de ezek általában három kategóriába sorolhatók. Az egyik az EDI szerverek, gateway-ek kategóriája, ami ellátja az adott környezet EDI feladatait (szerver) és csatlakoztatja a környezet EDI üzeneteit az inhouse (házi) formátumhoz (gateway, átjáró). A második kategóriába az EDI szerverekhez kapcsolódó EDI kliensek, EDI munkaállomások, amelyek általában a nem integrált vagy nem számítógépes adatfeldolgozás környezetét csatlakoztatják az EDI világhoz. A harmadikba a WEB EDI szerver szolgáltatások, amelyek szintén ezt a környezetet kezelik, de a munkaállomás felület a WEB EDI szerveren kerül kialakításra.

4.1.

EDI átjárók (EDI gateway-ek, szerverek)

A szervezetek többsége átjáró (gateway) szoftvereknek nevezett EDI szoftvereket vásárol, amelyek ellátják az EDI üzenetkezelés és a távközlés minden funkcióját – ez az általunk vázolt modell 5., 3., 2. és 1. rétege. Bizonyos csomagok biztonsági funkciókat is kínálnak, ezek a funkciók azonban általában addicionális komponensek, és a helyi biztonsági igények kielégítéséhez szükség van az ilyen komponensek testreszabására. Az EDI (átjáró vagy szerver) szoftver kétféle módon installálható: • az ügyviteli alkalmazással együtt, ugyanazon a számítógépen (a felhasználói funkciók önálló készleteként) – integrált EDI szoftver • önálló gépen, általában személyi számítógépen (PC), amely csatlakozik az ügyviteli alkalmazás számítógépéhez. – front-end gép illesztés. Ezt a módszert mutatjuk be a 19. sz. ábrán.

32

Ügyviteli alkalmazás illesztõegysége

Ügyviteli alkalmazás

Folyamat vezérlõ, ellenõrzõ és naplózó EDIFACT fordító

Üzenetátvitel

“Tárolótovábbküldı” (postafiók)

Hálózati szolgáltató

Vonal protokoll kezelõ

Üzenetátvitel

EDIFACT fordító

Ügyviteli alkalmazás illesztõegysége

Folyamat vezérlõ, ellenõrzõ és naplózó

Vonal protokoll kezelõ

Adatcsere házon belüli adatállománya

Ügyviteli alkalmazás

=opcionális

19.sz. ábra: Az EDI fizikai implementációja

Az EDI fordításnál felhasznált adatok adatállományokban, file-okban kerülnek az EDI szoftverhez. Az átjáróhoz továbbított adatállományok tartalmazzák egy EDI üzenet összeállításához szükséges összes adatmezıt, ebben a szakaszban azonban az adatszerkezet nem igazodik semmilyen EDI szintaxishoz. Ezt az adatállományt általában “házi” (inhouse) fájlnak nevezik. Az EDI átjáróban a fordítóprogram feladata, hogy ebbıl az adatállományban létrehozzon egy EDI üzenetet. A fordítóprogramok többsége táblázatvezérelt és felismeri a házon belüli adatállomány formátumát és az EDI üzenet formátumát. A táblázatokat az EDI adminisztrátor feladatait ellátó személy állítja össze. Az érkezı EDI üzenetek fordított sorrendben mennek végig ezen a folyamaton, és az alkalmazáshoz továbbított (inhouse) fájl az érkezı EDI üzenet összes adatát olyan formában tartalmazza, amely lehetıvé teszi azok ügyviteli alkalmazásban történı feldolgozását. Az EDI átjáró programcsomagok többsége távközlési opciókkal rendelkezik, amelyek a pont-pont adatátvitelnél vagy a VAN postafiók szolgáltatásoknál egyaránt képesek kezelni az EDI üzenetek címzését és az átvitel útvonalainak megválasztását. Itt érdemes megjegyezni, hogy az EDI üzenetek konverziója nem csak inhouse file-ra, illetve inhouse file-ból történhet, hanem relációs adatbázis adatokra, illetve adatokból is. Az adatbázisra való konvertálás automatikus és relációs adatbevitelt biztosít a relációs feldolgozáshoz. Mindez rendkívüli mértékben meg tudja növelni az adatfeldolgozás hatékonyságát. A konfigurációs menedzsmentet, az üzenetkezelést, naplózást, a kereskedelmi partnerek nyilvántartását, adataik karbantartását, a nyomkövetést és hibakeresést az adatbázis kezelı végzi. Az RDBMS szervere képezi az EDI szerver kernel-jét és teszi azt teljes mértékben adatbázis-orientálttá. A naplózás és a lekérdezés több összetevıbıl áll úgy, mint üzenet naplózás, hiba jegyzék és session naplózás. Az EDI konverzió adatai közvetlenül az adatbázis kezelıi alkalmazások adatait jelenthetik és az adatbázis kezelıre esetleg épülı Data Warehousing rendszerek adatait is. (pl.: 33


Oracle) A szabványos dokumentum kezelés (EDI) adatainak és a relációs adatbázis kezelés adatainak egysége olyan adatstruktúrát alkot, ami eddig soha nem látott dokumentum kezelési ás feldolgozási lehetıséget jelent.

4.2.

EDI munkaállomások

Az EDI alkalmazására készülı számos szervezetnél az EDI funkciók ügyviteli alkalmazásokba való integrációja elsı lépésként túl bonyolult és kockázatos feladatnak tőnhet. Ebben a helyzetben egy PC számítógépre telepített önálló alkalmazás a követendı megoldás, amely lehetıvé teszi az üzenetek elıállításához szükséges adatok (akár manuális) beléptetését és az érkezı üzenetek megtekintését/kinyomtatását. A munkaállomások kezelhetnek például elektronikus formanyomtatványokat, Excel táblázatokat, ODBC-n vagy SQL-en keresztül adatbázisokat, Ezekre akkor lehet szükség, amikor a házi adatfeldolgozás manuális vagy számítógépesen nem integrált. A nem integrált eset, olyankor értendı, amikor az EDI fordításhoz szükséges adatok egy adott üzenet esetében nem egy inhouse file-ból kaphatók a helyi számítógépes rendszerbıl. A munkaállomások EDI átjáróvá illetve EDI szerverré bıvíthetık a késıbbiek során, ha kialakul az integrált számítógépes feldolgozás a házon belül. Ez a migráció több szakaszban is elvégezhetı; elképzelhetı egy olyan megoldás, amelynél elsı lépésként a könnyebben integrálható kimenı üzenetek implementációjára kerül sor.

4.3.

WEB EDI szoftverek

Az EDI szerverek WEB szerverrel is összeköthetık. Ilyenkor a munkaállomások felületei az EDI szerverre kerülnek és azok távolról böngészıvel érhetık el. A hálózat természetesen lehet Internet is, de a biztonságos kezelés érdekében ezt a megoldást inkább Intranet-es, illetve Extranet-es környezetben szokták alkalmazni.

34

5.

AZ ADATBIZTONSÁG KEZELÉSE

A kormányzati rendszerek adatbiztonsága egyre gyakorlatibb kérdéssé válik. Az EDI-t kritikus adatok elektronikus kezelésénél alkalmazzák, ezért az adatok adatbiztonsági követelményei fokozottak. A kormányzati rendszerek egészét tekintve, az adatbiztonsági technológiák egyre központibb kezelést igényelnek. Az ezzel kapcsolatos központi koordinációk és üzemeltetések ismertetése elıtt röviden bemutatjuk e technológiák fıbb ismérveit.

5.1.

Az adatbiztonság elemei

Hitelesség Papír alapú rendszerekben a feladó személyét általában a feladó aláírása, valamint a kapott dokumentum fizikai ismérvei, többek között a fejléc és a vízjel alapján lehet ellenırizni. Különbözı postaforgalmi technikákkal, például ajánlott postai küldeményekkel vagy személyi futárral a feladó gondoskodhat arról, hogy a dokumentumot valóban az arra jogosult személynek kézbesítsék. Ezeket a fizikai ismérveket egy elektronikus dokumentumnál leképezni nem lehet. A feladó azonban egy elektronikus aláírást generálhat és mellékelheti azt az elektronikus üzenethez; ez alkalmas a fentiekkel megegyezı funkciók ellátására. A digitális aláírás elıállításához az elektronikus üzenetbıl, adott algoritmus szerint zárszámot (egyedi összegzı számot) képezünk és a titkos (privát) kulccsal titkosítjuk. Ezt követıen a digitális aláírást vagy az EDI üzenettel együtt, vagy attól elkülönítve továbbítjuk a címzettnek. A digitális aláírást a címzett a nyilvános kulcs segítségével dekódolja és ı is elkészíti az üzenetre vonatkozó egyedi összegzı számot. Ha ez megegyezik a kapott és dekódolt zárszámmal, akkor az üzenet sértetlenül érkezett meg. Amennyiben az üzenetet és a privát kulccsal titkosított aláírást a címzett nyilvános (publikus) kulcsával titkosítjuk, csak a címzett tudja elolvasni a kapott üzenetet a saját privát kulcsával. Mindez jelenti az üzenet sértetlen integritását és a feladó hitelességét. A kódolás és a kulcsok alkalmazásához két módszer kapcsolódik: • •

szimmetrikus vagy egyedi kulcsrendszerek aszimmetrikus vagy nyilvános/egyedi kulcsrendszerek.

Szimmetrikus rendszerben mindkét fél ugyanazt a titkos kulcsot és ugyanazt az algoritmust használja. A szimmetrikus kódolás legáltalánosabb példája a Data Encryption Standard (DES). Aszimmetrikus rendszerben van egy nyilvános kulcs, amelyet sokan ismerhetnek, és a titkos kulcs, amelyet csak az illetékes feladó ismerhet. Ez a technika a feladó hitelesítésére is alkalmas. A nyilvános/egyedi kulcsrendszerekben alkalmazott legáltalánosabb kódolási algoritmus az RSA; ez a szerzık nevének kezdıbetőibıl álló rövidítés – Rivest Shamir és Adleman.

35


Az üzenet tartalmi integritása Papír alapú rendszerekben nem létezik “bombabiztos” módszer egy dokumentum fizikai integritásának maradéktalan ellenırzésére. Elektronikus üzenet esetében azonban egy zárszám vagy egy hash szám alkalmas lehet ennek a feladatnak az ellátására. A zárszámot a teljes EDI üzenet alapján határozzák meg egy megfelelı kriptográfiai algoritmus segítségével; ilyen például a Modification Detection Code. A zárszám ezt követıen vagy megjelenik az üzenetben, vagy külön megküldik a címzettnek. Az üzenet esetleges módosításának ellenırzéséhez el kell végezni a zárszám ismételt kalkulációját, majd a kapott és az eredeti értékek szembesítését. Az algoritmus ily módon elıállítja minden egyes EDI üzenet eltérı és ezért egyedülálló hash kódját vagy zárszámát. Ezt az EDI üzenettel együtt továbbítják a címzettnek, majd az üzenet átvételét követıen a kapott üzenet alapján ugyanezzel az algoritmussal elkészítenek egy új zárszámot. Amennyiben az új szám megegyezik az üzenettel együtt megküldött számmal, a címzett megnyugodhat: az üzenetet nem módosították a továbbítás során. Titkosság A tartalom titkosságának biztosítása érdekében az egész EDI üzenetet vagy a védendı információt rejtjelezni kell oly módon, hogy azt illetéktelen személy vagy alkalmazás ne érthesse. Az eljárás hasonlít a papírbizonylatok kódolására. Az adatok kódolása során általánossá vált az a gyakorlat, hogy digitális aláírással hitelesítik a felhasználó személyét, valamint egy zárszámmal gondoskodnak az üzenet tartalmának integritásáról. Ezeknek az intézkedéseknek az együttes alkalmazása szavatolja a nagyfokú biztonságot. Nem szabad azonban megfeledkezni arról, hogy a biztonság nagyban megterhelheti a számítástechnikai erıforrásokat és jelentısen növelheti a költségeket. Ezért a biztonság mértékének arányban kell lennie a kockázattal és a kockázat kezelésének költségével. Az eredet letagadhatatlansága Az eredet letagadhatatlansága megóvja az EDI üzenet címzettjét az üzenet kezdeményezésének letagadásától és annak következményeitıl. Papír alapú rendszerben a dokumentum fizikai megléte lehet a dokumentum eredetének bizonyítéka, noha esetenként nehéz kiszőrni egy hamisítványt. Az eredet bizonyítására az EDI üzenetnek tartalmaznia kell valamit, ami csak az üzenet engedélyezett kezdeményezıjétıl származhat. Ez lehet – az esetek többségében ez így is van – egy digitális aláírás, ha utóbbit egy aszimmetrikus kulcsrendszerben generálták, ahol csak az üzenet kezdeményezıje ismeri az adatvédelmi kódolás kulcsát. Az eredet letagadásának lehetetlenné tétele önmagában még nem biztosítja az EDI üzenet teljes védelmét. Elıfordul, hogy – véletlenül tévedés vagy szándékos megtévesztés okán – ugyanazt a védett EDI üzenetet másodszor is feladják a rendszerben. Az ilyen módszerekkel szembeni védekezés érdekében szükség van egy üzenet-sorrendezı és egy dátum/idı bélyegzı rendszerre. Az átvétel letagadhatatlansága Az átvétel letagadásának ellehetetlenítése védelmet nyújt az üzenet kezdeményezıjének arra az esetre, ha a címzett esetleg letagadná az üzenet átvételét. Papír alapú rendszerben ezt úgy oldják meg, hogy a címzett visszaküld egy bizonylatot, például egy átvételi elismervényt. Elektronikus rendszerben is hasonló eljárást alkalmaznak; a címzettnek átvételt igazoló üzenetet kell visszaküldenie az feladónak. Az 36

EDI üzenetnek tartalmaznia kell olyan információkat, amelyek csak az eredeti üzenetbıl származhatnak, valamint a címzett elektronikus aláírását; ez a bizonyítéka annak, hogy az arra illetékes személynek meg kellett kapnia az eredeti üzenetet. Az eredeti üzenetnél és az átvételét visszaigazoló üzenetnél gondoskodni kell a felhasználó személyének hitelesítésérıl és a tartalom integritásának ellenırzésérıl. Üzenetek sorrendisége Az EDI üzenetek sorrendbe rendezése védelmet nyújt a címzettnek az üzenetek elvesztésével vagy megtévesztı másolásával szemben. Egy üzenetet fel lehet adni másodszor eredeti formájában; egy ilyen üzenet a biztonsági ellenırzés, például a felhasználó hitelesítés vagy a tartalmi integritás ellenırzése során nem esik ki a biztonsági ellenırzés rostáján. A pénzügyi üzeneteknél ennek lehetséges következménye a kétszeri fizetés. EDI üzenet elvesztése vagy késedelmes átvétele a szállítási határidık be nem tartását, illetve az emiatt kivetett büntetı kamatok miatt költségnövekedést eredményezhet. Az üzenet elvesztésének, illetve ismételt megküldésének megakadályozását szolgálja az EDI üzeneten elhelyezett sorszám. A számot az üzenet tartalmi integritásának megırzése miatt védeni kell. Az EDI üzenet átvételét követıen ellenırzik az üzenet számát; az ellenırzés során ellenırzik az üzenet sorszámát és összehasonlítják azt az eggyel elıbbi üzenet sorszámával. Az ellenırzés során megállapított bármilyen eltérés üzenetvesztésre vagy üzenet ismételt feladására utal.

5.2.

Szimmetrikus és aszimmetrikus kulcs kezelési eljárások, elektronikus közjegyzés

Kulcs kezelési eljárások A titkosítási kulcsok kezelésének két fı irányzata alakult ki: a szimmetrikus és aszimmetrikus kulcs kezelési eljárás. A szimmetrikus kulcs kezelési eljárásokban mindegyik partner saját (kiosztott) titkosító kulccsal rendelkezik. Az aszimmetrikus eljárásokban a partnerek egy nyilvános és egy saját kulccsal rendelkeznek. A szimmetrikus rendszerek viszonylag könnyen kezelhetıek, ha a kereskedelmi partnerek szőkebb köre vesz részt a tranzakciókban. Amennyiben azonban a kereskedelmi partnerek közössége létszámát tekintve dinamikusan növekszik a titkos kulcs kezelése egyre nehezebbé válik. A titkos kulcsok kiosztása rendkívüli körültekintést igénylı feladat. A partnerek papíron is kicserélhetik egymással a kulcsokat, miután azonban a kulcsok egy része bonyolult és terjedelmes, ez a megoldás nem tőnik célszerőnek. A gyakorlatban mindez floppy lemezen vagy smart card-on történik. Az aszimmetrikus rendszerek alkalmazása során két kulcsot használnak: az egyik saját kulcs, amely soha sem hagyja el a feladó telephelyét, a másik nyilvános kulcs, amely mindenki számára ismert. Továbbra is fennáll azonban a nyilvános kulcs védelmének problémája. Amennyiben azt akarjuk, hogy a biztonság ne sérüljön, lényeges, hogy az üzenet címzettjének módja legyen meggyızıdnie arról, hogy az EDI üzenet hitelesítéséhez használt nyilvános kulcs valóban a kereskedelmi partner kulcsa, és nem valakié, aki kereskedelmi partnernek adja ki magát. Ezt a problémát úgy lehet áthidalni, ha az érdekeltek igénybe vesznek egy kulcs hitelesı szolgáltatást és bevonnak egy külsı megbízottat – egy állami közjegyzıt vagy egy hitelesítı hatóságot (CA). Itt érdemes

37


megjegyezni, hogy más technikák, például a kulcsok kölcsönös kicserélése is biztosíthat hasonló elınyöket. Hitelesítı hatóságok A hitelesítı hatóság egy harmadik személy, amelyet partnerek közössége megbíz azzal, hogy ellenırizze a kulcsok biztonságos és szakszerő allokációját. Szimmetrikus kulcsrendszerben, ahol mindkét partner ugyanazt a titkos kulcsot használja, a CA generálhatja a titkos kulcsot és megküldheti azt a partnereknek. Az aszimmetrikus rendszerben a hitelesítı hatóság generálhatja és küldheti a titkos kulcsot az engedélyezett feladónak, illetve a nyilvános kulcsot a közösség tagjainak.

5.3.

Aszimmetrikus kulcskezelési eljárás X.400, X.500 környezetben

X.400 alapú adatbiztonság Az X.400 szolgáltatásokra vonatkozó 1984. évi ajánlások kevés biztonsági rendelkezést tartalmaznak. Nagy nyomás nehezedett az X.400 hatóságokra annak érdekében, hogy változtassanak ezen a helyzeten. A biztonsági kérdések értékelése során kiemelten kezelték nem közvetlenül az üzenet, hanem a Message Transfer Service biztonsági eszközökkel való kiegészítését. Ennek eredményeként az 1988. évi ajánlások már nyilvános és titkos kulcsokra alapozott és az üzenetátvitel rétegében mőködı technikákat tartalmaztak. Ezek a módszerek a felhasználói ügynök (UA, RUA) és az üzenetátviteli ügynök (MTA) között, illetve a felhasználói ügynökök között gondoskodnak a szükséges védelemrıl. Az X.500 névtár szolgáltatás lehetıvé teszi, hogy a nyilvános kulcsokat X.509 formában az X.500 névtár szolgáltatásba helyezzük, lehetıséget adva arra, hogy az X.400-as levelek titkosításánál és digitális aláírásánál a nyilvános kulcsterjesztés és kezelés egyszerővé váljon. A CA az X.500 és X.400 kapcsolatát a következı ábra mutatja be:

Üzenettovábbító rendszer X.400 MTA MS

X.500 Névtár Szolgáltatás

LDAP Directory elérés P7 MS elérés

nyilvános azonosítók feltöltése CA DDM nyilvános azonosítók lehívása

38

Privát kulcsok

RUA

20.sz. ábra: Az X.500 alapú adatbiztonsági rendszer elemei

A vázolt rendszer mőködése az alábbiakban foglalható össze: •

A CA hozza létre a privát kulcsokat és a nyilvános azonosítókat (X.509). A nyilvános azonosítók az X.500 névtárban kerülnek tárolásra. Az Directory Data Manager (DDM) biztosítja a nyilvános azonosítók megfelelı konvertálását és továbbítását a CA-ból az X.500 névtárba. A privát kulcsok kiosztása a felhasználók között a kijelölt hordozón történhet (pl.: floppy, smart card stb.)

•

Biztonsági X.400 kliens X.400 üzenettovábbító kliens, ami a normális X.400 funkciók kezelése mellett lehetıséget nyújt az üzenetek digitális aláírására és titkosítására is. Az X.400 kliens LDAP vagy DAP protokollon keresztül éri el az X.500 névtárat a nyilvános azonosítók tekintetében.

•

X.500 Névtár

X.500 szabvány szerinti névtár, ahol a közjegyzésben résztvevı valamennyi felhasználó nyilvános azonosítója kerül tárolásra. •

X.400 MTA és MS Az X.400 MTA-t az üzenetközvetítı ügynököt, az MS az üzenet tárolót jelenti.

Az X.400, X.500 rendszerek aszimmetrikus kulcskezelési és kódolási eljárásai kiterjedt rendszerek adatbiztonságát teszik megvalósíthatóvá. A levelezı kliensek kezelése egyszerő marad a kulcs kezeléssel kapcsolatos adminisztráció pedig központilag végezhetı. A kulcskezelést támogató CA biztonságos módon elkülöníthetı a rendszertıl, így a hitelesítési központ a rendszerben jól védhetı.

39


6.

A kormányzati EDI projektek során elvárt szabványok

A kormányzati rendszerek együttmőködése szabványokon alapul, ezért e szabványok betartatása rendkívül szükséges és sokszor központi beavatkozást igényel. A szabványok érvényesítése a fejlesztések során nem jelenti egyes termékkörök központi preferálását, mert mindegyik elvárt szabvány nyílt szabvány, több gyártó által is figyelembe vett nemzetközi szabvány.

6.1.

EDIFACT

Fıleg történeti okok miatt az EDI területén, az EDIFACT mellet más szabványok is léteznek, noha az EDIFACT dominanciája egyre nyilvánvalóbb. A magyar kormányzat az EU és az UN szabványosítási törekvéseivel összhangban az EDIFACT-ot választotta kizárólagos szabványnak, a kormányzati rendszerek tekintetében. Az ettıl való eltérés a kormányzati EDI rendszerek együttmőködésében jelentıs problémákat okozhat vagy az együttmőködést feleslegesen drágítja (redundáns konverterek, üzenetfejlesztések, stb.). A kormányzati EDI projektek során az EDIFACT szabványrendszer követése kötelezı jelleggel elvárt.

6.2.

X.400

kormányzati üzenetkezelı rendszer a nemzetközi X.400 szabvány szerint van kialakítva és ez megfelel az EU elvárásoknak is. A kormányzati EDI üzenettovábbításban ezért az X.400 szabvány a központilag elvárt üzenettovábbítási szabvány. Az EDI kommunikáció nyílttá tétele is e szabvány alkalmazását igényli.

A

6.3.

X.500

A kormányzati névtár rendszer kialakítása folyamatban van. Az X.400 rendszerhez kapcsolódó szabványos névtár szolgáltatatás az X.500. A nemzetközi tapasztalatok szerint az internetes névtár szolgáltatásban is jelentıs mértékben elıtérbe került az X.500, éppen a szabványos kialakítás miatt. Az EDI területén, egyrészt az X.400-as címzési technikákkal, másrészt az aszinkron kulcsú titkosítási eljárásokkal kapcsolatban merülnek fel névtár szolgáltatási igények. A kormányzati EDI projektekben, ilyenkor az X.500 alkalmazása az elvárt szabvány.

40

7.

JOGI HÁTTÉR

7.1.

A jogi szabályozás általános problémái

Az elektronikus dokumentumkezelésnek évek óta akut problémája a jogi szabályozás hiánya. A hiány össztársadalmi problémákat vet fel és jelentıs mértékben hátráltatja hazánk európai integrációját a gyakorlatban. Úgy a kormányzati, mint a piaci szereplık technológiai fejlıdését akadályozza e törvénykezés további késlekedése. Az elmúlt években e hiány pótlására voltak ugyan kísérletek, de ezek javarészt sikertelenek voltak. A sikertelenség oka leginkább, abban keresendı, hogy a tervezett törvényi szabályozás szintjébe technológiai, módszertani szabályozások keveredtek. Az európai törvénykezési eljárások ezen a szinten általában azt szabályozzák, hogy az elektronikus dokumentumok cseréjében résztvevı partnerek, milyen szerzıdés keretében tudnak egymással megállapodni, egymás elektronikus dokumentumainak elfogadása tekintetében. Vagyis, nem a technológiai megoldások felemlítésével szabályoz (ami úgyis éveken belül elavul), hanem azt mondja meg, hogy minek kell egy ilyen, úgynevezett Adatcsere Egyezményben (Partner Agreement – ben) mindenképpen benne lennie, ahhoz, hogy ez a szerzıdés törvényes legyen. (hasonlóan, ahogy nálunk a törvény kimondja például, hogy az adás-vételi szerzıdésekben az árnak szerepelnie kell és nem azt szabályozza, hogy az adásvétel milyen technikák szerint történik) A kormányzati rendszerekre vonatkozó biztonságtechnikai elvárásokat Kormány Rendeletben lehetne szabályozni a törvény alapján, ahol módszertani elıírásokat is ki lehetne kötni a biztonsági fokozatoknak megfelelıen és mellékletként adatcsere egyezmény formátumot is elı lehetne írni.

7.2.

EDI projektekkel kapcsolatos szerzõdések

A dokumentumcserék jogi hátterének megteremetése az egyik legfontosabb kormányzati feladat az informatikában, aminek megvalósítása viszont elsısorban nem informatikai, hanem jogügyi és törvénykezési feladat. Ugyanakkor a munkához jelentıs informatikai ismeretre is szükség van. Mindez azt jelenti, hogy a törvény elıkészítésben központi kormányzati koordinációra és hatáskörre van szükség az illetékes területek munkájának összehangolásában. Számos oka van annak, amiért egy üzleti vállalkozás vagy tevékenység körül létre kell hozni a megfelelı jogi struktúrát, ezt azonban csak eszközként, és nem célként kell kezelni. Sajnálatos módon szinte mindenben, ami a jog körül, illetve a joggal kapcsolatban történik, szinte azonnal bonyodalmakat és zavarokat vélnek felfedezni. Ilyen elıfordul, a cél azonban az, hogy ne akadályként, hanem segédeszközként kezeljük és értelmezzük egy üzleti tevékenység jogi vonatkozásait, illetve annak kiterjesztéseként az EDI jogi vonatkozásait. Az EDI-vel kapcsolatos jogi kérdéseket nehezíti, hogy az elektronikus adatok cseréjének nemzetközi vonzata is van illetve a nemzetközi viszonylatban számos jogi kérdés van a jogi rendszerek különbözısége miatt. Ne feledjük; az EDI csupán egy újabb eszköz üzleti fegyvertárunkban, és hasonlóan ahhoz, ahogyan a gazdasági szereplık elképzelhetetlennek tartják, hogy a jelenlegi, papíron lebonyolított tranzakcióknak ne legyen valamilyen jogi háttere, az elektronikus rendszereknél is szükség van ilyen jogi

41


szabályozásra. Ezért célszerő az EDI partnerek szándékait, jogait és kötelezettségeit adatcsere szerzıdésben rögzíteni.

7.3.

Adatcsere szerzõdés

Az adatcsere szerzıdés áttekinthetıvé teszi a felek jogi helyzetét. A szerzıdés alkalmas arra is, hogy a felek rögzítsék a felelısség és a kockázat megosztását. Rendszerint a szerzıdés melléklete foglalkozik a technikai specifikációkkal, a biztonsági intézkedésekkel és üzemeltetési eljárásokkal. A kezdeti esetekben a különbözı partnerekkel egyenként is megköthetı az adatcsere szerzıdést, de a partnerek növekedése esetén már nehezen kezelhetı. A szabványos adatcsere szerzıdés kialakítása és elfogadtatása az államigazgatásban a MEH EDI munkabizottságának lehetne a feladata, ahogy az elsı ilyen szerzıdés az Amerikai Vonalkód Egyesület illetve a Brit EDI egyesület által került kidolgozásra. A legtöbb szabványosított szerzıdés az elektronikus adatátvitellel történı kereskedelmi adatcsere egységes szabályai (UNCID) alapján készült. Az európai EDI szerzıdésminta 14 fejezetet tartalmaz: 1. fejezet: A szerzıdés célja és alkalmazási területe 2. fejezet: Meghatározások 3. fejezet: A szerzıdés formája és a szerzıdéskötés 4. fejezet: Az EDI üzenetek elfogadhatósága és bizonyító ereje 5. fejezet: Az üzenetek vételének folyamata és nyugtázása 6. fejezet: Az üzenetek biztonsága 7. fejezet: Bizalmas adatok, a személyi adatok védelme 8. fejezet: Az üzenetek nyilvántartása és tárolása 9. fejezet: Az EDI mőködésének követelményei 10. fejezet: Mőszaki specifikációk és követelmények 11. fejezet: Felelısség 12. fejezet: A vitás kérdések rendezése 13. fejezet: Alkalmazandó jog 14. fejezet: Érvényesség, módosítás, hatály és a rendelkezések különválaszthatósága

7.4.

Az EDI szerzõdés technikai tartalma

A jogi szöveget technikai melléklet egészíti ki, amely tartalmazza a szabványok és az EDIhez használt eszközök jellemzıit. Ez a dokumentum olyan tételek részletes adatait tartalmazza, amelyek az idı folyamán változhatnak: • • • • • • •

42

az adatátvitelek gyakorisága; a tranzakciók jellege, pl. mely EDI üzenetek; alkalmazott hálózatok; alkalmazott postafiók-azonosítók; az átvitel ellenırzésének gyakorisága; lekérdezések vagy problémák esetén a kapcsolattartással megbízott személyek neve, címe és telefonszáma; a „munkanap” definíciója;

• • • • • •

7.5.

állami ünnepek idıpontjainak bejelentése. tartalékeljárások biztonsággal kapcsolatos elıírások adatok tárolása rendszer elérhetısége technikai eszközök rögzítése

Üzenetmegvalósítási kézikönyv

Ez az a dokumentum, amely leírja milyen üzenet kerül továbbításra és fogadásra, valamint hogy az egyes üzenetek mit tartalmaznak és az egyes adatok mint jelentenek. Ezen dokumentum alapján tudja a partner a saját rendszeréhez illeszteni az EDI rendszert illetve az EDI üzenet megvalósítását elvégezni maga vagy egy megbízott partner által. Ez a dokumentum a következı elemeket tartalmazza: • •

• • • •

7.6.

Üzenet típus Üzenet áttekintés − Funkcionális leírás − Alkalamazási terület − Alapelvek Üzenet definíció Szegmens index Üzenet struktúra Szegmens részletezés

Hálózati szolgáltatások szerzõdése

Az Adatcsere Szerzıdés mellett- feltételezve, hogy használatba vételre kerül egy harmadik fél hálózata, amire szintén szükséges egy szerzıdést aláírni. Mint bármely szolgáltatás szerzıdése esetén, a potenciális felhasználónak megbeszéléseket és tárgyalásokat kell folytatnia a hálózati szolgáltatóval, hogy kielégítıen biztosított legyen a nyújtott szolgáltatás az üzleti elvárásoknak.

43


8.

EDI AZ EU-BAN

Az EDI fejlesztésének sebessége eltérı az európai piac vezetı gazdaságai között. Az Egyesült Királyság egyértelmően Németország és kisebb mértékben Franciaország elıtt jár, de az EDI elterjedése a nyolcvanas évtized vége felé jósoltakhoz képest lassabban halad. Ez nem lenne baj, ha elegendı idı állna rendelkezésre ahhoz, hogy minden egyes ország és minden egyes üzleti szektor kialakíthassa az EDI bevezetéséhez a saját ütemtervét. Ezzel összevetve azonban a világ többi részén jóval gyorsabb az elırehaladás és az Egyesült Államok, Ausztrália és a Távol-Kelet feltörekvı gazdaságai jelentısen fokozzák az ütemet. Az EDI bevezetését Szingapúr, Hongkong és Indonézia gazdaságaiban erıs kormányzati kezdeményezések ösztönzik. A közelmúltban az Egyesült Államokban az EDI és az elektronikus kereskedés bevezetésének a kormányzat által támogatott szupersztráda program révén történı megvalósítására tett lépések következtében Európa egyre inkább a lemaradás fenyegetésével kénytelen szembenézni. Az EU mindig is törekedett az európai távközlési és közlekedési infrastruktúra erısítésére az európai vállalatok versenyképességének fokozása érdekében. E célból folyamatosan különös fontosságot szentel a telekommunikációs és információpolitikai programoknak, köztük az EDI programnak. A Maastrichti Szerzıdés XII. fejezete rendelkezik a távközlési szektoron belül a transzeurópai telekommunikációs hálózatok létrehozatalához és bıvítéséhez szükséges keretekrıl. Ez az irányzat került megerısítésre az 1993. évi Koppenhágai csúcstalálkozót követıen, amikor nyilatkozat született arról, hogy a Bizottság 30 milliárd ECU összeget szán a következı tíz év során a hálózati struktúra fejlesztésére, 0.5 milliárdot az informatikai infrastruktúrára és 5-8 milliárdot a megfelelı programokra. A EU telekommunikációs politikájának alapja a Nyitott Hálózat Biztosításának (Open Network Provision, ONP) elve. Ez azt jelenti, hogy mindenki, aki szolgáltatást (pl.: VANt) szándékozik kínálni, köteles megfelelı piaci áron nyílt hozzáférést biztosítani a távközlési infrastruktúrához. Az elv bevezetése igen jelentıs lépés a távközlési egységes piac létrehozatala irányában és új kereteket biztosít az EDI európai elterjesztéséhez. Az Európai Bizottság e lépései fokozódó nyomást gyakorolnak a helyi nyilvános távbeszélıés távíró-szolgáltatókra (PTT). A globális verseny és az új technológiák valamint az állami távközlési monopóliumok megszüntetésére meghatározott 1998. évi határidı együttes fenyegetésének hatására a nemzeti távközlési szolgáltatók a szolgáltatásaik teljesítéséhez új partnereket és új módokat kerestek. A Bizottság, az ONP elv érvényesítése révén biztosította, hogy a nemzeti kormányzatok az általános európai érdeknek alárendeljék a helyi távközlési szolgáltatók védelmére irányuló igényeiket. A transz-európai hálózatok felépítése a strukturális ipari váltás felgyorsítására irányuló általános célkitőzés része. EU - IDA programok Az IDA program keretében 26 projektet finanszíroznak központi forrásból, amelyeknek közös vonása, hogy valamely - az EU összes tagállama számára fontos - funkció megvalósításának érdekében a kommunikációt és az információcserét megoldja. Ezért e projektek többsége szorosan kapcsolódik egy, vagy több informatikai fejlesztéshez (pl. adatbázisok kialakítása, alkalmazási rendszerek kidolgozása, stb.) és természetesen nem mindegyük alkalmaz EDI technikát, mert esetenként az adott cél megvalósítása interaktív kapcsolatok kialakítását, vagy nagy adatállományok cseréjét, esetleg E-mail kapcsolatok 44

bevezetését igényli. Az IDA által finanszírozott projektek keretében nemcsak az információcserével összefüggı kommunikációs és üzenetkezelési feladatokat oldják meg, hanem egyes projektek sok esetben az informatikai rendszerek kapcsolódásának alapfeltételeként az adatstruktúrák, egységes metaadatok kidolgozását is támogatja. Az IDA un. horizontális (több igazgatási, illetve gazdasági területet érintı) és szektoriális projekteket támogat és felügyel. Az alábbiakban néhány olyan fontos EU projektet ismertetetünk, amelyek többsége EDI alapú dokumentumcserére épül és amelyhez Magyarország EU csatlakozásakor, vagy azt követıen hamarosan a magyar kormányzati informatikai rendszereknek is csatlakozniuk kell. Ezzel kapcsolatban fontos megjegyezni, hogy a már kialakult és mőködı rendszerekhez történı magyar kapcsolódás nemcsak, sıt nem elsısorban kommunikációs kapcsolatok, vagy akár az EDI alkalmazásának kérdése, hanem mindenekelıtt szervezési, informatikai feladat. Hiába épülnek ki a magyar és az EU közigazgatás között a megfelelı minıségő, sebességő kommunikációs kapcsolatok, az adott céloknak megfelelı EDI alkalmazások, ha a magyarországi informatikai rendszerek nem tartalmazzák, vagy nem képesek elıállítani az elıírt struktúrában és összetételben az információcserében megkívánt adatokat. Ezért fontos az európai rendszerek és a magyar kormányzati rendszerek mielıbbi, alapos összevetése és a jogi-, eljárási és strukturális harmonizáción kívül az informatikai rendszerek harmonizációjára irányuló tervek kidolgozása. CCN/CSI (Common Communicaitons Network / Common System Interface) A 90-es évek közepére az Európai Unióban számos olyan informatikai rendszert fejlesztettek ki és vettek használatba, amelyek a Közösség központi irányítása és a tagországok számára egy-egy alkalmazási területen, egymástól elveiben és az alkalmazott megoldások tekintetében is eltérı, saját kommunikációs hálózatra épült. A sokféle hálózat kiépítése és üzemeltetése (amelyek között több EDI hálózat, illetve EDI kapcsolatrendszer is megtalálható) jelentıs költséggel jár. Az IDA program megindításától kezdve egyik fı feladatának tartotta egy egységes hálózati architektúra kidolgozását és ennek alapján egy általános, csaknem minden közösségi rendszer által alkalmazható hálózat létrehozását. A hálózat általános architektúrája tagállamonként egy helyi központot (local domain) és egy közösségi központot (Euro Domain) tartalmaz, amelyhez minden helyi központ egy bejáraton (Euro Gate) kapcsolódik. A CCN/CSI elsıdleges célja az Unió központi igazgatása és a tagállamok között, az információ cserében alkalmazott eljárások és módszerek harmonizációja. Az egységes hálózat bevezetése számottevı költségmegtakarítást, biztonságosabb üzemeltetést jelent valamennyi csatlakozó alkalmazás számára.

8.1.

Statisztikai adatgyûjtéssel kapcsolatos projektek

Az Európai Közösségben évek óta megfogalmazódott az a törekvés, hogy a különbözı célú statisztikai alapadatok szolgáltatása lehetıleg az érdemi tranzakcióval egyidıben, az érdemi feldolgozást végzı informatikai rendszerek által elıállított adatokkal történjen. Ez a módszer egyszerősíti a statisztikai célú alapadatok elıállítását, az adatszolgáltatásokat és az adatgyőjtést egyaránt. Az EK központi statisztikai hivatala, az Eurostat egy olyan modellt dolgozott ki, amelyben az alapadatok győjtését közvetítı ügynökségek végzik, amelyek nem feltétlenül állami intézmények. Ezek nemcsak a statisztikai, hanem az ügylettel kapcsolatosan valamennyi adatot begyőjtenek és ezeket összesítve továbbítják, az adatok jellege szerint illetékes nemzeti hivatalokhoz, így például a vámbevallás adatai a 45


vámhatósághoz, a kapcsolódó statisztikai adatok pedig a statisztikai hivatalhoz kerülnek, miközben az adatszolgáltatásra kötelezett gazdálkodó szervezetnek csak egy alkalommal, egy példányban, egy EDI dokumentumot kellett elkészítenie és elküldenie. Ez a modell ma még csak kísérleti stádiumban van, számos eljárási és jogi probléma még megoldatlan, például az adatszolgáltató nem annak az intézménynek küldi el adatait, amely az adatszolgáltatásra kötelezi, stb. A statisztikai alapadatok győjtése az alábbi - némely esetben nem kizárólag statisztikai célú adatgyőjtéssel is kapcsolatos - IDA projektekhez társulhat: DSIS (Distributed Statistical Information Services) Az 1994-ben indított DSIS projekt az Európai Közösségben nemzeti és nemzetek közötti szinten folyó, a statisztikai adatok győjtésével, feldolgozásával és szétosztásával foglalkozó számos projekt összehangolására vállalkozott. A projekthez kezdettıl csatlakoztak az EFTA tagországok is. Ezek a kezdeményezések a Közösség és a tagországok adminisztrációinak munkáját segítik azáltal, hogy fejlett informatikai és kommunikációs eszközöket alkalmaznak a statisztikai adatgyőjtésben, így a költségek redukálása, a gazdasági folyamatok pontosabb követése mellett lehetıséget adnak a statisztikai feldolgozások eredményeinek visszacsatolására, amivel az adatszolgáltatók is érdekeltté tehetık. A statisztikai adatgyőjtéssel kapcsolatban számos feladat van, amelyek ugyan érintik az EDI alkalmazását, de messze túlmutatnak azon. Így a DSIS program célul tőzte ki a metaadatok harmonizálását (az aktuális adatok meghatározása és minısítése), referencia környezet és központi metaadat könyvtár kialakítását és természetesen EDI üzenetek kidolgozását, adatszolgáltatási eljárások és kommunikációs ajánlások kidolgozását, továbbá multimédia alkalmazását a statisztikai feldolgozások eredményeinek szétosztásában. 1997-ben a DSIS projekt keretében kijelölték azokat az elsıdleges fontosságú statisztikai területeket, amelyek az európai referencia modell kialakításában szerepet kapnak: • pénzügyi területek: nemzeti számlák, fizetési mérlegek, ECU (1998 óta euro) statisztikák • külkereskedelem • ipari mutatók, termelési adatok, árindikátorok • mezıgazdasági mutatók • szállítmányozás • biztosítás • egészségügyi-, és környezetvédelmi statisztikák • alkalmazási mutatók A fenti területeken az adatok győjtésével kapcsolatban széleskörő EDI szabványosítási munkát folytattak, számos EDIFACT üzenet tervezésére került sor (GESMES, RDRMES, CLASET, CUSDEC/INSTAT, BOPSTA, stb.) A projektben figyelemmel kísérik az új Open-EDI szabványosítási törekvéseket. Az EBES, az Európai Közösség EDI szabványosítási bizottsága az XML/EDI alkalmazásának lehetıségeit vizsgálja. A statisztikai alapadat-szolgáltatás támogatása, egységesítése és egyszerősítése céljából akciókat indítanak szoftverfejlesztı cégeknél, hogy megkezdıdjön a statisztikai EDIFACT üzenetek (GESMES, CLASET, RDRMES, ...) integrálása a vállalatirányítási informatikai rendszerekbe. A DSIS program szorosan kapcsolódik a SERT és az EXTRACOM projektekhez.

46

SERT (Statistiques d’Enterprises et Réseaux Télématique) Annak érdekében, hogy az EU-ban folyó gazdasági tevékenységekrıl pontos képet lehessen alkotni, a vállalatoktól statisztikai adatokat kell győjteni. Ezek az adatok a vállalatok szinte minden tevékenységére kiterjednek (üzleti-, termelési-, pénzügyi-, exportés import-, munkaadói- és munkavállalói-, befektetési adatok, fizetési mérlegek, stb.) A SERT projekt célja, hogy automatizálja, egyszerősítse, gyorsabban és alacsonyabb költséggel oldja meg a statisztikai adatok győjtését, elsısorban a kis- és közepes vállalkozásoktól, amelyeket a sokirányú, többnyire redundáns adatszolgáltatási kötelezettségek költségei a leginkább érintenek. A projektnek a statisztikai adatgyőjtés egyszerősítése mellett az is célja, hogy közös szabványok és ajánlások kidolgozásával nyitott piacot teremtsen a szoftver fejlesztık és az európai kommunikációs szolgáltatók számára is, EDIFACT (RDRMES üzenet) és SGML alapú adatgyőjtı rendszerek kifejlesztésére, az üzleti informatikai rendszerek ilyen irányú kiterjesztésére, és az ezzel kapcsolatos szolgáltatások beindítására. A SERT projekt keretében számos, a tagországokban már kidolgozás alatt lévı EDI rendszert illetve EDI pilot projektet figyelembe vesznek, az értéktöbblet adó bevallástól, a export- és szállítási statisztikákon keresztül a szállodai bejelentésekig. Ilyen, a SERT keretében folyó pilot projekt többek között az acél- és széntermelési statisztikák győjtésére, az EDIFACT PRODCOM üzenet alkalmazásával indított nemzetközi adatgyőjtés, az Egyesült Királyságban a többcélú, egységes adatgyőjtés megvalósítására kezdeményezett projekt, vagy az a tanulmány, amely javaslatot tesz a statisztikai célú adatgyőjtésre szolgáló EDIFACT üzenetek integrálására a széles körben alkalmazott Integrált Vállalatirányítási Rendszerekbe. EXTRACOM (EXternal TRAde statistics) Az EXTRACOM kezdeményezés a külkereskedelmi statisztikai adatok győjtésével kapcsolatos, az IDA által koordinált akciók győjtı elnevezése. A külkereskedelmi statisztikai alapadatok győjtése jelenleg a vámbevallások alapján, némely esetben és országban külön statisztikai bevallások útján történik. A projekt célja, hogy a Közösségen belüli forgalomi statisztikai adatgyőjtéseket egységesítse és mindinkább elektronikus útra terelje a Közösségen kívüli országokba szállított árúkra vonatkozó statisztikai alapadatgyőjtést is, továbbá javítsa az adatok minıségét, részletezettségét és pontosságát. A projekt keretében az elektronikus, EDIFACT alapú adatgyőjtésen kívül - ami EDIFACT üzenetek bevezetését és az egyszerősített eljárásokban SGML, vagy más elektronikus őrlapkitöltést jelent - meg kívánják oldani az egységes áruosztályozást és az egységes külkereskedelmi metaadatok bevezetését és kezelését az Európai Unión kívüli országokkal folytatott külkereskedelmi statisztikai rendszerekben, a nemzeti statisztikai intézetekben és az Eurostat-nál. Ezen kívül meg kívánják teremteni a kapcsolatot a vámeljárások és a külkereskedelmi statisztika között. Amíg a Közösségen belüli áruforgalom statisztikai adatainak cseréje részben már (EDIFACT üzenetek alkalmazásával) megoldott, az EDI alkalmazását a csatlakozó országokra is kiterjesztik. Az EXTRACOM kezdeményezés foglalkozik a metaadatok és az áruosztályozás egységes megoldásával. Az Eurostat-nál kialakított klasszifikációs adatbázisokat a tagországokban duplikálják és kiegészítik a saját, belsı osztályozásukkal. A metaadatbázis frissítésére az EDIFACT CLASET üzenetet alkalmazzák. Az EXTRACOM projektben tanulmányozzák a csatlakozó országok bevonásának, illetve az eredmények EU-n kívüli hasznosításának lehetıségeit is. A projekt számos 47


tevékenységében kapcsolódik a SERT projekthez.

8.2.

Szociális ellátással, munkaüggyel kapcsolatos projektek

A TESS/SOSENET program (Telematics for Social Security/Social Security Network) Az Európai Közösségben a szociális ellátások öt fı területe a nyugellátás, egészségügyi ellátás, munkanélküli ellátás, családi ellátás valamint a baleseti sérültek és fogyatékosok ellátása. Ezeket az ellátásokat központilag koordinálják, mert akkor is változtatás nélkül megilletik a jogosultakat, ha az Unió területén másik tagországba költöznek. Az ügyintézés nagy mennyiségő, a határokon keresztül áramló információ cseréjét és az egyes nemzeti ellátási rendszerek összehangolását követeli. A TESS projektben a legjelentısebb a nyugdíj- és az egészségügyi ellátás információcsere igényeinek kielégítése A nyugellátás területén a feladat a munkáltatói adatok továbbítása a vendégmunkások hazaköltözését követıen, a nyugdíjak megállapításához. Az egészségügyi ellátások költségeinek megtérítése ugyancsak nagytömegő információ továbbítását igényli, hogy a kezelés helyén, az ellátás költségeinek kifizetését követıen a helyi biztosító annak megtérítését kezdeményezhesse a beteg illetékes biztosítójától. A TESS program az európai polgárok ellátásának javítását, az eljárások egyszerősítését és gyorsítását, valamint az adminisztrációs költségek csökkentését célozza, egyben támogatja a szabad lakóhely változtatást a tagországok között. A program gyakorlati elınyei: • Csökkenti az adminisztrációs késeltetést és hibákat a több tízmillió utazó és turista számára, akik sürgısségi ellátásban részesülnek lakóhelyükön kívül, és az ugyancsak több tízmillió munkavállaló számára nyugdíjuk megállapításában, akik több, mint egy tagállamban dolgoztak (ideértve a határok mellett élıket is). • Csökkenti az eddig évi 5 millió őrlap kezelésével járó költségeket. A cél elérése érdekében a projekt végére a tagállamokban több, mint 1000 intézmény és több mint 5000 helyi hivatal fogja alkalmazni az EDI technikát és a hálózati szolgáltatásokat. A TESS program az európai szabványokra és az IDA ajánlásaira épül, X.400 üzenetkezelést és EDIFACT dokumentumokat alkalmaz. A szektoriális feladatokat, vagyis az egyes tagországok biztosítási rendszereinek összehangolását a tagországok fedezik, az IDA finanszírozza az adatcserével kapcsolatban a megvalósíthatósági tanulmányok, a tervezés és a kivitelezés költségeit. 1998-ban kezdıdött meg egy referencia modell kiépítése hét tagország és 20 intézmény részvételével. EURES (European Employment Services) Az EURES projekt célja olyan információs hálózat létrehozása a Tagországok között, amely az egységes európai munkaerıpiac kialakulását segíti azáltal, hogy részletes adatokat tárol és továbbít a munkalehetıségekrıl és munkaerı kínálatról, továbbá általános információkat szolgáltat az élet- és munkakörülményekrıl, a munkavállalók, munkaadók és a kormányzatok számára. Az EURES programhoz a tagállamok munkaerı hivatalain kívül csatlakoztak a szakszervezetek és a munkaadói szervezetek is. Az 1993-ban indított projekt a megvalósíthatósági tanulmányok elkészítése után elıször a tagországokban már akkor is meglévı munkaügyi adatbázisok összekapcsolására, saját hálózat kialakítására és Windows alapú kliens szoftver kidolgozására összpontosított. Késıbb került sorra egy központi adatbázis kidolgozása a munkaerı kereslet (betöltetlen munkahelyek)

48

adatbázisának kialakítására és jelenleg folyik a munkaerı kínálat adatbázisának megteremtése. Az EURES projekt ugyan nem alkalmaz EDI kapcsolatokat a nemzetközi adatcserében, de néhány regionális alkalmazásban, így például elıször az osztrák-német, majd a németfrancia közös munkaügyi alkalmazásokban már az EDI technikát is alkalmazzák.

8.3.

A nemzetközi szállítmányozással, VÁM és adózással kapcsolatos projektek

Az Európai Unió több olyan projektet indított, amelyek az Unió-n belül és az Unió határain kívülre szállított árukkal kapcsolatos információcserét az EDI alkalmazásával oldják meg. TRANSIT (Transit Computerisation Project) A Közösség tranzit megállapodása az Európai Unió és az EFTA tagországok, továbbá a Visegrádi Országok közötti áruszállításban teszi lehetıvé, hogy a tranzit szállítmányok után nem kell elıre megfizetni a vám és adó tételeket, valamint nem szükséges további vizsgálatokat végezni. E megállapodás gyorsítja és egyszerősíti a vámeljárásokat, megkönnyíti a külkereskedelmi vállalatok munkáját, de szigorúbb ellenırzést tesz szükségessé. A TRANSIT rendszer célja, hogy részletesebb adatgyőjtés és feldolgozás révén, a vámhatóságok számára lehetıséget adjon a visszaélések felderítésére, amellett, hogy a megállapodást aláíró szervezetek tagországaiban egyszerősíti és gyorsítja a többi tagországba irányuló tranzit-szállításokkal kapcsolatos eljárásokat. Az EC/EFTA országok közös tranzitszállítási bizottsága még 1993-ban kezdte vizsgálni egy informatikai rendszer kidolgozásának lehetıségeit a tranzit vámkezelés gyorsítására. A rendszer létrehozására a végsı döntést az Európa Tanács, majd az Európai Parlament hozta meg 1995 végén. A TRANSIT projekt 1997-ben túljutott az eljárási és szervezési kérdések megoldásán és az elsı EDI üzenetek tervezésén és 1998-ban megindult az elsı pilot rendszer kidolgozása néhány tagország részvételével.

49


9.

50

Idegen kifejezések magyarázata (GLOSSARY) adatcsere (interchange)

az EDI partnerek számítógépes alkalmazásai közötti kommunikáció (egy, vagy több üzenet), amely fejrésszel kezdıdik és zárórésszel végzıdik

adatcsere egyezmény (interchange agreement)

az EDI partnerek közötti szerzıdés, amely tartalmazza az adatcserében alkalmazott üzenetek típusát (verziókat, stb.), szintaktikáját, a jogi, biztonsági és egyéb követelményeket

adatcsere fejrész (interchange header)

az adatcsere kezdı szolgálati szegmense, amely azonosítja az információcserét

adatcsere zárórész (interchange trailer)

szolgálati szegmens, amely lezárja az információcserét

adatelem (data element)

az EDI üzenetek specifikációjának legkisebb önálló egysége, lehet egyszerő- és összetett

adatelem címke (data element tag)

az adatelem egyértelmő azonosítója

adatelem érték (data element value)

az egyszerő adatelem konkrét elıfordulása, amelynek tartalma megfelel a specifikációnak

adatelem könyvtárak (data element directory)

az egyszerő és az összetett adatelemek megnevezését és specifikációját tartalmazó

adatszegmens azonosító (data segment identifier)

az adatszegmensek egyértelmő megkülönböztetésére szolgáló karaktersorozat

ADMD (Administrative Message Domain)

Az ADMD alá tartozó PRMD-k az ADMD-n keresztül kommunikálnak egymással.

alkalmazási rendszer (application system)

adatfeldolgozó programrendszer, amely egy meghatározott funkciót (pl. vállalatirányítás, stb.) lát el

alkészlet (subset)

egy, vagy több üzenet speciális értelmezése egy adott iparág, vagy alkalmazás-típus kívánalmainak megfelelıen (pl. EANCOM), az üzenetnek csak azokat az elemeit tartalmazza, amelyek az adott célra szükségesek

ANSI X.12

az Amerikai Nemzeti Szabványügyi Intézet által kifejlesztett és karbantartott EDI szabványok

azonosító (identifier)

egy adat azonosítására, vagy tulajdonságainak jellemzésére szolgáló karakter, vagy karakter sorozat

boríték (envelop)

az EDI átvitelben az üzeneteket közrefogó alkalmazott fejrész és zárórész

CCITT

Nemzetközi Telefon- és Távíró Tanácsadó Testület, a távközlési rendszerek szabványainak fejlesztésében érdekelt szervezet, amely része az ENSZ Nemzetközi Távközlési Egyesületének (ITU-T).

címke (tag)

szegmens, vagy adatelem egyértelmő azonosítója

csoport (group)

üzenetek, vagy objektumok összessége, amelyeket egy csoport fejrész és egy csoport zárórész határol

csoport fejrész (group header)

szolgálati szegmens, amely egy csoportot bevezet és azonosít

csoport zárórész (group trailer)

szolgálati szegmens, amely egy csoport végét jelzi

DATACOM FILE

X.400-ban borítékolt file

Delivered

Üzenet státusz. Üzenet érkeztetésének visszaigazolása

digitális aláírás (digital signature)

olyan egyedi adat, amely az üzenethez csatolva, vagy a titkosítás során a címzett számára egyértelmően azonosítja az üzenet küldıjét és bizonyítja az üzenet sértetlenségét

DLL

Dinamic Link Library: Dinamikusan szerkeszthetı könyvtár. A Windows alatt lehetıvé teszi, hogy több alkalmazás megosztva tudjon program kódokat és erıforrásokat használni.

DOMAIN DEFINED ATTRIBUTES

Az X.400-as címek egyik összetevıje, akkor használatos, ha olyan valakinek küldünk üzenetet, aki nincs az X.400-as rendszerbe kapcsolódva.

EDI

Electronic Data Interchange: Elektronikus adatcsere

EDI szoftver (EDI software)

szoftver csomag, amely az elektronikus adatcserével kapcsolatos funkciókat végzi (kommunikáció, transzláció, adminisztráció, alkalmazási rendszer kapcsolat)

EDIFACT

Electronic Data Interchange for Administration, Commerce and Transport

EDI WEB SZERVER

Elektronikus formanyomtatványok szolgáltatása WEB szerveren keresztül, amik a szerveren EDIFACT üzenetté konvertálódnak.

egyedülálló adatelem (stand-alone data element)

egyszerő adatelem, amely nem része egy összetett adatelemnek

egyszerő adatelem (simple data element)

egyetlen értéket tartalmazó adatelem, lehet összetevı adatelem, egy összetett adatelemen belül, vagy egyedülálló adatelem

egyszerő adatelemek könyvtára (simple data element directory)

az egyszerő adatelemek listáját, specifikációját tartalmazó könyvtár

elektronikus adatcsere (electronic data interchange)

Lásd EDI!

Elektronikus őrlap

Elektronikus formanyomtatvány: számítógépesen megjelenített formanyomtatványok, amik számítógépen tölthetık ki.

elválasztó karakterek (separator characters)

szintaktikai célokra fenntartott szerviz karakterek, amelyek az adatelemek, ismétlések, vagy szegmensek elválasztására szolgálnak

fejrész (header)

Az EDI üzenet bevezetı része, amelyben az egész üzenetre vonatkozó információ van

felépítés (construction)

a továbbítandó adatok ellenırzése és az EDI szabványnak megfelelı üzenet elkészítése

felhasználói adatszegmens (user data segment)

felhasználói adatokat hordozó szegmens

feltételes (conditional)

szegmensek, vagy adatelemek azon tulajdonsága, hogy a partnerek megegyezése, vagy az üzenet tartalma szerint jelenlétük nem kötelezı

Fordítás

a beérkezı EDI üzenetek ellenırzése és értelmezése az EDIFACT szintaxis és az adott üzenet szabályai szerint, az adatmezı- és kódelem hivatkozások feloldása

Fordító profil

Mapping Table: Az inhouse file EDIFACT üzenetté és viszont alakítását vezérlı programozó táblázat a konverterben.

Front-end gép

Amikor a belsı számítástechnikai ügyvitel gépei egy külön gépen keresztül kapcsolódnak az EDI üzenetekhez az inhouse EDIFACT oda-vissza konverzió ezen a “front-end” gépen történik.

funkcionális csoport (functional group)

egy, vagy több azonos típusú üzenet, amelyet a funkcionális csoport fejrész és a funkcionális csoport zárórész fog közre

funkcionális csoport fejrész (functional gropu header)

egy funkcionális csoportot megelızı és azt azonosító szolgálati szegmens

funkcionális csoport zárórész (functional group trailer)

egy funkcionális csoportot lezáró szolgálati szegmens

51


52

Gateway

Az X.400 rendszert más levelezı rendszerhez illesztı szoftver eszköz.

hozzáférés ellenırzés (access control)

egy erıforrás használatának visszautasítása jogosulatlan hozzáférés esetén

IDA

Interchange of Data between Administrations

Inhouse

Belsı formátum: a belsı számítástechnikai ügyvitel olyan fileainak formátuma, amik EDI üzenetté illetve EDI üzentbıl alakulnak.

ismétlıdı adatelem/szegmens (repeating data element/segment)

olyan adatelem, vagy szegmens, amely az adott üzenettípus specifikációja szerint megismételhetı

ISO

International Standard Organisation for Standardisation

Kernel

Szoftveres központi modul

kód (code)

az információ gépi ábrázolására használt szimbólum, vagy konkrét adatokat ábrázoló numerikus, vagy alfanumerikus karaktersorozat

kódlista (code list)

a kódolt adatelemek értékeinek készlete

Konverter

Kétirányú fordító program

kötelezı (mandatory)

szegmenscsoport, szegmens, összetett adatelem, vagy egyedülálló adatelem státusa, amely elıírja annak legalább egyszeri használatát

Log-file

Napló file

Mailbox

Elektronikus levél láda. Az üzenettovábbítás a mailbox címén keresztül történik. Az üzenetek a továbbításig a mailboxban tárolódnak.

metaadatok (metadata)

az adatbázisban tárolt üzemi adatok jellemzıinek adatbázisa (az adatok struktúrája és dimenziói, az adattárba kerülésük ideje, forrása és módja, archiválásuk ideje, információk a hozzáférésrıl, stb.)

minısített adatelem/szegmens (qualified data element/segment)

olyan adatelem/szegmens, amelynek pontos jelentését egy minısítı adatelem határozza meg

minısítı adatelem (qualifier)

olyan egyszerő adatelem, amelynek értéke egy kódlista alapján egy másik adatelem, vagy szegmens értelmezését, vagy jelentését határozza meg

MS

Message Store: X.400 alapú rendszerben az üzenetek tárolását végzı szoftver.

MTA

Message Transfer Agent: X.400 alapú rendszerben az üzenettovábbítást X.400 szabvány szerint végzı szoftver

ODBC

Open Database Connectivity: nyitott adatbázis kapcsolat. A Windows nyílt architektúrájú adatbázis elérést támogató szoftver eszköze.

összeköttetés (connection)

adatátviteli kapcsolat az EDI üzenetek továbbításához

összetett adatelem (composite data element)

az összetevı adatelemek csoportja, amely a szabvány szerinti sorrendben egy adott információt együttesen ábrázol

összetett adatelemek könyvtára (composite data element directory)

az összetett adatelemek megnevezésének és specifikációjának felsorolása

összetevı adatelem (component data element)

olyan egyszerő adatelem, amely egy összetett adatelem része

partnerek (trading partners)

EDI üzenetek egymásközti cseréjében részt vevı üzletfelek

PRMD

Private Message Domain. Kijelölt MTA az alá tartozó MTA-k a PRMD-n kersztül kommunikálnak egymással.

READY

Üzenet státusz. Üzenet küldésre kész, de nincs elküldve.

RUA

Remote User Agent: Távoli OSI alapú felhasználói alkalmazás az X.400 rendszerben. Levelezı program.

státus (status)

(1)

egy szegmens, összetett, vagy egyszerő adatelem használatát szabályozza (kötelezı, vagy opcionális)

státus (status)

(2)

az ENSZ/EDIFACT dokumentumok és üzenetek fejlettségének jelzése

STORE AND FORWARD

Tárol és továbbít technológia. Az üzenetek a továbbító rendszerben tárolódnak és a fogadó készültsége estén továbbítódnak.

szegmens (segment)

a szegmens specifikációban leírt, egymással funkcionális kapcsolatban álló összetett és/vagy egyszerő adatelemek sorozata, amely szegmens címkével kezdıdik és szegmens zárórésszel fejezıdik be, lehet szolgálati-, vagy adatszegmens

szegmens címke (segment tag)

egy szegmenset bevezetı, azt egyértelmően azonosító egyszerő adatelem, amely a szegmens könyvtárra hivatkozik

szegmens csoport (group of segments)

egybetartozó, többnyire ismétlıdı szegmensek összessége

szegmens csoport (segment group)

a szegmensek és/vagy más szegmens csoportok azonosított, hierarchikus csoportja

szegmens kód (segment code)

egy szegmens egyértelmő azonosítására szolgáló kód

szegmens könyvtár (segment directory)

a szegmensek listája és specifikációja

szegmens zárórész (segment terminator)

a szegmens végét jelzı karakter

szint (level)

egy adatszegmens elhelyezkedése az üzenet hierarchikus rendjében

szolgálati szegmens (service segment)

az adatok cseréjének irányítására szolgáló szegmens

titkosítás (cryptography)

az adatok átalakítása olyan módon, hogy az adatok információ tartalma csak a jogosultak számára legyen hozzáférhetı

titkosság (conditional)

a teljes üzenet, vagy az üzenet egy részének azon tulajdonsága, hogy az információ csak a jogosultak számára hozzáférhetı

transzláció (translation)

az adatok átalakítása valamely EDI szabványnak megfelelı formátumról az alkalmazási rendszer által kívánt belsı formátumra és fordítva.

transzlátor (translator)

az EDI szoftvernek az a része, amely a transzlációt végzi, sok esetben önálló szoftver termékként is megjelenik

tranzakció, ügylet (transaction)

az üzleti, vagy adminisztratív kapcsolatrendszerben a partnerek közötti adatcsere folyamatában egy üzenet összeállítása és elküldése, valamint fogadása és feldolgozása

UA

User Agent: OSI alapú felhasználói alkalmazás az X.400 rendszerben (pl.: levelezı program)

UN/ECE

United Nations/Economic Commission of Europe

UN/EDIFACT

United Nations rules for Electronic Data Interchange for Electronic Data Interchange

UNSM

United Nations Standard Messages azon üzenetek összessége, amelyeket a UN/ECE általános nemzetközi alkalmazásra ajánlott

ügylet

ld. tranzakció

üzenet (message)

egy adott ügyletre vonatkozó, összefüggı szegmensek strukturált együttese, amely üzenet fejrésszel kezdıdik és üzenet zárórésszel 53


végzıdik

54

üzenet diagram (message diagram)

egy üzenet specifikációjában szereplı szegmensek hierarchikus rendjének grafikus ábrázolása

üzenet fejrész (message header)

szolgálati szegmens, amely az üzenetet bevezeti és egyértelmően azonosítja

üzenet kód (message code)

egy adott ügylettel kapcsolatos adatcserére kidolgozott üzenetet egyértelmően azonosító hatbetős kód

üzenet könyvtár (message directory)

az üzenet típusok felsorolása és specifikációja

üzenet típus (message type)

egy adott ügylettel kapcsolatos adatcserére szolgáló üzenet kódja

üzenet zárórész (message trailer)

szolgálati szegmens, amely az üzenetet lezárja

VAN

Value Added Network: hozzáadott értékő hálózat. Szolgáltatók által hálózaton keresztül biztosított EDI szolgáltatás. (EDI üzenetek továbbítására is szolgáló hálózat).

X.400

A szabványos elektronikus üzenettovábbítást definiáló nemzetközi CCITT szabvány

X.435

X.400 borítékolású EDI üzenet váltást definiáló nemzetközi CCITT szabvány

X.500

A directory szolgáltatásokat definiáló nemzetközi CCITT szabvány

X.509

Nyilvános titkosító kulcsok directory szolgáltatását definiáló nemzetközi szabvány

X.25

Csomagkapcsolt hálózati protokoll

Elektronikus adatcsere alkalmazása a kormányzatban TARTATOMJEGYZÉK 1. BEVEZETÉS... 1

Recommend Documents