Bevezetés. Remélhetoleg ez a tankönyv sok érdeklodo számára nyújt segítséget az EDI alapjainak elsajátításában. Budapest, 1997

Elektronikus adatcsere a közlekedésben

Bevezetés A tankönyv célja olyan megalapozó ismeretanyag átadása az olvasó számára, mely az elektronikus adatcserével ismerkedoknek nyújt tájékoztatást. Nem igényel elozetes felkészülést, hiszen ez a könyv adja meg azt a bázist, amire a késobbiekben építeni lehet. Néhány rész talán bovebb információmennyiséget tartalmaz, mint egy bevezeto tananyagtól elvárható, azonban ennek oka az, hogy a megértést minél könnyebbé tegye. Az irodalomjegyzékben felsorolt anyagok ugyanakkor biztosítják azt a lehetoséget, hogy akinek esetleg hiányérzete támad, azt megszüntethesse. Az EDI nagy sebességu fejlodési pályán mozog, melynek egyik hajtóereje a technikai fejlodés. Elképzelheto, hogy egyes fejezetek hamar idoszerutlenné válnak, de az anyag nagyobb része hosszútávon hasznosítható. Az általános jellemzok bemutatását követoen közlekedési példákon keresztül történik az egyes részek világosabbá tétele, de helyettük más példák is azonos értéket képviselnének. Ezért egyaránt ajánlható a tankönyv közlekedési és nemközlekedési terület szakemberei, tanulói, hallgatói számára. Az öt fejezet a rendszertervezési technikáktól kezdve az EDI-projekt tervezéséig vezeti végig az olvasót, miközben megismerkedik a technikai (hardver-szoftver) feltételekkel, a szabványokkal (különösen az ENSZ-EDIFACT-tal), valamint az EDI szerepével a vállalati külso-belso folyamatokban. Remélhetoleg ez a tankönyv sok érdeklodo számára nyújt segítséget az EDI alapjainak elsajátításában.

Budapest, 1997. December

Dr. Tóth János

1


1 Az árufuvarozás információs folyamatai 1.1 Az elektronikus adatcserét megalapozó vizsgálati módszer az árufuvarozásban Az elektronikus adatcsere bevezetésének vizsgálatánál elsoként az információs folyamatokat kell megismerni. Fel kell mérni, hogy az egyes információk honnanhova, milyen adatátviteli eszközön (papír, számítógép stb.) jutnak el. Számos módszer áll rendelkezésre, melyek a gazdálkodó egységek, különféle rendszerek aktuális informatikai helyzetét tárják fel. Az elemzést követoen az információs rendszert racionalizálva készítheto elo az elektronikus úton történo adattovábbítás. Egy rendszer elemei és a közöttük lévo kapcsolatok (relációk) mennyiségi és minoségi paraméterei utalnak az adott rendszer összetettségére, bonyolultságára. Az árufuvarozás a közlekedés rendszerének egy alrendszere - alágazatonként sajátosságokkal rendelkezik -, ugyanakkor komplex (belso felépítése összetett, alrendszerekre bontható fel) és nyílt (környezetével kölcsönhatásban áll). Ezen fejezet célja az alágazatfüggetlen, közös vonások modellszintu bemutatása. Az árufuvarozásnak, mint rendszernek célja az áruk helyváltoztatásának biztosítása. Ehhez egy jól szervezett információáramlásra van szükség (az információ a kello helyen és idoben álljon rendelkezésre). Ezt a közlekedés irányítási rendszerén belül értelmezheto informatikai rendszer valósítja meg, mely az információrendszerbol, az információkezelési (felvételi, átviteli, tárolási, feldolgozási, felhasználási) folyamatok és az információkat hordozó technikai és humán összetevok rendszerébol áll. Az elektronikus adatcsere lehetséges alkalmazásának vizsgálatához az árufuvarozás információs rendszerét kell megvizsgálni. A rendszer összetevoit, azok tevékenységeit és a közöttük lévo információáramlást kell meghatározni. A rendszertervezés folyamatából a helyzetfelmérést, helyzetelemzést kell kiemelni és végrehajtani. Ennek során az árufuvarozáshoz elengedhetetlen okmányokat, dokumentumokat, bizonylatokat kell összegyujteni, szakemberek segítségével az árufuvarozás folyamatát modellszeruen felépíteni és elemezni. 1.1.1 Az árufuvarozás folyamatának elemzési módszere A következokben áttekintjük, hogy milyen lehetoségek, eszközök, ábrázolástechnikák állnak rendelkezésre a feladat végrehajtására. A helyzet felvételénél arra kell törekedni, hogy a szerzett ismereteket áttekintheto és a továbbiak szempontjából egzakt formában lehet dokumentálni.

2


Mivel nem egy alágazatról és nem egyetlen szervezetrol van szó, így a helyzetrögzítés során a statikus struktúrát (a horizontális struktúrát - a térbeli elrendezési ábrát; a vertikális struktúrát - a szervezeti ábrát; a funkcionális struktúrát) részben lehet rögzíteni. Ez azt jelenti, hogy a rendszer összetevoit (az árufuvarozási folyamat résztvevoit) lehet meghatározni. A továbbiakban a dinamikus struktúrát kell tehát részleteiben megvizsgálni. 1.1.1.1 A dinamikus struktúra rögzítésének technikája A dinamikus struktúra vizsgálata alapvetoen a folyamatok, vagyis a muködés rögzítését jelenti. A következo lépésekbol áll: ? A tevékenységek rögzítése a tevékenységi jegyzék alapján történhet meg, melyre példát a 1. sz. táblázat mutat, ahol a feladatok szerint történik a tevékenységek csoportosítása. A táblázat úgy épül fel, hogy az elso oszlopban a fo feladatok (folyamatok) szerepelnek, majd minden egyes ilyen megnevezésnek a sorában feltüntetésre kerül, hogy milyen részfeladatokból áll. A sorok és oszlopok száma a vizsgált rendszertol függ. Feladatok, Tevékenységek Folyamatok A A1 A2 A3 B B1 B2 B3 B4 B5 C C1 C2 C3 C4 1. táblázat

Tevékenységi jegyzék

Egy fuvarrendelési feladat (A) egy fuvarozást végzo cég esetében a következo tevékenységek összességét jelentheti: 1. Szállítmányozótól árajánlat kérés. (A1) 2. A beérkezo ajánlatok közül a legmegfelelobb kiválasztása. (A2) 3. A fuvarozási feladat elvégzésének megrendelése a szállítmányozótól. (A3)

? A rendszerbeli résztvevok kapcsolatainak rögzítésére relációmátrixot vagy ún. Információkapcsolati diagramot készíthetünk. Az elobbire példát a 2. sz. táblázat mutat be.

I I II III IV

Összetevok II III IV X X X

X

2. táblázat

Relációmátrix

3


Ez egyben egy honnan-hová mátrix is, ami azt jelenti, hogy a kapcsolat irányultságát úgy követhetjük nyomon, hogy az elso oszlopban feltüntetett összetevok a kapcsolatot képezo információk forráspontjai, míg a második sorban szereplo összetevok a célpontok. Az információkapcsolati diagram elkészítésénél az összetevok szervezeti hierarchiája nem játszik szerepet, mert az ábra bonyolultságát fokozná (1. sz. ábra). A nyilakkal egymáshoz kapcsolt összetevoket egy-egy téglalappal szokás megjelölni, beleírva az elem megnevezését. A nyilakra felírt sorszámokkal lehet a kapcsolatok idobeliségét érzékeltetni, illetve szövegesen megjelölni az információkat vagy a dokumentumok nevét. 2

1

A

B 5

3

C

E

6 7

1. ábra

4

D

Információkapcsolati diagram

Fuvarmegbízás során a fuvarozást kéro cég fuvarszervezoje, a kiválasztott szállítmányozó és az operatív végrehajtást ellátó fuvarozó kapcsolatát ábrázolhatjuk. A mátrixban kapcsolatot kell feltüntetni a fuvarszervezo és a szállítmányozó, valamint a szállítmányozó és a fuvarozó között. A fuvarszervezo nem feltétlenül áll kapcsolatban a fuvarozóval. A kapcsolatok kétirányúak (a mátrix szimmetrikus), mert a megbízási folyamat a megbízások visszaigazolásával zárul le. A kapcsolati diagramban a három téglalap között az elobb leírtaknak megfeleloen kétirányú nyilakat rajzolhatunk.

? Az elozo ábrához képest gyakran áttekinthetobbé kell tenni az idobeliséget. Ezt a célt szolgálja az idokoordinált folyamatábra (2. sz. ábra). A jelzett téglalapokban az elvégzendo információkezelési tevékenységeket lehet feltüntetni. A közéjük elhelyezett nyilak az információátvitelt jelzik, ezek jelöléstechnikai megkülönböztetése (szaggatott, pont-vonal stb.) utalhat az átvitel módjára (telefon, bizonylat, számítógép stb.)

A

b

B

f

2. ábra

e

c

C D

g

a

d

Idokoordinált folyamatábra

4


Az elozo fuvarmegbízási példa esetében ez a következoképpen néz ki (3. sz. ábra):

Fuvarszervezo Szállítmányozó

Visszaigazolás iktatása

Szállítmányozó megbízása Fuvarozó megbízása

Megbízás visszaigazolása Megbízás visszaigazolása

Fuvarozó

3. ábra A fuvarmegbízás idokoordinált folyamatábrája 1. 2. 3. 4. 5.

A fuvarszervezo megbízza a szállítmányozót. A szállítmányozó megbízza a fuvarozót. A fuvarozó visszaigazol a szállítmányozónak. A szállítmányozó visszaigazol a fuvarszervezonek. A fuvarszervezo tudomásul veszi a visszaigazolást.

? Ezt követoen az információellátással kapcsolatos további elemzésre van szükség. Az elektronikus adatcsere szempontjából az információ hordozójául szolgáló bizonylatok vizsgálatát, információtartalmának elemzését jelenti. Az árufuvarozás folyamatában kiterjedten és legtöbb esetben pontos formai és kitöltési eloírásokkal elrendelten alkalmaznak nagyszámú bizonylatot. A felesleges párhuzamosságokra az ún. koincidencia táblázat mutat rá (3. sz. táblázat). Az elso oszlopban a bizonylatok nevei szerepelnek, minden további oszlop fejlécében a bizonylatokon fellelheto teljes információskála jelenik meg. Az egyes információ(adat)-féleséget jelento oszlopban minden olyan bizonylat sorában jelölést kell alkalmazni, amely bizonylaton az illeto adat ténylegesen elofordul. Bizonylat neve A. B. C. D. 3. táblázat

a

b

c

d

e

X X X X X X X X X X Koincidencia táblázat

A fuvarozási megbízás folyamatát tekintve az elkészített táblázat nagy és a cégek közötti kapcsolatoknak megfeleloen különbözo is lehet, mivel általánosan használt formanyomtatvány nem létezik. Ez a táblázat pl. tartalmazza a szállítmányozói és fuvarozói megbízásokat, mint bizonylatokat. Az okmányokon a következo adatok szerepelhetnek: áru neve, tömege, mérete, a fuvaroztató neve, címe stb.

A bizonylatok önálló elemzése (4. sz. táblázat) már kifejezetten az elektronikus adatcsere szemszögébol történik. A Rovatszám (ha van) és a Rovatnév a dokumentumon megtalálható jelöléseket jelenti. Az Információ

5


oszlopában az adott rovatban megtalálható bejegyzés információtartalma szerepel, ennek esetleges részletesebb kifejtésére a Tartalom oszlopban nyílik lehetoség. A Hossz oszlopában a bejegyzés becsült, maximált vagy tényleges hossza szerepel. A Megjegyzés oszlopra a kitöltéssel kapcsolatos egyéb tudnivalók miatt van szükség. Dokumen- Rovats Rovat tumneve zám név A. 1. 2. 3. 4. táblázat

Információ

Tarta- Hossz Kitölto Megjegyzés lom szerv

A dokumentum információtartalmának elemzése

Példaként a szállítmányozói megbízás feladóra vonatkozó egyik rovatának elemzését mutatja az 5. sz. táblázat. Dokumentum neve Szállítmányozói megbízás.

Rovat- Rovatszám név 1.

5. táblázat

Feladó neve

Információ

Tarta-lom

Hossz

Kitölto szerv

Megjegyzés

A feladó neve

Az áru feladójának azonosító adatai közül a neve

Max. 50 karakter

Feladó

Ha eloírás megköveteli, kézírással, bélyegzovel hitelesíteni (aláírni) is kell.

A szállítmányozói megbízás információtartalmának elemzése (részlet)

Az elektronikus adatcsere végso megtervezése a kapcsolatok kiépítése szempontjából lényeges a bizonylatok áramlási útvonalának rögzítése. Ezt legalkalmasabb formában a bizonylatáramlási gráfok (4. sz. ábra) - az idobeliséget is érzékeltetve - a bizonylatáramlási folyamatábrák valósítják meg. Ez utóbbi rendkívül hasonlatos a tevékenységek idokoordinált folyamatábrájához (2. sz. ábra). A gráfon a téglalapokban a szervezeti összetevok nevei szerepelnek, a nyilakon a bizonylatok nevei vagy kódjai. E

1 D

F

1,2 C

6 4

1,3

4

B

4. ábra

4,2

A

7

6,1 7

5 G 6 H

Bizonylatáramlási gráf

6


A fuvarozási megbízásra vetítve ez azt jelenti, hogy a három szervezeti összetevo közül a fuvarszervezo a szállítmányozónak szállítmányozói megbízást ad, a szállítmányozó a fuvarozónak fuvarozói megbízást. Bizonylatok az ellenkezo irányban is mozognak, fuvarozói és szállítmányozói visszaigazolás formájában.

1.1.1.2 Az információs rendszer elemzése Az elozo pontban ismertetett módon lehetséges egy rendszer, egy folyamat rögzítése. Mindezt lépésrol-lépésre kell végrehajtani, hiszen logikai sorrend van közöttük, az elektronikus adatcsere szempontjából leglényegesebbek az utolsó fázisban az információs rendszerre vonatkozó dokumentálások. Gyakorlatilag már ezek során szükség van az információs rendszer elemzésére. Az elektronikus adatátvitel tervezéséhez nélkülözhetetlen, hogy a felesleges párhuzamosságokat, a nem megfelelo információk cseréjét kiküszöböljük. Így egyfajta racionalizálást hajtunk végre, amely alatt az adatszolgáltatás, információkezelés és bizonylati rendszer elemzését kell érteni. 1.2 Az árufuvarozás mint a kereskedelmi folyamat része Az áru fuvarozása annak a kereskedelmi folyamatnak a része (5. sz. ábra), melynek során az áru tulajdonjoga az eladótól az átvevore száll.

5. ábra

A nemzetközi kereskedelmi folyamat

Gyakorta térben és idoben egyaránt nagy utat kell megtennie az árunak, amíg eljut az eloállítás helyétol a végso felhasználóig. Ez az út esetenként ismétlodo kereskedelmi folyamatok eredménye, amelyek kiinduló- és végpontja, valamint kezdeményezoje az eladó és a vevo. A szállítás önmagában még nem jelenti az áru mozgását, csupán a tulajdonjog átruházását. Ebben az értelemben az eladó a szállító,

7


vagyis az a természetes vagy jogi személy, aki a kereskedelmi (szállítási) szerzodésben foglaltaknak megfeleloen, ellenérték fejében lemond az áru tulajdonjogáról a vevo javára. A leggyakrabban a gyártó és a vevo közé beékelodik egy kereskedo cég, aki maga intézkedik az áru mozgásáról. A szállítási szerzodés az eladó és a vevo között jön létre. Az áru helyváltoztatását (elszállítását) végrehajtó személyt áruszállítónak, vagy fuvarozónak nevezzük. Az árut elszállíthatja a termelo vagy a felhasználó is, de rábízhatja a fuvarozókra, s ha összetett a folyamat, akkor a szervezést szállítmányozóval végeztetheti el. 1.3 Az árufuvarozás szereploi és kapcsolataik Az árufuvarozás folyamatában - elszakadva a kereskedelmileg használatos elnevezésektol - az eladó és a vevo helyett a feladó és az átvevo szerepelnek. Gyakran elofordul, hogy az áru gyártója (eladója) nem egyezik meg azzal, aki az árut fuvarozásra elokészíti, majd feladja, és hasonló a helyzet az átvevo oldalán. Általában elmondható, hogy alágazatoktól függetlenül egy fuvarozási folyamat résztvevoi a: ? fuvarozó, ? szállítmányozó, ? feladó, ? átvevo, ? vámhivatal, ? bank. A fuvarozók olyan vállalkozók, akik mások áruját fuvarozzák, fuvarozási szerzodés alapján, fuvardíj ellenében. A fuvarozási szolgáltatást kitermelik, fuvarozási szerzodéssel eladják, és árát a fuvardíjban realizálják. A szállítmányozó általában nem foglalkozik fuvarozással, beépül a fuvarozó és a feladó közé, szakértelmével, ügyességével összehangolja a fuvarozók és a fuvaroztatók érdekeit, így mindkét fél számára megtakarítást tud biztosítani. Saját nevében megbízója árujára és költségére megköti a fuvarozási szerzodéseket, a szállítmányozási (bizományosi) szerzodés (megbízás) alapján, szállítmányozói jutalék ellenében. A fuvarozónak állandó, rendszeres nagy mennyiségre szóló megbízója. Így számíthat arra, hogy állandó vevoként fuvardíjkedvezményeket, visszatérítéseket kap. Ezért érdemes a feladóknak szállítmányozóval megköttetni a fuvarozási szerzodéseket, mert a mennyiségi kedvezményeket egy-egy áru után ok nem tudnák megszerezni. Szállítmányozót tehát rendszerint akkor érdemes igénybe venni, ha a fuvarozási feladathoz szükség van szakértelmére és/vagy fuvardíjmegtakarítást tud biztosítani.

8


A feladó átadja a fuvarozáshoz az árut, az átvevo átveszi a fuvarozótól az árut. Tehát az áru fuvarozását érinto helyváltoztatásának a kiinduló és célpontja. A feladó és/vagy az átvevo az áru elfuvarozásának a megrendeloje, vagyis az áru helyváltoztatásának a kezdeményezoje. Az árut közvetlenül feladhatja és átveheti valamilyen raktározási feladatokat ellátó személy vagy szervezet. A vámhivatal szerepe a nemzetközi ügyletek során jelentkezik az export és import forgalomban eltéro feladatokkal. Minden, az országba érkezo árut vámeljárás alá vetnek, kivitelkor pedig vámpapírokkal látják el azokat. Tranzitforgalom esetén az árufuvarozás módjának megfeleloen vámellenorzést végeznek vagy vámeljárást folytatnak le. Az elobbi az ún. TIR forgalomra vonatkozik, amikor a jármu meghatározott módon, lezárva közlekedik, ekkor a lezártság sértetlenségét ellenorzik. Gyakran a feladó és az átvevo megbízásából ún. vámügynök tartja a kapcsolatot a vámhivatallal. A pénzügyi mozgások biztonságos végrehajtását a bankok biztosítják, az átutalási megbízásokat teljesítik, számlatulajdonosaiknak elküldik a jóváírási értesítéseket. A gyakorlatban sokszor több azonos feladatkörrel rendelkezo szereplo - így például több bank vagy fuvarozó - vesz részt a folyamatban. Ez azonban a kapcsolatok jellegén, az információ típusán nem változtat, újabb információk nem lépnek fel a folyamatban. 1.4 Az árufuvarozáshoz kapcsolódó tevékenységei Nem célunk a fuvarozásban résztvevo felek tevékenységeinek részletes bemutatása, így erre itt nem kerül sor. Mindezt a megfelelo tananyagok, szakmai kiadványok részletesen tartalmazzák. Lényegesek azonban a résztvevokhöz és tevékenységeikhez kötodo információs folyamatok, különös tekintettel azokra az okmányokra (adatokra), amelyek a korábbiak alapján alapveto fontosságúak az információs folyamatra nézve. Így egy már elkészített árufuvarozási elemzés következtetései alapján kifejezetten az EDI alkalmazását figyelembe véve történik a tevékenységek bemutatása. Az árufuvarozás folyamata 6 tevékenységi blokkra bontható, a fontos tevékenységbizonylat párokat kiemelve ezek a következok: 1. A fuvarozó elozetes felkészülése a fuvarozási tevékenységre Gyakorlatilag nem találkozunk nagy távolságot, gyors adatátvitelt igénylo információcserével és ehhez kapcsolódó okmányokkal. A fuvarozáshoz szükséges engedélyek és egyéb nagy idotávlatban érvényes dokumentumok beszerzése a fuvarozó feladata.

9


2. A fuvarozáshoz szükséges szerzodések elokészítése, megkötése A megbízási szerzodések megkötése kulcsfontosságú lehet egy késobbi EDI alkalmazás szempontjából, mivel számos olyan információt tartalmaz, amelyek a késobbiekben más dokumentumokon is (pl. fuvarlevél) megjelennek. 3. A fuvarozás elokészítése közvetlenül az áru helyváltoztatása elott Ezen tevékenységek sorába tartoznak az árufuvarozáshoz elengedhetetlen okmányok kitöltése - fuvarlevél, vámkezelési okmányok stb.-, az áru és a jármu felkészítése a fuvarozásra. 4. Az áru helyváltoztatásával kapcsolatos tevékenységek Az áru mozgás közbeni helyzetérol, ha kívánják a résztvevok a fuvarozónak folyamatos tájékoztatást kell adnia, ami általában erre alkalmas telekommunikációs eszköz segítségével történik (nem számítógépen és nincs feltétlenül papírhoz kötve). A közbenso országok vámszervei ekkor végzik el a szükséges vámellenorzéseket, -eljárásokat. 5. Közvetlenül az áru helyváltoztatása utáni feladatok Nemzetközi árufuvarozás esetében legtöbbször ekkor történik az áru vámkezelése (vámkezelési okmány). A fuvarlevél is ekkor kerül a végso felhasználókhoz, adott esetben ekkor rögzítenek néhány kiszolgáltatással kapcsolatos információt. 6. Számlázás és fizetés A kereskedelmi ügyletnek a fuvarozási szerzodéseknek megfeleloen ekkor történik a pénzügyi igénylések kielégítése, melynek elso fázisa a számlák benyújtása azoknak, akik fizetésre kötelezettek. Megfigyelheto tehát a tevékenységeknek egy olyan köre, ahol az információhordozó tradicionálisan valamilyen papíralapú okmány. Ilyen tevékenységi kör például az áru fuvarozásra történo átvétele, szállítása és kiszolgáltatása, a vámolás vagy a munka ellenértékének követelése. Az említett tevékenységekhez kapcsolódó adatok hosszú ido óta papírra írt formában jutnak el az egyik féltol a másikig. Az információs rendszer elemei között bármilyen fontossági sorrend felállítása nélkül, elmondható, hogy ezek a papíralapú okmányok (fuvarlevél, vámkezelési okmány, számla) néhány más okmánnyal együtt alapvetok a fuvarozáshoz kapcsolódó információs folyamatban. 1.5 Az árufuvarozás folyamata A feladó árujának elfuvarozásához szállítmányozót keres, választását pénzügyi és tradicionális szempontok befolyásolják. E ketto elég szoros kapcsolatban van, hiszen, ha valaki hosszú távú megbízója a szállítmányozónak, akkor

10


kedvezményeket élvez. A szállítmányozó döntését ugyanezen ismérvek határozzák meg a megfelelo fuvarozó kiválasztása során, figyelembe véve az áru sajátosságait (veszélyes, gyorsan romló áru stb.), melyekhez speciális fuvarozási mód vagy eszköz szükséges. Ezek az ajánlatkérések leggyakrabban telefonon (szóban), telefaxon esetleg levél (írásos) formájában történik. Szabványos dokumentumformátum nincs, minden cég a saját gyakorlatának megfeleloen alakítja ki. A válaszadás hasonló módon történik, mint az ajánlatkérés. Az ajánlatok közül a szállítmányozó és a feladó kiválasztja a számára legkedvezobbet és megbízza fuvarozói megbízás és szállítmányozói megbízás keretében. Ezek a megbízások már papírhoz kötöttek, tulajdonképpen szerzodésnek minosülnek. A fuvarozónak rendelkeznie kell mindazon jogosítványokkal, engedélyekkel, amelyek a fuvarozási feladathoz szükségesek. Általában ezeket már a megbízás elott beszerzi, de legkésobb az áru helyváltoztatásának megkezdéséig a birtokában kell lennie. A feladónak kell biztosítania az áru fuvarozásához szükséges engedélyeket (pl. veszélyes áru). Ezt követi a fuvarozás elokészítése, az áru felkészítése a helyváltoztatásra (csomagolás stb.), az áru vámolása (nemzetközi árufuvarozás esetén), az áru fuvareszközbe rakása valamint a feladat elvégzéséhez szükséges okmányok összeállítása. Ennek során számos a szállítási eszköztol, a szállítási módtól és az áru fajtájától függoen különbözo feladatok jelentkezhetnek. Közös feladatként a fuvarlevél és a vámkezelési okmányok kitöltése szerepel, melyek közül az elobbi alágazatonként külön-külön szabványosított, míg az utóbbi teljesen egységes bizonylat. Mivel nemzetközi dokumentumokról van szó az adatok elrendezése is szabványos az alágazatoktól függetlenül. Az áru fuvareszközbe történo berakását követoen megkezdodik annak helyváltoztatása. Ennek során a fuvarozó tájékoztatását általában telefonon keresztül küldi el az áru helyzetérol. A kapcsolatfelvétel tehát élo szóban történik, az információt a szállítmányozó és a feladó is megkapja. Amennyiben több ország érintésével történik az áru fuvarozása a közbenso országok vámszervei a fuvarozási módtól függoen vámellenorzést (TIR egyezmény szerint) végeznek vagy vámeljárást folytatnak le. Az áru megérkezése elott az átvevo értesítést kap az áru várható átvételérol, szintén telefonon. Azért lényeges ez az elojelzés, hogy az átvevo fel tudjon készülni az áru átvételére és a vámszervekkel - esetleg vámügynökével felvegye a kapcsolatot a mielobbi vámeljárás lefolytatása érdekében. Az áru megérkezését követoen megtörténik a vámolás a célország vámjogszabályai szerint. Az árut az átvevonek kiszolgáltatják és rendelkezhet felette. Az árufuvarozást végigkíséro okmányokra (pl. fuvarlevél) felvezetik az átvételt és az arra jogosultak ezen dokumentumok közül kapnak egy-egy példányt.

11


Alágazatoktól, szállítási módtól és szerzodéstol függoen a számlák megküldése és kifizetése az árufuvarozás különbözo fázisában történhet meg. A konkrét helyváltoztatás elott megkötött szerzodések tartalmazzák azt, hogy a fuvarozás során ki, milyen mértékig viseli a költségeket, valamint, hogy ki, milyen mértékig felelos. Legtöbb esetben a pénzügyi mozgások a fuvarfeladat teljesítését követoen realizálódnak, melynek közege banki muvelet. A költségviselok elküldik átutalási megbízásaikat a bank(ok)nak, a bank(ok) pedig a jóváírási értesítést számlatulajdonosaiknak. Az áruszállítási folyamat során az árunak gyakran nagy utat kell megtennie, amíg eljut a feladótól az átvevoig. Ezalatt a fuvarozásban érintett felek számos dokumentumot töltenek ki és juttatnak el egymáshoz. A fuvarozási tevékenység tehát rendszerint térben kiterjedt, sok szereplos folyamatot feltételez. Ennek megfeleloen a tevékenységekhez kapcsolódó információs folyamatok is egymástól távol eso partnerek információs kapcsolatait jelenti. A partnerek közötti információcsere hordozója napjainkban rendszerint valamilyen papíralapú okmány. Természetesen számos esetben a partnerek telefonon, faxon, esetleg valamilyen más elektronikus hordozó segítségével adják meg egymásnak a fuvarozási feladat lebonyolításához szükséges információkat. Az árufuvarozás során használatos dokumentumokat a vonatkozó eloírások alapján három csoportba sorolhatjuk: 1. Nemzetközi egyezmény által szabályozott dokumentumok (pl. fuvarlevél, TIR igazolvány). 2. A nemzetközi árufuvarozásban használatos (nélkülözhetetlen) okmányok, melyek használatát nemzetközi egyezmény nem írja elo (pl. kereskedelmi számla, rakományjegyzék). 3. Az egyes országok sajátosságainak, az alkalmazott gyakorlatnak megfeleloen változó bizonylatok, melyek megjelenésére, adattartalmára vonatkozó eloírás nincs (pl. az ajánlatkérések, megbízások, visszaigazolások). A papírdokumentumok egy része az árufuvarozási folyamat egy rövidebb egységében használatosak, egy másik része gyakorlatilag végigkíséri az árut a helyváltoztatás során. Az utóbbiak általában a folyamat több résztvevoje számára tartalmaznak hasznos információkat, a kitöltés is több helyen történhet. 1.6 Kulcsszerepet betölto okmányok és funkcióik Látható, hogy az egyes okmányok különbözo tevékenységekhez kapcsolódnak. Egy okmány funkcióján a továbbiakban az adott okmányhoz kapcsolódó, az általa

12


rendes körülmények között eloidézett/eloidézendo tevékenységet vagy tevékenységek sorozatát értjük, valamint azokat a jogokat és kötelezettségeket, amelyek az okmány birtokosát illetik, illetve terhelik. Az okmányok funkcióinak (felül)vizsgálata fontos gyakorlati kérdéshez, az üzleti és információs folyamatok át-/újraszervezésének (process reengineering) kérdéséhez kapcsolódik. Az elozo fejezetben felsorolt tevékenységeket alapul véve, funkcióik alapján a megbízási szerzodés, a fuvarlevél, a vámkezelési okmány és a kereskedelmi számla kiemelheto a fuvarozási okmányok közül, mert döntoen meghatározzák a fuvarozási tevékenységet, illetve - információs szempontból - adattartalmuk a fuvarozási tevékenység lebonyolításához szükséges adatok dönto többségét lefedik. Ez utóbbi két szempont különösen fontos abban az esetben, amikor az a kérdés merül fel, hogy mely papíralapú okmányt indokolt elektronikus üzenettel kiváltani. A megbízási szerzodés (a neve alapján is) a felek közötti megállapodás, ami szabályozza a felek együttmuködését. A feladó szállítmányozói szerzodést köt a szállítmányozóval, a szállítmányozó fuvarozói szerzodést köt a fuvarozóval. Tartalmazzák mindazokat az információkat, amelyek az áru fuvarozásához elengedhetetlenek (az áru fajtája, súlya, neme, szállítási határido stb.) Nincs szabványosított formája, a rajta szereplo adatok körét is a megbízó, ritkán a megbízott határozza meg. Más dokumentumok, okmányok ezen szerzodések adatai alapján készülnek el. A fuvarlevél alágazatonként szabványosított formával rendelkezik. A nemzetközi eloírásoknak köszönhetoen a struktúrája, az adatok elhelyezkedése alágazatfüggetlenül egységes. Itt kell utalni azokra a nemzetközi törekvésekre, mely szerint a nemzetközi árufuvarozásban használatos bizonylatok, okmányok esetében azok szerkezeti kialakítása egységes legyen. Ez azt jelenti, hogy ugyanazok az adatok a nyomtatványnak ugyanazon részén találhatók meg, és egyes rovatoknál szabványos formában (pl. kódok). A fuvarlevél az árufuvarozás alapdokumentumának tekintheto, végigkíséri az áru helyváltoztatását. Többpéldányos dokumentum, melyek mindegyikének külön funkciója van (számlakészítés alapja, vámpéldány stb.). Fo funkciójának tekintheto, hogy az árufuvarozási folyamat valamennyi résztvevoje kiolvashassa belole azokat az információkat, amelyek az árunak az átvevohöz történo eljuttatásában útmutatásokat tartalmaznak. Ezen túlmenoen a fuvarlevélre a résztvevok felvezethetik azokat az adatokat, megjegyzéseket, amelyeket nemzetközi egyezmény biztosít a számukra. A vámkezelési okmánynak a nemzetközi forgalomban használatos EV (Egységes Vámárunyilatkozat) minosül. Ez alágazatfüggetlenül egységes, szabványos formai

13


kialakítású. Az EV nyolcpéldányos nyomtatvány, amelybol a forgalom iránya (behozatal, kivitel, árutovábbítás, raktározás) alapján különbözo vámkezelésekhez különbözo számú példányra van szükség. Export áruszállítás során az indító vámhivatal, a kilépteto vámhivatal és a vámkezelést kéro (a feladó vagy exportor) kap a példányokból. Árubehozatal kapcsán az EV példányok közül a vámkezelést végzo vámhivatalnak, a vámkezelést kéronek és a vámfizetésre kötelezettnek (ez utóbbi ketto lehet ugyanaz a szerv vagy személy) jut egy-egy. Tranzitforgalomban történo vámolás esetében a belépteto vámhivatal, a kilépteto vámhivatal és a vámkezelést kéro jogosult a példányra, valamint egy példányt (igazolásként) küld a kilépteto vámhivatal a beléptetonek. A számlák a pénzügyi mozgások beindításához szükségesek. A szolgáltatások ellenértékét a költségviseloknek ki kell fizetniük. Nincs eloírás a számlák kialakítására nemzetközi, nemzeti szinten, azonban a rajta szereplo információk köre szabályozott. Az adóhatóságok a számlák számos fajtáját elfogadják a kifizetés kezdeményezésére.

14


2 Az elektronikus üzleti kommunikáció és az EDI Az elozo fejezet bemutatta azt a nagyszámú papírdokumentumot használó és sokrétu folyamatot, melyet nemzetközi árufuvarozásnak hívunk. Az információk (a bizonylatok) átadása a folyamat résztvevoi között történhet szóban (pl. telefonon), telefaxon, küldönc segítségével (pl. posta), számítógépes rendszerek közötti kommunikáció útján (mágneslemes, e-mail, EDI - Electronic Data Interchange). Ezen kommunikációk ölthetnek strukturált és strukturálatlan formát. Az elobbi lényege hogy valamilyen szabványos formában történik az adatátvitel (pl. szabványosított urlap). A szóbeli kommunikáció a strukturálatlan kommunikáció egyik lehetséges módja, de telefaxon vagy postai úton (pl. levél) is küldhetünk ilyen üzeneteket, ugyanakkor nemzetközileg elfogadott - vagy valamilyen egyezmény által szabályozott - dokumentumformát használva már strukturált formát ölt a résztvevok közötti kapcsolat. Az elektronikus kommunikációs lehetoségek közül az e-mail strukturálatlan, az EDI strukturállt üzenetváltást jelent, a mágneslemes - vagy bármilyen más lehetséges adathordozó - tartalmazhatja mindkét formáját az üzeneteknek. Ez utóbbi esetében az üzenetváltás sebessége lényegesen lassabb, mint a számítógépek közötti hálózati kapcsolat esetében. A kommunikációs módok elterjedése azt mutatja, hogy az információcsere leghatékonyabb hordozójának a papír mutatkozott. Annak ellenére, hogy az elmúlt két évtized során sok cég saját automatizált információrendszert alakított ki, a folyamatok résztvevoi között áramló információ igen nagy mennyisége még ma is papíron mozog. A nemzetközi árufuvarozás szereploinek mindegyike rendelkezik számítógéppel, melyek összekapcsolása manapság a távközlési infrastruktúrának köszönhetoen nem probléma. Errol a szintrol minoségi továbblépést jelent, ha nem csak a hardverek, hanem a szoftverek is összekapcsolhatók. A számítógépes programok emberi közremuködés nélkül automatikusan is képesek elintézni olyan muveleteket, mint az ajánlatkérés, a számlázás stb. Nem elegendo két (vagy néhány) partner közötti megállapodást rögzíteni az adat- és üzenetformátumokra, hiszen nemzetközi viszonylatokban a folyamatok résztvevoinek száma rohamosan növekszik így a különbözo nyelvek használatából is probléma adódik. Újabb és újabb partner esetén azok informatikai rendszerét hozzáigazítani a kialakított rendszerhez rendkívül költséges. Ezért van szükség egy nemzetközileg elfogadott szabvány (pl. ENSZ-EDIFACT - United Nations Electronic Data Interchange for Administration, Commerce and Transport - Az Egyesült Nemzetek ajánlása igazgatási, kereskedelmi és szállítási adatok elektronikus cseréjére) alapján történo elektronikus kommunikációra, az EDI-re. Definíció szerint az EDI elore meghatározott, strukturált, szabvány szerinti üzenetek számítógépes alkalmazások közötti elektronikus átvitele, mely nélkülözi az emberi

15


beavatkozást. Egy másik definíció szerint EDI-nek nevezzük azt a kommunikációt, ahol a partnereknél futó számítógépes alkalmazások elektronikus úton, emberi beavatkozás nélkül (rendszerint valamilyen szabvány szerint) strukturált formában juttatják el az adatokat egymáshoz. A definíciókban megfogalmazottak jelentéstartalma: az adatok strukturálása Az EDI legfontosabb kritériuma, hogy elore meghatározott adatok, elore meghatározott normák szerint tagolva érkezzenek a címzetthez. Ez biztosítja az automatikus feldolgozás lehetoségét, az adatok beépülését az ügyviteli, illetve termelésirányítási rendszerekbe. egyezményes szabványok Alapfeltétel, hogy az adatstruktúra (adattartalom és -tagolás) valamennyi fél számára értheto legyen. Az EDIFACT szabvány ezt lehetové teszi, így az a cél, hogy minél többen használják ezt a legátfogóbb és legelfogadottabb normát. elektronikus átvitel A papírdokumentumoknak postai úton történo küldése helyett a feladó és a címzett az információ átvitelére elektronikus hordozót választ. Az elektronikus átvitel kritériuma, hogy az átvitt adatok az átvitel kezdetén és végén lényeges közbülso emberi beavatkozás nélkül elektronikus jelek formájában jelenjenek meg. számítógéptol számítógépig A strukturált formában szolgáltatott adatokat a számítógép emberi beavatkozás nélkül képes fogadni és feldolgozni. Ha csupán elektronikus okmánycserérol beszélnénk, az okmányokon szereplo adatokat újra gépre kellene vinni, hogy a címzett automatizált információs rendszere képes legyen feldolgozni oket. Így számítógépes alkalmazások közötti kommunikációról beszélhetünk. A definíció alapján tehát alapveto különbség van az EDI és például az elektronikus levelezés (e-mail) vagy a fax között. Az utóbbiak esetében az adatok valamilyen szabad szöveges formában szerepelnek, feldolgozásukhoz valakinek el kell olvasni oket, hogy az információ értelmezheto legyen és az értelmezés eredményeként valamilyen folyamatot el lehessen indítani. Technikai oldalról tekintve egy EDI-rendszer telepítése elott egy vállalatnak három fo területre kell koncentrálnia: ? kommunikáció, ? EDI-szoftver és -hardver,

16


? házi rendszer módosítása. A kommunikációt illetoen a meglévo távközlési kapcsolatok, szoftver- és hardver eszközök használhatók az EDI kommunikációhoz is. Ugyanakkor elofordulhat, hogy a megnövekedo távközlési igények bovítést feltételeznek, vagy egy új távközlési rendszer szolgálja ki az EDI-alapú kommunikációt (esetleg a nem EDI-alapú kommunikációt is). Alkalmazótól függoen felmerülhet az igény értéknövelo hálózati szolgáltatások iránt. Az EDI bevezetésével meg kell vizsgálni a külso és a belso kommunikációs igényeket. Nem kerülheto el az EDI-kapcsolatot biztosító szoftver beszerzése és a szükséges szoftverfejlesztések elvégzése. A legfobb igények a szoftver oldalon jelennek meg az EDI kapcsán, mivel különféle funkciók kellenek egy muködoképes megoldáshoz. A legfontosabbak elokészítik és továbbadják az üzeneteket a külso kommunikációhoz, illetve a belso alkalmazásokhoz, és a konverziót is elvégzik a ketto között. Továbbá fontosak a monitoring (felügyelo) funkciók, melyek minoségileg és a biztonság fokozásával járulnak hozzá az EDI muködéséhez. Manapság szoftvercsomagok az EDI-szolgáltatás funkcióinak különbözo kombinációit kínálják PC-kre, miniszámítógépekre. A legfontosabb jellemzoje az EDI szoftvernek, hogy rendelkezik egy interfésszel, mely teljesen független attól az alkalmazástól, amely létrehozza az EDI számára, vagy kapja az EDI-tol az adatokat. Ez az interfész az EDI-szolgáltatás bevezetésekor lehetové teszi, hogy a már meglévo számítógépes alkalmazások változtatása minimális legyen, és így a szoftver képes kiszolgálni a különbözo alkalmazásokat. Késobb az alkalmazások esetleges módosításakor az EDI-szoftver funkcióira pedig nem lesz hatással. Egyre több olyan szoftvert lehet vásárolni, melyben már benne van az EDI interfész, mégis inkább a cégek maguk (akár megrendelés útján) fejlesztik ki. A 6. sz. ábrát alapul véve vázolható, milyen szabványelemek szükségesek egy EDIalkalmazás muködtetéséhez. Fontos megjegyezni, hogy az alábbi ábra vázlatos, a teljesség igénye nélkül készült, ugyanakkor jó áttekintést nyújt az egyes szabványelemek elhelyezkedésérol, elválasztva egymástól a gyakran keveredo fogalmakat. Az elektronikus adatcsere alkalmazása érdekében a cégek informatikai rendszeréhez tartozó szoftvereket ki kell egészíteni, hogy a házi formátumú dokumentumokból egy közbülso formájú dokumentumot állítson elo, amely az EDI alrendszerben kerül felhasználásra. Az EDI-szolgáltatás kimenetén már EDI formátumú üzenet jelenik meg, amely a kommunikációs protokollnak megfeleloen kerülnek továbbításra. A hálózati szolgáltatás az EDI formátumú üzeneteket kiegészíti olyan utasításokkal, amelyeket a konkrét számítógépes hálózat igényel. A számítógéphálózat másik oldalán lévo csomópontba megérkezo EDI formátumú

17


üzeneteket az EDI-szolgáltatás és környezeti architektúrája átalakítja az ezen csomópontban eloírt házi formátumra. Az EDI-szolgáltatás a megfelelo üzenetformátum átalakításon és eloállításon kívül az elektronikus adatcsere biztonságáról is gondoskodik. A továbbiakban áttekintjük az ábra egyes elemeit, kiemelve és részletesen tárgyalva az EDIFACT-szabványrendszert. A lka l m a z á s

A lka l m a z á s

E D I-s z o l g á l t a t á s

E D I-s z o lg á lta t á s

K o m m u n ikációs p rotokoll

K o m m u n iká c i ó s p r o t o k o ll

H á lózati szolgáltatások

H á lózati szolgáltatások

H á ló z a t

6. ábra

Az EDI-alkalmazásának elemei

Szemléltetésként bemutatjuk a fax alapú (7. sz. ábra) és az elektronikus adatcsere útján (8. sz. ábra) történo információátadást. Kereskedelmi alrendszer

Teljesített szállítások

Számla faxformátum létrehozása

Fax

SZÁLLÍTÓ Telefonhálózat

MEGRENDELO

Logisztikai alrendszer

7. ábra

Bevitel

Számlák

Fax

Fax alapú információtovábbítás

Ehhez képest a tipikus magyar megoldás, az intelligens EDI-fax esetét. Ekkor bevezetik az EDI-t, de az integrálást elmulasztják. Az EDI-kapcsolat megvan, de a

18


manuális muveletek is megmaradnak. Ez a leheto legrosszabb megoldás, ennél még az is jobb ha az EDI-t nem vezetik be. Mert ez egy olyan negatív lökést adhat az egész projektnek, hogy valaki, aki amúgy sem ismeri az EDI-t, és negatív fenntartásai vannak vele kapcsolatban, ezek után bizonyítva látja az eredeti fenntartásait. Kereskedelmi alrendszer

EDI alrendszer

Számlának megfelelo EDI üzenetek

SZÁLLÍTÓ

Értéknövelt hálózati szolgáltató

MEGRENDELO

EDI alrendszer

Logisztikai alrendszer

8. ábra

EDI alapú információtovábbítás

2.1 Az elektronikus kommunikáció kialakulása Az elektronikus kommunikáció kialakulását alapjaiban határozta meg a kapcsolódó infrastruktúra (adatátviteli eszközök, számítógépek stb.) fejlodése. Ugyanakkor nagy jelentoséggel bírtak azok a törekvések, melyek az ügymenetek, különbözo eljárások egyszerusítése, ésszerusítése irányába hatottak. Ezért egészen a kereskedelemkönnyítés gyökeréig kell visszamenni, ha az EDI kialakulásának kezdeteit keressük. A kereskedelemkönnyítés fogalma az információáramlás javítására irányuló szándékot jelenti függetlenül attól, hogy az információ papíron vagy elektronikus hordozón jelenik-e meg. Kezdetben ez a papírmunka csökkentését és egyszerusítését jelentette, elsosorban az export dokumentumokra vonatkozóan. A kezdeti lépéseket 1953-ban tették meg az északi országok, de hamarosan belátták, hogy ennek a tevékenységnek nemzetközi keretekben kell történnie, hiszen csak úgy lehet hatékony ez a munka, ha nemzetközi és ágazatközi szinten zajlik, és ha mind a hivatalos szervek, mind az érintett nemzetközi szervezetek együttmuködnek. Így az EGB kínálkozott az európai kereskedelemkönnyíto munka legmegfelelobb színteréül, mely célul tuzte ki a formalitások minimalizálását és az eljárások

19


egyszerusítését, valamint az okmányok és az információk harmonizálását és szabványosítását. Az EGB 1960-ban úgy döntött, hogy szakértoi csoportot hoz létre annak vizsgálatára, mely exportdokumentumok egyszerusíthetok és szabványosíthatók. 1963-ban megállapodás született egy olyan okmányformátumról, amely az alapja lehet egy szabványos, egységes külkereskedelmi okmánysorozat kialakításának. A világban ma használt nemzetközi kereskedelmi okmányok legtöbbjét az Egyesült Nemzetek által ajánlott ún. „elrendezési séma” (UNLK - United Nations Layout Key) alapján állították össze. Ez a szabványosítás lehetové teszi, hogy az okmányok kitöltése racionális módszerekkel történjék, olyan módon, hogy az információt csak egyszer kelljen rágépelni a teljes exportdokumentációra. Így például a nemzetközi fuvarlevelek (minden alágazat esetében), a nemzetközileg használatos vámokmányok (EV - Egységes Vámárunyilatkozat) stb. ugyanazon jelentéssel bíró adatcsoportjai (pl. feladó adatai) a formanyomtatványoknak ugyanazon pozíciójában találhatók meg. Az egységes okmánysorozat célja, hogy a leheto legtöbb dokumentum ugyanolyan méretu legyen, az azonos információelemek minden nyomtatványon ugyanazon a helyen álljanak. A nyomtatványok feldolgozása és kitöltése egyszeru a több nyelvu környezetben dolgozók számára is. Ezáltal lehetové vált a nyomtatványok összetuzése több részes „indigós” garnitúrává, amelyre a közös információt csak egyszer kell rágépelni. A nyomtatványok szétválasztása után a szükséges egyedi adatokat külön lehet felírni. Másik módszer a dokumentumok együttes kezelésére egy „törzsdokumentum” fénymásolása a kitöltendo dokumentumra a nem kívánt részek maszkolásával (eltakarításával). További lehetoség az okmányok szoftveres úton történo elkészítése. Függetlenül attól, hogy az egységes dokumentumot szoftverrel készítik-e el, vagy fáradtságosan, írógéppel töltik-e ki, a dokumentum könnyebb feldolgozhatóságából elonye származik a nemzetközi fuvarozási lánc valamennyi résztvevojének. Az egységes rendszer csökkenti a hibákat, hiszen egyetlen muvelettel egyetlen okmány készül, és nincs szükség arra, hogy ugyanazt az információt több nyomtatványon is ellenorizni kelljen, a költségek is csökkennek. A kereskedelemkönnyíto tevékenységet 1971-ben átszervezték, és létrehozták a Nemzetközi Kereskedelmi Eljárásokat Könnyíto Munkacsoport-ot (ECE/TRADE/WP.4 vagy WP.4). A munkacsoport nemsokára felismerte, hogy az okmányok csak a jéghegy csúcsát jelentik, az igazi problémák az adminisztratív és üzleti eljárásokban rejlenek. A munkacsoport ezért a következo két területre összpontosította tevékenységét:

20


1. A nemzetközi kereskedelem résztvevoinek információs igényében testet ölto

kereskedelmi „formalitások” és eljárások elemzése (függetlenül attól, hogy ezek jogi, adminisztratív, üzleti vagy üzemeltetési jelleguek-e). 2. A

hagyományos papírdokumentumokat helyettesíteni képes kereskedelmi információátviteli módszerek (számítógépes feldolgozás és adatátvitel) fejlesztése.

Jelenleg két szakértocsoport (a GE.1 - Experts on Data Elements and Automatic Data Interchange - Az Adatelemeknek és az Automatikus Adatcserének a Szakértoi Csoportja; a GE.2 - Experts on Procedures and Documentation - Az Eljárások és az Okmányok Szakértoi Csoportja) dolgozik a kereskedelemkönnyítés e két vonatkozásán. A szakértoi csoportokban folyó munka alapján könnyítési ügyekrol szóló ajánlásokat tesznek. Ezek vonatkozhatnak: az eljárások és a papírmunka egyszerusítésére, szabványos kódok létrehozására, a papírdokumentumok megszunése okozta jogi problémák megoldására stb. Mivel az ajánlásokat szoros együttmuködésben dolgozzák ki azokkal, akik helyzetüknél fogva meg is valósítják oket, ezért ezek az ajánlások gyakran minden további nélkül átültethetok a gyakorlatba. A munkák eredményeként a nyolcvanas évek közepére több országban széles körben elterjedt az egységes okmányok használata, a szabályozott eljárások alkalmazása. A legígéretesebb lehetoségek csak akkor bontakoztak ki, amikor a törzsdokumentumot és ennek fénymásolatait használó rendszerek lassacskán kezdtek kivonulni az irodákból, és átadták a helyüket a számítógépes exportdokumentációs rendszereknek. Ekkorra már az elektronikus adatcsere kezdeményeivel is találkozhattunk. Az ENSZ által ajánlott elrendezési sémával kapcsolatos munka egyik melléktermékeként a WP.4 felismerte az adatelemek (pl. a személy neve) szabványosításának és a szabványos kódok kidolgozásának fontosságát. A szabványos adatelemek lehetové teszik, hogy az információt az egyik nyomtatványról a másikra lehessen másolni úgy, hogy ott is többé-kevésbé ugyanazt a jelentést hordozza, és beleférjen a neki szánt rovatba. Ezenkívül a kódolt adatelemeket az egész világon egységes módon lehet értelmezni. (Mindenki ugyanazt a kódot használja, de amikor a kód jelentését szeretné megtudni, már a saját anyanyelvére lefordított meghatározást olvashatja.) Így született meg az Egyesült Nemzetek kereskedelmi adatelemtára (UNTDED United Nations Trade Data Element Directory), amely tartalmazza a szabványos adatelemeket, a hozzájuk tartozó kódlistákat és a vonatkozó ajánlásokat.

21


Mindezek során az információk strukturáltságát a kereskedelemkönnyítési munka megalapozta, fogalma a következoképpen határozható meg: A szervezetek által saját szervezeti körükben végzett áru- és szolgáltatáscsere segítése annak révén, hogy egyszerusítik, ésszerusítik, és ahol lehet megszüntetik azokat az eljárásokat, amelyek akár elektronikus, akár papírhordozón - adatok gyujtését, feltüntetését és feldolgozását igénylik. Ez alapján a papír vagy az EDI használata között elvileg nincs különbség, hiszen mindketto hordozója annak az információáramlásnak, amely lehetové teszi, hogy a partnerek lebonyolítsák ügyleteiket. Az EDI-rendszerekben azonban a papírdokumentumokat, illetve a kinyomtatott adatokat csak az információ vizuális, emberi áttekintésére használják. A papírbizonylatokat nem használják az információ átvitelére, és az információfeldolgozási funkciók legtöbbje számítógépesítve van vagy lehet. A technikai fejlodés révén a papíralapú rendszerek mellett megjelentek az elektronikus adathordozók, majd késobb a távközlési hálózaton továbbított információk. Az elso elektronikus üzenetkezelo rendszerek az idoosztásos számítógéphasználók közötti kapcsolattartást tették lehetové az 1970-es években. Az E-mail hamar elterjedt, azonban a megfelelo szabványosítás hiánya nehezítette a különbözo gyártók rendszerei közötti üzenetváltást. Az elektronikus üzenorendszerek fejlodésének fo hajtóeroi többek között a tudományos és az üzleti élet globalizálódása, a megnövekedett igény az információ szétosztására, valamint a gyorsabb és megbízhatóbb üzenetváltásra, továbbá a korszerubb kommunikációs szolgáltatások egyre bovülo lehetosége. A 80-as évek elején nagy erovel indult meg a szabványosítás abból a célból, hogy az új kapcsolattartási módszer egységes távközlési szolgáltatásként az egész világon elterjedhessen. A korszeru elektronikus üzenetkezelo rendszerek szabványainak elso változata, a CCITT X.400-as ajánlatsorozata (MHS - Message Handling Systems) 1984-re jött létre és azóta is töretlenül fejlodik. Az X.400-as üzenetkezelo rendszerek célja egy olyan nemzetközileg elfogadott szabványrendszeren alapuló üzenoinfrastruktúra kialakítása, amely a különféle rendszerek összekapcsolása révén nemcsak a személyközi levelezést szolgálja, hanem sokféle jelenlegi és jövobeli alkalmazás befogadására is alkalmas. Már az 1984-es változatban is nyilvánvaló volt, hogy a személyközi üzenetközvetítés (IPM - Inter Personal Messaging) csak az elso alkalmazás, amelyet az 1988-as fejlesztésnél már az elektronikus adatcsere szabványosítása követett.

22


Az üzenetkezelo rendszereknek az alábbi fajtáival találkozhatunk: ? a személyközi üzenés (IPM), amely emlékeztetok, okmányok, levelek, dokumentumok stb. közvetítését teszi lehetové (elsosorban természetes) személyek között; ? az elektronikus adatcsere (EDI), amely szabványos adatelemekbol összeállított szabványos formátumú dokumentumok (urlapok) számítógépes alkalmazások közötti cseréjét teszi lehetové a közigazgatás, a kereskedelem, a szállítás, az automatizált gyártás, a pénzügyi üzletág stb. területén; ? a hanglevelezés (VSM - Voice Messaging System), amely beszédüzenetek, hangos levelek közvetítését teszi lehetové. Az elektronikus adatcsere irányába az elso lépéseket az árufuvarozó vállalatok tették meg, mintegy 30 évvel ezelott, próbálva kibontakozni a papírmunka szorításából. Az EDI-t a hatékonyabb kommunikáció iránti igény hozta létre, mely a modern információtechnikát használja. Az EDI hoskorában a vállalatok egyéni igényeit kielégíto formátumokat dolgoztak ki. Ezek a saját szabványok korlátokba ütköztek, ezért ágazati szabványokat hoztak létre, melyeket az egyes szektorok közötti forgalomra is ki kellett terjeszteni. 1985re két ilyen szabvány jelent meg, melyeket széles körben alkalmaztak - ÉszakAmerikában az ANSI ASC (az Amerikai Nemzeti Szabványügyi Intézet Akkreditált Szabvány Bizottsága) által kifejlesztett X12, Európában a GTDI (írásnyelvek a kereskedelmi adatcserére). Miközben ezek a szabványok a helyi igényeket többnyire kielégítették, a nemzetközi kereskedelemben a két jelentos, de eltéro szabvány léte kezdett bonyodalmat okozni. 1986-ban az EGB jóváhagyta az ENSZ-EDIFACT projektet. Koncepciója szerint ez egy olyan egységes nemzetközi EDI szabvány, amely elég rugalmas ahhoz, hogy a felmerülo különféle igényeket kielégítse. 1987-ben három kulcsfontosságú eseménnyel megkezdodött az ENSZ-EDIFACT hivatalos fejlesztési folyamata: 1. Az EGB ENSZ-EDIFACT-raportoröket jelölt ki Észak-Amerika, Nyugat-Európa

és Kelet-Európa térségébe. 2. Az ISO és az EGB elfogadta az ENSZ-EDIFACT szintaxist. 3. Kísérleti használatra jóváhagyták az elso üzeneteket.

A raportorök feladata, hogy régiójukban megszervezzék a munkát, és közösen gondoskodjanak a területek közti együttmuködésrol. A regionális EDIFACTraportorök egyik kötelessége, hogy megteremtsék saját régiójukban az ENSZ-

23


EDIFACT fejlesztéséhez szükséges megfelelo szervezetet és eszközöket. A regionális EDIFACT-tanácsok segítik a raportoröket feladataik végrehajtásában. Az EDIFACT szintaxis, amely egyben ISO-szabvány (International Organization for Standardization - Nemzetközi Szabványügyi Szervezet), az EDIFACT-üzenetek felépítésére vonatkozó szabványokat tartalmazza (ISO 9735). Az UN/ECE titkárság és a raportorök együttes feladata az EDIFACT szintaktikai szabályok karbantartása és javaslattétel új üzenetekre. Semmilyen körülmények között sem változtathatnak a felhasználók, szoftverkészítok és hálózati szolgáltatók az EDIFACT szintaktikai szabályokon. Csak az UN/ECE titkárságán illetve a raporotökön keresztül kezdeményezheto ez. Az elektronikus adatcsere fejlodése rohamléptekkel folytatódik, a rendelkezésre álló szabványos üzenetek mellett kipróbálási céllal felhasználható üzenetekkel és kidolgozás alatt álló üzenetekkel találkozunk, valamint tovább folytatódik az a kutatómunka, amely az elektronikus adattovábbításra felhasználható dokumentumokat keresi. 2.2

Kommunikációs lehetoségek és kommunikációs protokollok

A kommunikációt tekintve három területet kell kiemelnünk, amelyek egymásra épülnek. A legalsó szinten a „hálózati szolgáltatások” helyezkednek el. Ezt követoen az ezek „felett” elhelyezkedo kommunikációs protokollokról fogunk röviden említést tenni, majd az értéknövelo szolgáltatásokról (VAN - Value Added Network) esik szó. 2.2.1 Hálózati szolgáltatások A hálózati szolgáltatás valósítja meg a partnerek közötti összeköttetést. (Az összeköttetés kifejezés nem kizárólag fizikai kapcsolatot jelent.) Ez a szolgáltatás teremti meg a kapcsolatot a vállalat számítógépe és a partner vagy az értéknövelo hálózati szolgáltató számítógépe között. A hálózatok a legutóbbi idokig a nemzeti távközlési szolgáltatók kezében voltak. Napjainkban azonban, a világméretu deregulációs folyamatok eredményeként mind több hálózati szolgáltatást kínáló vállalat jelenik meg. Számos értéknövelo szolgáltató üzemeltet globális hálózatot, amely alkalmas az EDI-kommunikációra. Az EDI-kommunikációt napjainkban többféle hálózat segítségével bonyolítják le. A következo felsorolás a legelterjedtebbeket tartalmazza: ? nyilvános telefonhálózat vagy bérelt vonali hálózat; ? vonalkapcsolt adathálózat;

24


? csomagkapcsolt adathálózat (X.25); ? Integrált szolgáltatású digitális hálózat (ISDN - Integrated Services Digital Network); ? hibrid hálózat; ? Internet. A nyilvános telefonhálózaton bonyolított adatátvitel esetén az adatokat küldo fél (adó) és az azokat fogadó fél (vevo) a nyilvános távbeszélo hálózaton modem segítségével kommunikál egymással. A modem az adó digitális jeleit a távbeszélo hálózaton átviheto analóg jelekké alakítja, a vevo oldalon pedig az analóg jeleket digitális jelekké demodulálja, emellett egy sor kiegészíto funkciót is ellát. A legkorszerubb modemek hibajavítást és tömörítést is végeznek.

A kommunikációnak ez a széles körben elterjedt formája még ma sem veszített jelentoségébol. Ennek oka a rohamosan bovülo telefonellátottság és a modemek viszonylag olcsó beszerzési ára. Ha ezen túlmenoen figyelembe vesszük, hogy egyegy EDI-üzenet - éppen a strukturáltság miatt - viszonylag kis adatmennyiség továbbítását jelenti, nem túl nagyszámú üzenetcsere esetén a legolcsóbb megoldásnak tekintheto. A rövid üzenetek gyorsan keresztüljutnak a hálózaton, mivel a díjszabás az összeköttetés idotartamától függ a kommunikáció viszonylag olcsón lebonyolítható. A vonalkapcsolt hálózat muködési elve lényegében megegyezik a telefonhálózatéval. Ez azt jelenti, hogy az összeköttetés itt is kizárólag a hívó és a hívott fél között áll rendelkezésre, akkor is, ha a felek nem bonyolítanak le adatátvitelt. Díjszabása ugyancsak megegyezik az elozo megoldással. Különbséget jelent azonban, hogy a hálózat az elofizetok eszközeihez egységes digitális interfészt nyújt. A vonalkapcsolt adathálózaton különbözo sebességu ún. elofizetoi szolgáltatási osztályok vannak, amelyek funkcionálisan különbözo sebességu külön-külön vonalkapcsolt adathálózatként muködnek. Eltéro sebességu osztályok elofizetoi tehát nem kommunikálhatnak egymással, ami a vonalkapcsolás valós ideju muködésmódjának következménye. Szemben például a csomagkapcsolt hálózat tárolva továbbító muködésmódjával, ahol a különbözo adatátviteli sebességu végberendezések is kommunikálhatnak egymással. A hálózat meghatározott különszolgáltatásokat nyújt, amelyek az alábbiak: ? közvetlen hívás: hívás a kapcsolási szám megadása nélkül; ? zárt elofizetoi csoport: a csoport tagjai csak egymás között létesíthetnek kapcsolatot;

25


? zárt elofizetoi csoporton belülrol jövo hívás letiltása: a zárt csoport kijelölt adatállomásait nem hívhatják fel a csoport többi állomásai sem; ? zárt elofizetoi csoporton belülre meno hívás letiltása: a zárt csoport kijelölt adatállomásai nem hívhatják fel a csoport többi állomását sem; ? hívóvonal azonosítása: a hálózat megadja a hívottnak a hívó kapcsolási számát; ? hívott vonal azonosítása: a hálózat megadja a hívónak a hívott kapcsolási számát; ? sorozatba kapcsolás: több állomás egyetlen kapcsolási számon hívható, a hálózat maga választja ki az elso szabad vonalat; ? híváskezdeményezés vagy hívásfogadás lehetoségének kizárása egyedi állomás esetén. Az elozo két hálózattípus elsosorban a hagyományos kommunikáció igényeihez alkalmazkodott (pl. beszédhang, távirat továbbítása). Ez azt jelenti, hogy a hívás idotartama alatt egyetlen állandó rögzített út jön létre, amely abban az esetben is fennáll, ha az ido egy részében nem történik információcsere. A számítógépes alkalmazások számára azonban inkább a nagy sebességu, rövid idore igénybe veheto összeköttetés lenne a megfelelobb. Ez az igény vezetett a csomagkapcsolt hálózat kialakulásához. A csomagkapcsolt hálózatokon az adatok fejrésszel ellátott csomagokra bontva jutnak el az adatforrástól a címzettig. A hálózat csomópontokból áll, amelyek rövid tárolás után, a csomagok fejrészének kiértékelését követoen továbbadják a csomagot a következo hálózati csomópontnak. Az utolsó csomópont elérése után jut el a csomag a címzetthez. Egy üzenet csomagja különbözo úton, különbözo hálózati csomópontok érintésével is eljuthat a címzetthez. A csomagkapcsolt adathálózat a következo jellemzoket mutatja: ? szakaszonkénti és átfogó hibavédelem; ? a hálózati utak hatékony használata; ? ugyanaz a végpont egyszerre több partnerrel is kommunikálhat; ? eltéro sebességu berendezések kommunikálhatnak egymással. A csomagkapcsolt adathálózatoknak ugyanakkor jellemzojük a bizonytalan, változó ideju késleltetés is, emiatt ezek csak kevésbé, alkalmazhatók az azonnali választ igénylo (real-time) alkalmazások kiszolgálására, külön intézkedések nélkül. További hátrányai lehetnek, hogy az egyes csomópontokon külön kell gondoskodni: ? olyan tárkiosztásról, amelynek révén az eloírtnál ritkábban fordul elo, hogy a csomópont tárhiány miatt új vagy érkezo csomagot nem tud fogadni; ? nemcsak a vonalak, hanem a tárak védelmérol is tartalmuk lehallgatása, az ellopás, a megrongálódás, a kicserélés vagy a megsemmisítés ellen;

26


? arról is, hogy a hibás vonalak és csomópontok elkerülése során a csomagok forgalomirányítása ne kerüljön se hurokba (végtelen ciklusba), se olyan torlódási helyzetbe, amely a hálózat átereszto-képességét lényegesen leronthatja; A csomagkapcsolt hálózat a következo összetevokbol áll (9. sz. ábra): ? hálózati csomópontok (az ún. nódok vagy kapcsolóközpontok); ? hálózati átviteli utak, amelyek csomópontokat kötnek össze; ? hozzáférési átviteli utak, amelyek a használókat (elofizetoket) a csomópontokhoz csatlakoztathatják (elofizetoi vonalak vagy utak); ? kiegészíto egységek, amelyek akár az elofizetoi pontokon, akár a hálózati csomópontokon további (esetleg értéknövelo) szolgáltatások igénybevételét teszik lehetové, vagy kiterjedt elofizetoi hálózatok csatlakoztatását végzik (üzenetkapcsoló csomópontok, hidak, átirányítók, átjárók stb.) V3 V2

V4

V1

V5 NA

NB

X.25 csatlakozás

NC NE

ND

V6 NA, NB,...NE: hálózati csomópontok V1 ,V2 ,...V8: X.25 típusú végberendezések

9. ábra

V8

V7

A csomagkapcsolás alapelve

Az X.25 olyan nemzetközi ajánlás, amely háromrétegu (OSI modell - Open System Interconnection - nyílt rendszerek összekapcsolása) csatlakozási interfészt ír elo az elofizetoi adatvég-berendezés és az elofizetoi adatállomáson a hálózatot képviselo adatáramköri végberendezés között. A szabványos X.25 interfész teszi lehetové azt, hogy a különféle gyártók által készített adatvég-berendezések, hálózati csatlakozóegységek együtt tudjanak muködni a különféle távközlési szolgáltatók különbözo gyártású, kivitelu és korú csomagkapcsolt adathálózataival. Az egyszeru (nem programozható) terminálok csomagkapcsolt hálózatra történo csatlakoztatására fejlesztették ki a csomag összeállító-szétbontó ún. PADszolgáltatást (Packet Assembler-Disassembler). A PAD mindkét irányban elvégzi azokat az átalakításokat, amelyek ahhoz szükségesek, hogy a csatlakozó terminál és

27


a távoli csomagüzemmódú számítógépes berendezések megérthessék egymást. (10. sz. ábra) X.25 készülék PC-k és terminálok X.25 csomópont

X.25 hálózat

10. ábra

X.28 PAD

X.28. szabvány szerinti PAD-ok egy X.25-ös hálózatban

A csomagkapcsolt hálózathoz való legegyszerubb, legkisebb beruházást igénylo hozzáférésmód az ún. PAD-behívás, amikor a távbeszélo-hálózaton üzemelo aszinkron adatállomás hívja a PAD-ot. Az így felépült, kapcsolt modemes összeköttetésen keresztül a megfelelo azonosítás után belép a hálózatba. (Szinkron az adatállomás akkor, ha az adatátvitel során nem használ idozítojeleket - órajeleket -, a bájtokat vagy karaktereket hordozó adatjelek start- és stopelemei elegendo ütemezést adnak egy-egy adatjel hibamentes visszaállításához, értelmezéséhez.) Az összeköttetés során az azonosítás a hálózathasználói azonosító (NUI - Network User Identification) megadásával történik, amelyet jelszó egészít ki. Az integrált szolgáltatású digitális hálózat (ISDN - Integrated Services Digital Network) lehetové teszi, hogy a különbözo szolgáltatásokat egy nagy sebességu, nyilvános hálózaton vehesse igénybe a használó. A hálózat a jeleket digitális formában továbbítja. Az ISDN egyaránt alkalmas beszéd, fax, adatok, videojelek, grafikák (multimédia) továbbítására. A gyors, nagy mennyiségu adat átvitelére alkalmas ISDN biztosítja, hogy a szolgáltatásokat a használó egyetlen szabványos interfészen keresztül vegye igénybe. Az ISDN elofizetok irodájukban egy csatlakozóaljzattal rendelkeznek, ami hasonlít a telefon csatlakozóhoz. Az ISDN hálózathoz csatlakoztatott eszközzel bármilyen analóg jel átalakítható digitális jellé. Hasonlóan a telefonhálózathoz, bármelyik elofizeto felhívhatja a hálózatra csatlakozott másik elofizetot. Feltéve, hogy kompatibilis berendezések vannak, adatokat vagy más jeleket küldhetnek az összeköttetés maximális sebességén.

28


Bizonyos tekintetben az ISDN egyfajta kihívás a jelenlegi EDI szolgáltatóknak, mivel az üzleti partnerek számára lehetové teszi az adatok küldését egymásnak egyszeruen, minimális formalitással. Idovel sok EDI használó fogja keresni a lehetoséget, hogy ISDN használóvá váljon.

Csomagkapcsolt adathálózat (A ország)

Optikai szál kapcsolat

Analóg, szélesköru hálózat (A ország)

Mikrohullámú kapcsolat Digitális hálózat (B ország) Muhold kapcsolat

11. ábra

Hibrid hálózat

Ugyanakkor nem szabad megfeledkezni arról, hogy egy EDI rendszernek alapvetoen a következoket kell nyújtania: biztonságos muködés biztosítása a használóknak, az üzleti partnerek rendszerének muködéséhez igazított üzenetek küldése, az üzenetek szétosztása több célpontra küldés esetén, a hálózat forgalmának rögzítése és az összegyult üzenetek érvényesítése, és lehetoség szerint néhány formátum ellenorzése és konverziója. Az EDI rendszer több, mint egy kommunikációs csatorna, a cégek muködésének része. A hibrid hálózatok a különbözo hálózati technológiák összekapcsolásával jönnek létre (11. sz. ábra) A vörösréz és alumínium kábelek használatosak a helyi hálózatokban, ezek összeköttetésére optikai szálakat használnak. A mikrohullámú kapcsolatok inkább Észak-Amerikában terjedtek el, Európában kevésbé. Manapság már a muholdakat igénybevevo kommunikáció fokozatosan kerül elotérbe. Az Internet valójában több hálózatot foglal magában, ezért a „hálózatok hálózata” névvel is szokták illetni. Az Internet egy hálózati alapszolgáltatást nyújt csupán, ami önmagában csak a végpontok közti kapcsolatot biztosítja. Ilyen értelemben az

29


„informatikai országút” szlogen tulajdonképpen huen fejezi ki a lényeget. Az Internet igazi értékét - a magasabb szintu szolgáltatásokat - az Internetre kapcsolódott értéknövelt szolgáltatók nyújtják. Az Internet jelentoségét az adja, hogy a világ hálózati rendszerei közül a legnagyobb kiterjedésu és messze a legnagyobb felhasználói számmal büszkélkedhet. Az Internet elonyei közé tartozik: ? A felhasználói kör óriási mérete. ? Roppant sebességu terjeszkedése. ? Az értéknövelt szolgáltatók által biztosított rugalmasan növekvo, széles szolgáltatási portfolió. ? Az olyan újszeru szolgáltatások révén, mint a WWW (World Wide Web) a barátságos (multimédia) felhasználói felület. ? A nagyszámú, piacorientált szolgáltató cég által a felhasználók hatékony, egyedi megoldásokra is kiterjedo támogatása. Az Internet negatívumai közé az alábbiak sorolhatók: ? Nincs átfogó szabvány háttere. ? Számos biztató kísérlet dacára is a biztonsági kérdések általános megoldása és gyakorlata még várat magára. ? Az Internetnek nincsen egyetlen tulajdonosa vagy felelose. Ennek következtében senki sem garantálja, vagy vállal felelosséget egy üzenet célba jutásáért, vagy azért, hogy nem kerül-e illetéktelen kézbe. Mindez akadálya az EDI Internet elterjedésének. Országonként eltéro lehet az EDI-hez kapcsolt hálózat fajtája. Németországban például az utóbbi idoben a nyilvános telefonhálózat és az ISDN használata jellemzo leginkább. Nyugat-Európa több országában több nagy EDI-projektet valósítottak meg csomagkapcsolt hálózat igénybevételével. Magyarországon, ahol az EDIalkalmazás még nem terjedt el, több megoldással (pl. vonalkapcsolt, csomagkapcsolt hálózat) is találkozhatunk. 2.2.2 Távközlési szolgáltatások Üzenetkezelés Az üzenetkezelés két fajtája alakult ki: a személyek és az informatikai alkalmazások közötti kommunikációt célzóak. Elobbi tipikus esete az elektronikus levelezés, míg utóbbira a kézenfekvo példa az EDI. Az üzenetkezelésnek az EDI szempontjából két meghatározó funkcionális csoportja különböztetheto meg. Mindketto közös jellemzoje az üzenetekre vonatkozó

30


útképzés (routing), mivel azok általában több közvetíto funkcionális elemen haladhatnak át, míg célba érnek (lásd késobb az X.400 ismertetésénél). ? A „tárold és továbbítsd” (store and forward) jellegu üzenetkezelésre az automatikus, „azonnali” továbbítás a jellemzo. Ez a fajta muködési mód elsosorban az interaktív EDI-re alkalmazható, bár más híján a hagyományos EDIre is alkalmazzák. Ilyen jellegu volt az X.400 eredetileg az 1984. évi szabvány alapján, az MS (Message Store - üzenettároló) funkció nélkül. ? A „tárold, majd lehívják” (store and call forward) jellegu üzenetközvetítéskor egy közbülso funkcionális elem elvileg addig tárolja az üzenetet, amíg a címzett azt le nem hívja. Az ilyen rendszerek kizárólag a hagyományos kötegelt EDI-re alkalmasak, az interaktívra nem. Az elobbi esetében a partnerek idoben függetlenné válhatnak egymástól. Az üzenetkezelés legfontosabb elonyei a közbülso tároló alkalmazásából és több továbbító funkcióból (lásd. MTA-k az X.400 esetében) következnek: ? az üzenetek mozgása jól nyomon követheto, naplózható; ? az „elektronikus közjegyzo” funkció megvalósítható; ? az üzenetek menet közben míg a tárolóban vannak feldolgozhatók (pl. konvertálhatók, ellenorizhetok, összesíthetok stb.); ? jelentosen javítják az együttmuködo partnerrendszerek biztonságát, miután a tároló elem közvetíto köztük, melyek így már egymás rendszereit közvetlenül nem érhetik el. Üzenetkezelo rendszert elsosorban akkor érdemes igénybe venni, ha ? sok partner vesz részt a kommunikációban; ? egy alkalommal csak kevés üzenetet kell küldeni; ? szervezeti- esetleg eszközfüggetlenséget kell biztosítani. Fájl átvitel A hagyományos kötegelt EDI természetes környezete a Feladat átvitel (Job transfer), mégis az EDI szabványok jellemzoi miatt nem ez vált gyakorlattá. Kezdetben az ehhez viszonylag közel álló fájl átvitel eljárások kezdték ezt a szerepet betölteni. Fájl átvitelt elsosorban akkor célszeru alkalmazni, ha ? nagy adatmennyiséget gyorsan kell átvinni; ? nem sok partner vesz részt a kapcsolatban; ? közbülso rendszert nem szabad használni.

31


Feladat átvitel (Job transfer) Az EDI rendszerekben a fájl átviteli és az üzenetkezelési irányultság alakult ki annak ellenére, hogy a feladat átvitel elvileg testreszabott lenne az EDI kötegelt jellege miatt. Ez az EDI szabványok koncepcionális megközelítésének köszönheto, mely az egyes elektronikus dokumentumokat, mint hierarchikus adategységeket (UN/EDIFACT esetén üzenetek, ANSI X12 esetén tranzakciók) definiálja, az ezeket összekapcsoló vezérlo funkciókat nem. 2.3 Kommunikációs protokollok A kommunikációs protokoll kezeli - többek között - a logikai összeköttetés felépítését, az adatátvitelt, a nyugtázást, az összeköttetés bontását. A szabványos adatcseréhez az adatokat a számítógépek között továbbítható adategységekre kell bontani. Ilyen egységek lehetnek az adatállományok (adatfájlok) és az üzenetek vagy a programok közti kommunikációra szolgáló pufferek. A protokoll határozza meg a küldött és kapott adategységek típusát. A protokoll tehát azt írja le, hogy az említett muveleteket milyen módon kell végrehajtani. Mivel az EDI kötegelt feldolgozású (batch orientált), az állomány átviteli protokollok (file transfer protocol) jól használhatóak az EDI-kommunikációhoz. Ez nem igényel „real-time” (idoazonos) üzemmódot, bár az ún. interaktív, párbeszédes EDI a jövoben ettol eltéro megoldást is igényelhet. Sok esetben a kommunikációs protokollokat számítógépgyártók készítették. A gyártók termékeihez használható szoftverek ennek megfeleloen a saját fejlesztésu protokollt támogatták. Más a helyzet a széles körben elterjedt TCP/IP (Transmisssion control protocol/internet protocol) esetében, amelyet az Amerikai Védelmi Minisztérium fejlesztett ki. Szervezetspecifikus szabványok OSI TP ?

X.435

X.400 (P2)

Integrált szolgáltatású digitális hálózat

6. táblázat

FTAM

OFTP

Csomagkapcsolt adathálózat

Számítógépgyártók gyári szabványai

Nyilvános telefonhálózat

Néhány hálózati lehetoség és protokoll szabvány az EDI-hez

32


Az egyszerubb, szabványos protokollok a távoli adat- és muveletbeviteli funkciók kiszolgálására születtek. Ezek funkciókészlete az adatátvitelre korlátozódik, és többnyire nincs külön EDI-t támogató funkciójuk. Az elso EDI-protokollt az Odette fejlesztette ki az európai autógyártó ipar számára. A protokoll, amely az OFTP (Odette File Transfer Protocol - Odette állományátviteli protokoll) nevet kapta, ipari szabvánnyá vált. (6. sz. táblázat) Napjainkban az új protokollszabványok kidolgozását egyre inkább a szabványosító testületek végzik. A hálózati és kommunikációs protokollok szabványait egy elméleti távközlési modell, az OSI modell alapján specifikálják. Ez a modell a különbözo szabványok funkcióinak egymáshoz való viszonyát írja le. Az OSI által definiált keret két olyan kommunikációs módszert is meghatároz, amely az EDI céljaira felhasználható. Ezek két szabványban specifikáltak, az ún. X.400-as sorozatú (üzenetkezelo rendszerek) ajánlásokban és az FTAM (állományátvitel,hozzáférés és-kezelés) szabványban. X.400 és X.435 Az X.400-as szabvány egy olyan ajánlássorozat, amelyet elektronikus üzenetek kezelésére dolgoztak ki. Az ajánlássorozat kidolgozója a CCITT (Consultative Committee on International Telegraph and Telephony - Távírási és Telefonálási Tanácsadó Bizottság). Az üzenet küldoje lehet személy vagy alkalmazás, az EDI esetén az üzenet küldoje egy alkalmazás, aki vagy ami az ún. használói képviselo (amely egy elektronikus postaládával fogható fel) közbeiktatásával adja át üzenetét az üzenettovábbító szolgálatnak. Az üzenettovábbító szolgálat a felelos az üzenet további sorsáért. Igény esetén tárolja, végül a fogadó fél használói képviselojének kézbesíti az üzenetet. Így annak küldoje és fogadója nincs közvetlen összeköttetésben, az egyes válaszüzenetek önálló üzenetként továbbítódnak. Az elso X.400-as ajánlatsorozat-változatot 1984-ben adták ki, amely még a „tárold és továbbítsd” jellegu megvalósítást tartotta szem elott, míg a késobbi a „tárold, majd lehívják” jellegu muködést. Ez utóbbit olyan szolgáltatásokkal vértezték fel, mint a névtárszolgálat, az üzenettárolás, továbbá a biztonsági funkciók közül a felhatalmazás, valamint az adatok sértetlenségének és bizalmasságának a biztosítása. Az üzenetkezelo rendszerek általános modelljét a 12 sz. ábra mutatja be. A használóval az UA (User Agent - a használó képviselo) áll kapcsolatban, amely a hozzátartozó MTA-val (Message Transfer Agent - üzenettovábbító ügynök/képviselo) együttmuködve segíti a használót az üzenetek eloállításában, címzésében, feladásában, ugyanígy a vett üzenetek olvasásában, megválaszolásában, továbbadásában stb. Ugyancsak az UA nyújthat olyan kiegészíto funkciókat is, mint az üzenetek elraktározása (archiválása), kiegészítése, átszerkesztése, ismétlése,

33


lekérdezése, átirányítása stb. Minden UA-nak egyedi címe van, amit az X.400 általános (globális) címkezelo rendszere egyértelmuen azonosít. Az MTA egy tároló-továbbító üzenetkapcsoló. A hagyományos levélpostai rendszerben az MTA megfeleloje a „postahivatal”. Az MTA-k egymással összekapcsolt rendszere az X.400-as ajánlásokban, illetve a szabványokban eloírt módon gondoskodik az üzenetek tartalomtól független eljuttatásáról a felvevocsomóponttól kezdve egészen a rendeltetési csomópontig. Ezt a szolgáltatást nevezzük üzenettovábbító szolgáltatásnak (Message Tranfer Service). UA

UA

RUA P7

MS

UA P2

MTA

P1

MTA

MTA

AU Telefax P1 - MTA-MTA protokoll P2 - UA-UA protokoll P7 - UA-MS protokoll

12. ábra

Fizikai

Telex

Az üzenetkezelo rendszerek modellje

A nagygépes rendszerekben az UA általában ugyanazon a rendszeren volt megvalósítva, mint a hozzátartozó MTA, ezért mindig rendelkezésre állt. A PC-k elterjedésével azonban szükséges volt olyan újabb elemet kialakítani, amely ezek számára is lehetové teszi a szolgáltatás használatát, mivel nincsenek folyamatosan a hálózatra kapcsolva. Az 1988-as szabványoktól kezdve megjeleno MS (Message Store - üzenettároló) szerepe az, hogy a távoli és nem mindig rendelkezésre álló UA-k számára megorizze az üzeneteket. Ez az üzenettároló a hagyományos „postafiók” elektronikus megfeleloje. Az olyan intelligens és önállótlan, az MTA-tól fizikailag távol (tipikusan PC-s szoftvercsomaggal) megvalósított UA-kat, amelyek üzenettárolóhoz csatlakoznak, tehát a rendszerbe csak az MS-en keresztül kapcsolódnak RUA-nak (Remoter User Agent - távoli használót képviselonek) nevezzük.

34


Az X.400-as üzenetkezelo rendszerek használói üzenhetnek más, nem az X.400 szerint muködo rendszerekbe, esetenként választ is kaphatnak ilyen rendszerekbol (pl. telex, telefax, hagyományos levélposta). Erre a célra határozták meg az AU-kat (Access Unit - hozzáférési egységeket), amelyek a nem X.400-as külvilág illesztését végzik. A leglényegesebb AU-k: a FAXAU, amelynek segítségével távmásoló készülékre továbbítható üzenet, valamint a PhDAU, amely a fizikai kézbesítorendszer (postás) számára adja tovább a kézbesítendo üzenetet. elektonikus üzenet üzenetfejrész tárgy:

Címzett:

üzenettörzsrészek szöveg fax kép

13. ábra

Feladó:

A személyközi üzenetek szerkezete

Az üzenetkezelo rendszerek sok tekintetben a hagyományos papíralapú levelezés elektronikus megfelelojének tekinthetok, így az üzenetkezelo rendszerekben is minden egyes üzenet két fo részbol áll: a borítékból és a tartalomból. A boríték tartalmazza mindazt a vezérloinformációt, amely az üzenet kezeléséhez szükséges (feladó, címzett, sürgosségi fokozat stb.). A tartalom a címzettnek (embernek vagy számítógépes alkalmazásnak) szól. A tartalom különféle formátumú törzsrészekbol (szöveg, bináris fájl, 3-as csoportú (G3) fax-formátum stb.) állhat. Ismét a hagyományos levélpostából véve az analógiát, ez a struktúra nagyon hasonló ahhoz, amikor valaki a megcímzett borítékban a szöveg mellett egy-egy rajzot, fényképet stb. is elhelyez. A használó képviselo, amely személyközi üzenoszolgálatra is képes, olyan szoftvermodul, amely további protokoll segítségével magát a tartalmat is két részként kezeli: az egyik a fejrész, amely az üzenetre jellemzo információkat (pl. a tárgyat) tartalmazza, a másik a törzsrész, amely az üzenet adatait hordozza. (13. sz. ábra)

35


Az EDI szempontjából két eltéro gyakorlat alakult ki az EDI-üzenet elhelyezését tekintve. Az Egyesült Államokban az EDI-üzenet az ún. 0 típusú (definiálatlan) boríték tartalmát képezi (14. sz. ábra). A másik, Európában inkább elterjedt gyakorlat szerint az EDI-üzenet az ún. 2. típusú boríték törzsrészében helyezkedik el (15. sz. ábra).

Boríték Tartalom: 0. típus ANSI X.12 (definiálatlan) tranzakciókészlet

14. ábra

A 0. típusú boríték

Boríték

Fejrész: Tartalom: 2. típus

- küldo - fogadó

Egy törzsrész: - EDIFACT adatcsere

15. ábra

2. típusú boríték

Az X.400-as sorozaton belül 1988-ban új ajánlást fejlesztettek ki az EDIkommunikáció támogatására. Az új protokoll az X.435, amely Pedi néven is ismert, és számos szoftvertermék támogatja. Az X.435 új elemei az EDI-üzenet és az EDI-értesítés. Az X.435 EDI-üzenet része a ? fejrész, amelynek mezoiben megadható az üzenet azonosítója, a címzett, a szintaktika, az EDI üzenettípus és az értesítés kérése stb. ? törzs, amely egy vagy több törzsrészt tartalmazhat. A törzsrészek egyike EDI üzenetekbol állhat. Az EDI-értesítést az üzenet vételének és továbbításának nyugtázására használják a végpontok között, lehetové téve a hálózati forgalom ellenorzését (16. sz. ábra). Az X.400-as szabványt támogató rendszerek lehetové teszik a használóknak, hogy elektronikus üzeneteket cseréljenek. A használók lehetnek egyazon vállalat vagy különbözo vállalatok dolgozói, azonos vagy eltéro levelezési rendszereket használhatnak, földrajzi szempontból lehetnek azonos vagy más országokban.

36


Boríték

Fejrész: Tartalom: EDIM

- küldo - fogadó - információ az UNB-bol - értesítéskérés -…

EDI-törzsrész: - EDIFACT adatcsere

16. ábra

Opcionális törzsrész:

nem EDI

…

(nem EDI)

Az X.435 boríték

Az FTAM Az FTAM vagy ISO 8571 olyan szabványsorozat, amely távoli rendszerek között állományátvitelt és más állománymuveleteket tesz lehetové. A muvelet kezdeményezoje egy virtuális állománytárhoz fér hozzá, amely a tényleges állományszerkezet valamilyen leképezése. A tényleges fájlrendszer többnyire csak a távoli végponton ismert. A kezdeményezo olvashatja, írhatja vagy megváltoztathatja a virtuális fájlokat vagy azok egyes részeit. A protokoll muködése két végpont közötti, átmeneti tároló nélküli kommunikáción alapul. A protokoll lehetové teszi az adatok hierarchikus strukturálását az állományon belül, ami nagymértékben megkönnyíti azt a módot, ahogyan a strukturált állományhoz hozzá lehet férni. Egyúttal azonban bonyolulttá teszi a megvalósítást. Emiatt a protokoll csak korlátozott funkciókészletu állományok kezelését, pl. bináris adatok vagy szövegek továbbítását teszi lehetové. Az eddig ismert termékek közül csak kevés támogatja ezt a szabványt.

37


Az Odette File Transfer Protocol (OFTP) Az Odette elsosorban az EDI speciális igényére való tekintettel dolgozta ki az OFTP-t azzal a kettos céllal, hogy ? a fájl transzfer (FTAM) a közbülso tároló központ és a hozzá tartozó útképzés jellegu funkciók (X.400) együttesen jelenjenek meg; ? tegyen lehetové az X.400-hoz és a FTAM-hoz képest egyszerubb és olcsóbb megvalósítást. Az OFTP az EDI mellett természetesen más jellegu állományok továbbítására is alkalmas. Az OFTP a megvalósítás és a használat költségkímélo voltához azzal is hozzájárul, hogy közvetlenül épül X.25, sot egyszeru aszinkron X.28 távközlési alapra. Ez utóbbi például csak egy egyszeru aszinkron modemet és egy telefonvonalat igényel. X.25 esetén az ISDN alapként való választását is támogatja a szabvány. Az OFTP szabvány egy háromrétegu, valójában több protokollt tartalmazó egyszerubb architektúrát ír le. Az egyes, egymásra épülo rétegek felülrol lefelé haladva: ? Üzenet ? Állomány ? Hálózat Az OFTP számos olyan funkcióval rendelkezik, mint például az „End-to-End Response” (EERP), mely választhatóan teszi lehetové azt, hogy a címzett mikor küldjön nyugtát a feladónak. (Lehetoség van arra, hogy akkor tegye ezt meg, ha az EDI konverzió sikeresnek bizonyult - a vett állomány EDI üzenetei valamennyien szintaktikailag helyesek.) Az OFTP alkalmazása meghaladta az autóipar korlátait és viszonylag rövid ido alatt olyan népszeruvé vált, hogy valamennyi értéknövelt hálózati szolgáltató - akár az X.400 esetében - az igényekre való tekintettel kénytelen volt OFTP átjáró szolgáltatást is bevezetni. Ezzel az OFTP - hasonlóan az X.400-hoz - elérte a hálózatoktól független univerzális jelleget. Az internet protokollok A kis betuvel kezdodo „internet” egy protokoll-család neve, melyet az USA Kereskedelmi Minisztériuma ajánlott szabványként a 70-es évek végén. Másik gyakran használt neve a családnak a TCP/IP, melynek jelentoségét az határozza meg, hogy ez a protokoll szolgálja ki az Internet alapú kommunikációt.

38


Az EDI számára közvetlen szolgáltatást nyújtó magasabb szintu internet protokollok a következok: 1. SMTP, MIME A protokoll család legrégebbi üzenetkezelési protokollja az Egyszeru Levél Továbbítási Protokoll (Simple Mail Transfer Protocol - SMTP). A protokoll több olyan korlátozó tényezovel rendelkezik, mint ? a protokoll személyek közti kommunikációs jellege; ? az ASCII kód kizárólagos használata, ami egyes EDI szabványok használatát éppen úgy korlátozza, mint a címzettek számát, vagy az üzenetek maximális méretét. Ez utóbbi probléma feloldása érdekében jött létre az ajánlás a „Több Célú Internet Levelezési Kiterjesztésre” (Multipurpose Internet Mail Extension MIME). Az ajánlás ún. „levél törzs struktúrát és különbözo tartalom típusokat” vezetett be, melyek lehetové tették a dokumentumok SMTP kompatibilis módon történo levélbe csomagolását. A „tartalom típusok” szövegre, hangra, képre, videóra vagy 8 bites informatikai adatokra egyaránt kiterjednek. Az EDI szempontjából az igazi áttörést az a szabvány jelentette, mely kifejezetten EDI objektumoknak a MIME-n belüli becsomagolását célozta. Ez lényegében UN/EDIFACT és ANSI X.12 szabvány szerinti EDI üzenetek, illetve tranzakciók MIME tartalom típusokként való kezelését tette lehetové és megoldotta azt, hogy az EDI üzenetek az átvitel során megtartsák mind szintaktikai, mind szemantikai jellemzoiket. 2. World Wide Web A WWW (Világméretu Pókháló) multimédia jellegu, ún. hipermédiadokumentumok keresését és megjelenítését teszi lehetové. Ezek tartalmazhatnak képet, hangot, és korlátozott animációt is. „Hyperlinks” kapcsolatok révén egy sor, akár különbözo helyeken tárolt dokumentumot is összekapcsolhatnak, melyet a HTTP (Hyper Text Transport Protocol) segít. Több cég alkalmaz WWW-re és HTTP-re alapozó urlapokat az EDI-hez közel álló üzleti tranzakciók esetében. Ezeket jelenleg az ügyfél oldalán interaktív módon töltik ki, majd kitöltve a HTTP segítségével elküldik a WWW kiszolgálóra, ahol ez utóbbi megfelelo átjáró segítségével továbbítja az adatokat az alkalmazói rendszerhez. Az EDI WWW-n keresztül történo gyakorlati megoldása még gyerekcipoben jár, számos kezdeményezés létezik már. Ennek keretében az üzleti tranzakciók

39


biztonsága érdekében az ún. Secure HTTP (SHTTP) is megjelent, mely a személyi adatok (privacy) és a hozzáférés védelem (authentication) kielégítésére továbbfejlesztett HTTP protokoll. 3. Telnet, FTP Annak ellenére, hogy a Fájl Átviteli Protokoll (File Transfer Protocol - FTP) szintén alkalmas alapot nyújthatna az EDI-re, számottevo ilyen gyakorlat nem létezik. Feltehetoen erre addig kell várni, míg a biztonsági kérdések megnyugtató megoldása megtörténik. Hasonló a helyzet a Telnet terminál elérési protokoll esetében is, az interaktív EDI vonatkozásában. Az elmúlt néhány évben az Internet használóinak száma robbanásszeruen emelkedett és ez a tendencia várhatóan tovább erosödik az elkövetkezo idoszakban. Ennek egyik motorja az elektronikus kereskedelem, amely várhatóan mind több használót kapcsol be a TCP/IP alapú hálózatokba. ISO OSI Jelen gyakorlat szerint a virtuális terminál protokoll funkció használata igen ritka, feltehetoen az interaktív EDI térhódításával jelentosége noni fog. Jelen állapotában az ISO OSI JTAM ( Job Transfer and Management) protokollja a bonyolultsága, nehézkessége és ennek következtében a ritka megvalósítása miatt feltehetoen nem gyakorolna vonzó alapot az EDI használathoz. IBM SNA / APPN LU 6.2 Az LU 6.2 az IBM-nek az egyenrangú programok közti kommunikációt támogató, ún. „peer-to-peer” protokollja. Szinte valamennyi IBM informatikai rendszer szabvány-protokollja, ilyen környezetben az EDI támogatására is gyakran használják. Aszinkron protokollok (TTY, X.28) A régi, rendkívül egyszeru és olcsó TTY távgépíró protokoll újjáéledt a PC-k és a UNIX rendszerek megjelenésével. Az X.28 protokoll az X.25 adathálózat helyi elérését teszi lehetové távoli PAD hívás révén aszinkron vonalon keresztül. Az új modern generációk megjelenésével az aszinkron átvitel minoségi (hibaellenorzés, adattömörítés) és sebességi jellemzoi jelentosen javultak, ami következtében olcsó, mégis a teljesítmény/ár jellemzot tekintve az aszinkron protokollok igen elonyös alapot jelentenek a távközlési hálózat vagy értéknövelt szolgáltatás helyi eléréséhez.

40


2.3.1 Értéknövelo szolgáltatások (VANS - Value Added Network Service) Az értéknövelo szolgáltatást nyújtó fél harmadik szereploként lép be a kommunikációt bonyolító felek közé. A gyakorlatban ez rendszerint valamilyen elektronikus postaláda-szolgáltatást és az ahhoz kapcsolódó kiegészíto szolgáltatást jelenti. A szolgáltató általában passzív szereplo, a tranzakciókat (üzenet küldése, kiolvasása a postaládából stb.) a partnerek kezdeményezik. A szolgáltató azonban számos - a biztonságot, megbízhatóságot, gyorsaságot, kényelmet - biztosító szolgáltatást nyújt a partnereknek. Ilyen szolgáltatások lehetnek például: ? kimeno és bemeno adatok auditálása; ? 24 órás ügyfélszolgálat; ? technikai tanácsadás, rendszerintegráció; ? az adatforgalom naplózása; ? igény esetén adattárolás; ? konverzió a különbözo protokollok között; ? hozzáférés adatbázisokhoz stb. Fontos azonban megemlíteni a különbözo értéknövelo szolgáltatások közötti átjárhatóságot. Lényeges szempont, hogy a szolgáltató mely más hálózatokra biztosít átjárást és milyen mértékben teljesülnek ilyen esetekben a biztonsági követelmények. Az értéknövelo szolgáltatások haszna abban rejlik, hogy: ? a szakosodott szolgáltatók olcsóbban, megbízhatóbban, kezelhetobben, kényelmesebben tudják ezeket a szolgáltatásokat nyújtani, mintha azokat a használók saját maguk fejlesztenék és valósítanák meg; ? a szervezetek nagy részének gazdaságosabb saját tevékenységi körükön belül szakosodni és a távközlési megoldásokat készen megvásárolni; ? egyszerubben és könnyebben kialakítható a vállalatközi, világméretu együttmuködés, amelybe bárki gyorsan bevonható; ? egységes, szabványos szolgáltatáskészlethez lehet hozzáférni. A VAN kezeloknek rendszerint a hálózat csomópontjaiban viszonylag nagy teljesítményu számítógépük van. Valamennyi csomópont a legtöbb hálózati funkcióhoz hozzájárul vagy nyújtani képes azokat az adattárolás kivételével, melyet 1-2 helyre lehet koncentrálni. A használók közvetlenül vagy híváskezdeményezés útján csatlakoznak a hálózati csomóponthoz, ami nem csak más elofizetokkel létrejövo kapcsolatot jelent, hanem a csomóponti számítógépek szolgáltatásainak igénybevételét.

41


2.3.2 Az EDI és a hálózat Az EDI számára a távközlo hálózatot sokféleképpen lehet kialakítani. A megfeleloen muködo távközlorendszer kiválasztása gondos körültekintést igényel. Olyan megoldásra van szükség, amely az összes EDI-partner rendszerével lehetové teszi az együttmuködést. Az alkalmas távközlési formáknak alapvetoen két változatát használják: a közvetlen (a végpontok közötti) összeköttetést vagy a szolgáltatóközponton (clearing center) keresztül való közvetett összeköttetést. A két partnernek meg kell egyeznie, hogy a kommunikáció során milyen hálózato(ka)t és milyen kommunikációs protokoll(oka)t használnak. Pont-pont közötti közvetlen átvitel esetén ez a megállapodás a két EDI-partner (a küldo és a fogadó) között jön létre. Szolgáltatóközpont igénybevétele esetén a két EDI-partner a szolgáltatóközponttal köt egy-egy külön megállapodást. A szolgáltatóközpont sokféle protokoll szerint képes muködni, áthidalva, konvertálva a különbözo egyedi megoldásokban rejlo különbségeket. Így lehetové teszi a partnereknek, hogy bármely új partnerrel úgy kommunikáljanak, hogy közben a saját, egyedi, eddig is alkalmazott kommunikációs protokolljukat használják. X.400 EDI munkaállomások

X.400 EDI munkaállomások

MHS MTS MTA

P1 UA P3

P1

MTA

UA

MTA

EDI szerver

P7 P3

Távoli EDI munkaállomás

MS

Internet

EDI www Forms szerver

Közvetlen EDI munkaállomás

17. ábra

Van szolgáltató

EDI és az Internet

A 17. sz. ábra nagy általánosságban ismerteti az EDI- és Internet-eszközöknek ismertebb vállfajait. Az ábra segítségével képzeljünk el egy olyan helyzetet, amikor egy cég vagy cégcsoport már rendelkezik egy olyan X.400 bázisú üzenettovábító rendszerrel, amelyre EDI-rendszerek épülnek - tehát az EDI-üzeneteket X.400 tárol és továbbít típusú hálózat továbbítja. Ugyanakkor viszont a cégünk abba a

42


kereskedelmi láncba, amelyik EDI segítségével muködik, és ahol beszállítók, viszonteladók stb. vannak, be akar iktatni egy web alapú elektronikus képviselot (ügynököt), amelyen keresztül szintén kereskedelemnek kell lebonyolódnia, de lehetoleg úgy, hogy a benne jelentkezo megrendelések miatt az EDIautomatizmusokat ne kelljen megtörni. Tehát például a webes formanyomtatványokon kitöltött megrendeléseket ne kelljen valakinek újra bevinni, hanem azok már ugyanúgy, EDI-formátumban kerülhessenek be a vállalat információs vérkeringésébe, mint az EDI alapú adatok. A példa alapján látható, hogy az Internet kétféle módon hat az EDI-kapcsolatokra, érdemes tehát a hatások vizsgálatát két részre bontani. Az egyik, amikor valóban az Internet-hálózatról beszélünk, a másik, amikor tulajdonképpen inkább webtechnológiáról van szó. Egyre másra jelennek meg a piacon azok az eszközök, amelyek az ún. egyszerre kezelik a tárol és továbbít alapon meno internetes üzeneteket, illetve az X.400-as üzeneteket. Ezek az eszközök azt teszik lehetové, hogy megfelelo biztonsági feltételek között az Internet hálózatát is lehessen adatátviteli útként használni, ami jelentos költség megtakarításokat eredményezhet. Nemzetközi tapasztalatok bizonyítják, hogy egy ilyen megoldás gyakorlatilag is megvalósítható, csakhogy a hiányzó titkosítási, biztonságtechnikai megoldások körülbelül majdnem ugyanakkora költséggel terhelik meg, mint ha egy biztonságosabb hálózatot használnánk. Az Internet másik rétege a webtechnológia. Amikor az Interneten a webet használjuk, sokak szerint tulajdonképpen az Internetnek az egyik legbiztonságosabb részébe lépünk be. Ez lehet, hogy igaz is. Ilyenkor a webek mögött formanyomtatvány-tárak állnak, és a kommunikáció végül is ezeken a formanyomtatványokon keresztül történik, majd ezeknek megfeleloen épülnek fel az EDI-üzenetek is. A web tulajdonképpen egy elektronikus közvetíto közeg, amelynek révén be lehet kapcsolódni egy akár EDI alapon muködo kereskedelmi láncba is. Ugyanakkor e mögött a felhasználói felület mögött nyilvánvalóan muködnek valamilyen üzleti tranzakciók, amelyek segítségével például a megrendelések teljesítése, a kiszállítás és az ezzel kapcsolatos pénzügyi dolgok lebonyolódnak. Ezek a tranzakciók olyan alkalmazások között bonyolódnak le, amelyek között az EDI értelemszeruen elsoként kerül szóba. Tehát a webtechnológia és a formanyomtatványokra épülo EDI-technológia összevonása célszeru.

43


Nemzetközi szolgáltatók A Nemzetközi Értéknövelt Hálózati Szolgáltatók (International Value Added Network Service Providers - IVAN-s) nyújtják leggyakrabban a távközési alapot az EDI-hez. Az USA-ban szinte kizárólagos alapot jelentenek, míg Nyugat-Európában elsosorban a nagyobb, amerikai tulajdonrésszel is rendelkezo multinationális cégek EDI rendszerei számára. A legtöbbször az „alap” értéknövelt szolgáltatás az üzenetkezelés, amire további értéknövelt szolgáltatások épülnek. A legtöbb IVAN a telefon behívásra, valamint a bérelt X.25 elérésére készült fel, általában az aszinkron, az SNA, a TCP/IP és az X.25 protokollokat támogatják. Hazai szolgáltatás A MATÁV Rt. a GEIS-tol (General Electric Information Service) vásárolt licence felhasználásával építette ki az EDI-szolgáltatást. (A GEIS Európa legnagyobb EDI, E-mail és informatikai szolgáltatója.) A MATÁV Rt. EDI-szolgáltatása a rEDInet, amely biztosítja az EDI-, és a nem EDI fájl átvitelt valamint az elektronikus levelezést. A rEDInet elektronikus „postahivatalnak” vagy elektronikus okmányrendezonek tekintheto, biztosítja az elektronikus üzenetek tárolását, ellenorzését és továbbítását. Minden üzenet az elofizeto postaládáján keresztül az elofizeto által bérelt levélszekrénybe kerül, ahonnan igényei szerint férhet hozzá az információhoz. A szolgáltatás folyamatos, nem igényli a partnerek kommunikációs találkozójának egyeztetését. A fobb szolgáltatások a következok: ? Partnernyilvántartás. Minden elofizetorol adatbázisban tartja nyilván a vele kapcsolatban álló elofizetok adatait, és azt, hogy az elofizeto milyen szabványok és paraméterek szerint kíván velük forgalmazni. ? Levélszekrény kezelés. A felhasználók bármikor lehívhatják levélszekrényükbol a bejövo üzeneteket, okmányokat. A rendszer sürgosségi fokozatok szerint sorolja és dolgozza fel az üzeneteket. ? Vételi sorrend. Az elofizeto meghatározhatja, hogy a számára érkezett üzeneteket milyen sorrendben kívánja megkapni különbözo szempontoknak megfeleloen (üzenettípusok, egyéb jellemzok). ? Csereszintu szolgáltatás. A rendszer nem ellenorzi a formátumot, csak a címzés kötelezo rovatainak kell szerepelnie. ? Okmány szintu szolgáltatás. A rendszer ellenorzi az okmány formátumát és típusát. ? Partnerkapcsolatok. Zárt: az elofizetok csak akkor léphetnek kapcsolatba egymással, ha egy elore bejegyzett csoport tagjai (pl. egy vállalat egyes részlegei). Partnerspecifikus: minden kapcsolat egyénileg definiált.

44


? Elektronikus levelezés funkció. Az elofizetok üzleti partnerei közötti elektronikus levelezési szolgáltatást is biztosít. ? Adatbiztonság. Az elofizetok kétféle azonosítóval rendelkeznek: egy az egész világon garantáltan egyedi azonosítóval, az ún. EAN számmal, valamint a rendszer belso azonosítójával. Az adatbiztonságot szolgálja, ha az elofizetok egymás közötti megállapodásukban pontosan meghatározzák kommunikációjuk jellemzoit, melyek alapján a szolgáltatás csak a bejegyzett okmánycseréket engedélyezi. A rendszerbe csak jelszóval lehet belépni, minden muvelet naplózásra kerül és utólag is nyomonkövetheto. A fokozott biztonságot igénylo elofizetok üzeneteiket titkosítva is elküldhetik egymásnak, megállapodásuknak megfeleloen. A rendszer támogatja az EDIFACT, ANSI X.12, ODETTE, EANCOM szabványokat. A rendszerhez a hagyományos telefonhálózati modemmel lehet csatlakozni. A rEDInet és a MATÁVnet szolgáltatást követoen bevezetésre kerül az X.400 alapú üzenetkezelo rendszerre épülo MATÁV400 szolgáltatás. A MATÁV400 szolgáltatás elsosorban az ember-ember közötti tároló-továbbító jellegu elektronikus kommunikációt szolgálja. Az ilyen rendszerek jellemzo szolgáltatásai az üzenetek elkészítésén, feladásán, tárolásán, továbbításán és kézbesítésén felül a nyugták kezelését, szétosztólisták használatát és különféle formátumátalakításokat is magukban foglalják. Az X.400 a tárol-továbbít üzenorendszerek funkcionális szabványkészlete lehetové teszi egy szabályozott, nyilvános üzenoszolgáltatás létrehozását, amely egyben a különféle üzenorendszerek integrációs platformját is adja. A hasonló lehetoséget nyújtó rendszerek közül az X.400 kitunik sokoldalú funkciókészletével, egyértelmu címzési rendszerével, biztonságával és megbízhatóságával. Így alkalmassá válik arra, hogy a szervezetek közötti professzionális elektronikus levelezés eszköze legyen. A MATÁV400 szolgáltatás egy teljes nemzeti nyilvános rendszerre (ADMD) épül, amely a korszeru 1988/92-es szabványoknak felel meg. Jelenleg alapvetoen személyközi üzenoszolgáltatásra van felkészítve, de elvileg alkalmas arra is, hogy az EDI egyik hozzáférési közege legyen. A megfelelo alkalmazói programfelületek (API-k) révén kis erofeszítés árán pedig lényegében tetszoleges alkalmazáshoz illesztheto. A MATÁV400 átjárót is biztosít más rendszerekhez, egyelore az Internet- és a faxátjáró emelendo ki.

45


A MATÁV400-hoz alapvetoen kétféle szinten lehet csatlakozni. Az egyéni használók megszokott windows-os munkakörnyezetét csupán a megfelelo kliensprogrammal és - amennyiben nincs - modemmel kell kiegészíteni. A PRMDként csatlakozó vállalati rendszerek a megfelelo kommunikációs szerveren keresztül csatlakozhatnak. A MATÁV400 számos lehetséges alkalmazása közül néhány példa: ? belso levelezés többtelephelyes vállalatban; ? levelezés üzleti partnerekkel; ? államigazgatási, önkormányzati információcsere; ? távmunka. 2.4 Az EDI-szoftver EDI-kezelo Alkalma- <–––> zások <–––>

Alkalmazási interfész

Konverter (átalakító)

Távközlési <–––> Hálóinterfész <–––> zatok

Táblázatok és paraméterek: - Üzenetformátumok és -változatok - Partnerek, ügyfelek adatai - Hálózati profil (adatok, beállítások) - EDI-üzemeltetési profil (adatok, beállítások)

18. ábra

Az EDI szoftverek alapfunkciói

Egy EDI-szoftver az EDI minden folyamatát segíti, beleértve a kereskedelmi partnerek és kereskedelmi kapcsolatok kezelését, az okmányok fordítási, építési, leképezési muveleteit, továbbá a távközlési, a jelentési, az adatkövetési, az alkalmazási, beillesztési és az automatizálási feladatokat. Amennyiben moduláris a felépítése, akkor elosegíti, hogy egy sor feladatot elvégezzen mind egészen kicsi cégek, mind nagyvállalatok számára, akik az EDI-t saját nagygépi rendszereiken futó egyedi alkalmazásaikkal akarják összeilleszteni. Minden egyes modul az elektronikus kereskedelem bizonyos folyamatát kezeli. A 18 sz. ábra egy EDI szoftver alapfeladatait mutatja be. 2.4.1 A kommunikációs interfész A kommunikációs interfész feladata, hogy a kommunikációs protokollnak megfeleloen biztosítsa a partnerek közötti adatcserét, felépítse az alkalmazások

46


közötti kapcsolatot, lebonyolítsa az adatcserét, ellenorizze, nyugtázza és lebontsa a kapcsolatot. Abban az esetben, ha az egyes partnerekkel a kommunikációt különbözo protokollok szerint kell lebonyolítani, a kommunikációs interfész tegye lehetové az eltéro hálózatok és protokollok közötti választás beállítását. Az EDI-szoftver általában egy vagy több értéknövelo hálózatot (VAN) is támogathat. Ha a használó a kommunikációt VAN segítségével oldja meg az EDIszoftvernek biztosítania kell a: ? hálózati be- és kilépést. (A szoftver kezeli a modemet, szabályozza a kommunikációs muveleteket); ? a postaládában található üzenetek kiolvasását és elokészítését a további feldolgozásra; ? naplózást és archiválást. 2.4.2 Konverter A konverter biztosítja a házi állomány adatformátuma és az EDI-üzenet formátuma közötti átalakítást (konverziót). A konverzió során a házi állomány adataiból a konverter EDI-üzenetformátumot készít és ezt küldi el a partnernek a kommunikációs interfészen keresztül. Fordított esetben a konverter a kommunikációs interfész által fogadott EDI-üzenetformátumot alakítja át a házi rendszer által kezelheto formátumra. Ez azt jelenti, hogy két szintaktikai szabálykészletet kell alkalmazni, az adatokat át kell rendezni, át kell strukturálni, a kódolt adatelemeknek pedig rendelkezni kell a szükséges kódokkal. Szükség esetén ellenorzo adatokat is elo kell állítani és ezeket hozzá kell adni az üzenethez. Ezenkívül, ha a házon belüli és a külso karakterkészletek eltéroek, akkor kódkonverzióra is szükség lehet. A konverter felépítése a két kezelendo szintaktikai szabálykészleten múlik. A két eltéro szintaktika telepítése után létre kell hozni az üzenetek közötti konverziót vezérlo táblázatokat vagy paramétereket is. Ezek segítségével történik az egyes elemek alapértékeinek automatikus beállítása. A házi alkalmazás kódkészlete általában eltér az EDIFACT, vagy más nemzetközileg szabványosított kódkészlettol. A konverter a házi rendszerben alkalmazott kódokat kódtáblázatok segítségével szabványos kódokká alakítja az üzenet elküldése elott. Üzenetek fogadásakor hasonló, de fordított folyamat zajlik le. A konverzió egyaránt jelent szintaktikai, szemantikai vagy strukturális konverziót.

47


Az átalakítás során alapveto szerepet töltenek be a kódok, így a partnereknek az EDI alkalmazása elott meg kell állapodniuk a közösen használt kódkészletben, valamint a kimeno EDI-táblázatoknak és -paramétereknek a formátumában. A konverterek rendszerint több EDI-szabványt és több üzenettípust is képesek kezelni. Ehhez - ha ez korábban nem történt meg - fel kell készíteni a konvertereket. Elofordul, hogy ezt a felkészítést egy külön fejlesztoprogram segítségével végzik. A felkészítés alkalmával meghatározzák az alkalmazandó EDI-szabványt és az üzenetmaszkot (subset). Egy vagy két üzenet esetében a házi alkalmazás fejlesztése is elegendo a konverzió végrehajtásához, ugyanakkor több üzenet esetén a megoldás már nem költséghatékony. Üzenet módosításakor karbantartási nehézségek jelentkezhetnek. Számos alkalmazás esetében a házi fájlok nem tartalmazzák azokat az adatokat, amelyek az átvitelhez szükségesek. Elsosorban a szolgálati szegmensekben találunk ilyen információkat (UNB, UNG), vagy pl. a teljes neve és címe a különbözo szervezeteknek az adatok származásának ismerete miatt. Ez a probléma egy konstans adatokból álló paraméter fájl segítségével megoldható. A konverter muködése három szakaszra bontható: 1. A szoftver eldönti, hogy melyik üzenet legyen használva, amit vagy a felhasználó instrukciói (billentyuzet segítségével), vagy batch fájl, vagy egy a feladatok idobeli lefolyását leíró program határoz meg. Ez utóbbi akkor használatos, ha az üzenetek valamilyen idoponthoz köthetok, vagy az elvégzendo feladatok sorrendje egyértelmu meghatározását jelent. 2. A szoftver megkeresi az üzenethez szükséges adatok sorrendjét, mely egy táblázat segítségével történhet. Az adatok kódolt formáját egy kódjegyzék (UNTDED) alapján határozza meg. A táblázatban az adatokra vonatkozóan a jelentéstartalmuk mellett a hosszuk is, valamint belso felépítésük (betuk, számok) és más információk is megtalálhatók. 3. A szoftver megkeresi a házi szoftverben a szükséges adatokat, átalakítja a szabvány által eloírt hosszúságra vagy kódra, hozzáad néhány rögzített mezot és a szintaktikai szabályok szerinti írásjeleket. Adatok vételekor hasonló folyamat játszódik fordított sorrendben. Ekkor szükséges lehet a kapott üzenet felosztása, mivel egy EDI üzenet akár több felhasználói adatbázishoz csatlakozhat.

48


2.4.3 Alkalmazási interfész Az alkalmazási interfész teremti meg a kapcsolatot a konverter és a házi alkalmazás között. Megvalósítása eltéro, attól függoen, hogy a konverter és az alkalmazás ugyanazon a számítógépen fut vagy mindketto külön gépen. Az elobbi esetben a konverter és a házi alkalmazás közötti kapcsolatot egy ideiglenes fájl segítségével lehet megoldani. Abban az esetben viszont, ha az adatátvitelt egy külön számítógép vezérli és a házi alkalmazások valamilyen nagygépes rendszeren futnak, a két gép közötti kommunikáció egy belso protokoll szerint történik. Ha az EDI több alkalmazást is kiszolgál, célszeru a kapcsolatot egy közös interfész segítségével megoldani. Így a feladat az alkalmazások közötti adatcsere megoldása, amely „házon belül” megoldható. Ez egyszerusíti a rendszer késobbi karbantartását is. A konverzió és a kommunikáció lebonyolításához és ellenorzéséhez szükség van egy olyan kezeloszoftverre, amely egy adott idoterv szerint küldi vagy lehívja az üzeneteket, rögzíti a kommunikációs eseményeket, kezeli a nyugtázásokat, felügyeli a konverziókat stb. Ezenkívül a szoftver tartalmazhat üzenettárolót is, amely gondoskodik az üzenetek kötegelésérol és az adatok idoterv szerinti továbbításáról, idozítésérol. Nagyobb szervezetekben az EDI-t kezelo szoftver magasabb szintu funkciókat is elláthat. Belso szolgáltatóközpontként kezelheti például az egyes vállalati részlegek közötti EDI-forgalmat. Az EDI telepítésének legnehezebb és legköltségesebb része az EDI-szoftver és az alkalmazási szoftverek integrálása. Az integrálás során gyakran okoz problémát, hogy egyes adatelemek hiányoznak a házi állományból, vagy a házi rendszer és az EDI-rendszer egyes adatelemei nem feleltethetok meg egymásnak, az adatmezok hossza eltéro. A szoftvereket annak érdekében, hogy a már meglévo alkalmazásra gyakorolt hatásuk a kezdeti szakaszban a leheto legkisebb legyen, gyakran EDI-modulokkal egészítik ki. Ezek a modulok a meglévo adatbázisból vagy fájlból gyujtik ki az adatokat a kimeno EDI-üzenet számára, vagy pedig a bejövo EDI-üzenet ellenorzése után frissítik a házi adatokat.

49


2.4.4 Üzemeltetés Az üzemeltetésért az EDI-kezelo szoftverfelelos. A szoftver látja el az alábbi feladatokat: Naplófájlok készítése. A naplófájlok áttekinthetoen tartalmazzák az összes elküldött és fogadott üzenetet, valamint az elküldött üzenetekre érkezo visszaigazolásokat. A fájlok tartalmazzák az üzenetküldés és -vétel pontos dátumát és idopontját, az alkalmazások és személyek nevét, az üzenet hosszát stb. Muveletjegyzék eloállítása. A muveletjegyzék nagyon hasonló a naplófájlhoz. Segítségével nyomon követhetoek az üzenetek. Helyreállító állományok létrehozása. A helyreállító állományok segítségével hiba esetén visszaállíthatók az üzenetek eredeti formáikba. Hibajelentések készítése. A hibajelentéseket gyakorta a konverziós szoftver állítja elo. A jelentés tájékoztatja a használót az adatsérülésrol, hibás adatküldésrol vagy vételrol. Állapotjelentés elkészítése. Az állapotjelentés az üzenetek mindenkori állapotát tükrözi. (Pl. elküldve, konvertálva stb.) Archiválás. Az üzeneteket a késobbi visszakereshetoség érdekében a rendszer archiválja. Itt érdemes még megemlíteni a biztonság kérdését. A rendszer és a kommunikáció biztonságát az EDI-szoftver, illetve a kommunikációs szoftver biztosítja. A biztonság kérdéskörébe éppúgy beletartozik a kommunikációs hibák helyreállítása, mint a hozzáféréssel és az üzenetek olvashatóságával kapcsolatos jogosultságok megfelelo kezelése. Az EDI rendszert többnyire egy rendszergazda felügyeli. Egy speciális jelszóval rendelkezik, mely feljogosítja új felhasználók regisztrálására, valamint a hozzáférési szintek megváltoztatására. A rendszergazdának lehetoséget kell biztosítani a végrehajtandó feladatok sorrendjének ellenorzésére, az üzenetek és tárak használata közbeni aktualizálására. Feladatai közé tartozik a hibás muködés során a manuális beavatkozás, mellyel a hiba megszüntetheto. 2.4.5 További funkciók Egy modulárisan felépített, összetett szolgáltatást biztosító EDI-szoftvernek az elozoekben említetteken kívül további funkciói lehetnek:

50


? A rendszergazda munkáját segítheti egy modul, amely a felhasználók hozzáférését ellenorzi az EDI-szoftverhez, illetve annak elemeihez. ? Szükséges lehet a feladatok elvégzését támogató adatbázis, amely az üzleti partnerek adatait alkalmazza. ? Az automatikus muködést támogató modul segítségével meg lehet tervezni az EDI tevékenységet úgy, hogy a szoftver az EDI muveleteket naponta automatikusan elvégezze. Így lehetové válik például a bejövo okmányok automatikus fordítása a kívánt formátumba, azok szétosztása a helyi hálózaton, vagy a bejövo okmányok automatikus kinyomtatása. Természetesen a felhasználó igényeihez és pénztárcájához mérten számos funkcióval lehet ellátni az elektronikus adatcserét kezelo szoftvert. A szoftverkészíto cégek kész programcsomagokkal állnak az üzletfelek rendelkezésére, de az egyedi igényeket is ki tudják elégíteni. 2.4.6 Szoftverkategóriák Az EDI szoftvereknek három kategóriáját különböztetjük meg: 1. Általános üzenetkezelo. Ez a legáltalánosabb formája az EDI szoftvernek. Az

üzenetkezelo elvégzi a formátum átalakítást, az üzenet menedzsmentet és a kapcsolattartási feladatokat a felhasználóval. Gyakran a kommunikációs oldalon korlátozott a szerepe. Az üzenetkezelok hozzáférhetok PC-kre, minigépekre és a fobb EDI hálózatokra. Általában akkor használják, ha egy jól kifejlesztett házi alkalmazás felhasználói interfésszel rendelkezik. 2. Felhasználói rendszercsomag. Az EDI-szolgáltatás egy részét nyújtja. Mivel

úgy tervezték, hogy az egyéni rendszerekkel együtt muködjön, gyakran korlátozzák a támogatott kommunikációs fajtákat, de az adott EDI-szolgáltatásra optimalizálják és kezdetben csak kisebb rendszert igényel. Az ilyen csomagok a házi szoftverek nagyobb módosítását igénylik, hogy a fájlok pontosan a kívánt formában álljanak elo. 3. EDI átjárók. A cégeknek nem jelent nehézséget, hogy létrehozzák saját EDI

rendszereiket, melyek magukba foglalják a „tárolás és továbbítás” lehetoségét. Az ilyen átjáróknak sok különbözo hálózatot és szabványt kell összehangolni, de szükséges lehet a cégen belüli EDI alkalmazások kiterjedését ismerni.

51


2.5 Biztonság és adatvédelem az elektronikus kommunikációban Az elektronikus okirat veszélyeztetései Az elektronikus okiratok bevezetésének alapveto kérdése, hogy azok védelme keletkezésüktol kezdve folyamatosan biztosítva legyen, és errol a dokumentum használói kelloképen tájékozottak legyenek. Az elektronikus okirat biztonságát (mint általában az adatokét) szándékos és véletlenszeru veszélyeztetések fenyegetik. Az elektronikus adatcsere során a védelem tárgya az elektronikus okirat, ezért az elektronikus adatcsere veszélyeztetése alapvetoen az abban kezelt elektronikus okirat veszélyeztetését vonja maga után. Az információk felfedése Az elektronikus okmányok által hordozott információk kívülállók által történo felhasználása többnyire sérti az okmány tulajdonosának érdekeit, ezért azok bizalmasságát meg kell orizni, vagyis a külso és belso jogosulatlan személyek általi megismeréstol védeni kell. Az információk szennyezodése Az elektronikus okirat értékét veszti a használók számára, ha a tartalmazott információk idegen, jogosulatlan információkkal szennyezodnek, ezért az elektronikus okirat sértetlenségét védeni kell. Az elektronikus adatcsere eszközeinek jogosulatlan fel használása Az elektronikus adatcsere eszközeivel való visszaélés és azok jogosulatlan felhasználása az elektronikus okmányok információtartalmának sérülését, módosulását vagy elvesztését okozhatja. Az elektronikus adatcsere szolgáltatásának megtagadása Az elektronikus okiratok terjedésével az ügyintézésben mindinkább az elektronikus adatcserére hagyatkozunk majd, így a szolgáltatás elvesztése az elektronikus okiratok üzemszeru felhasználását akadályozza meg és következménye szinte beláthatatlan, ezért a szolgáltatás megtagadását, lehetoségének a felderítését meg kell akadályozni. Intézkedések az elektronikus adatcsere védelmében A biztonsággal foglakozók már számtalanszor kijelentették, hogy százszázalékos védelem nincs. Ez természetesen igaz az elektronikus adatcserére is.

52


Az itt megadott intézkedések csak azok az általánosítható logikai védelmi intézkedések, amelyeket még egyéb, fizikai, adminisztratív és logikai intézkedésekkel szükséges kiegészíteni, hogy zárt, teljes köru, folyamatos és a kockázatokkal arányos védelem, vagyis a biztonság létrejöjjön. Rejtjelzés A rejtjelzés egy olyan szolgáltatás hozzáadását jelenti, amely lehetové teszi az elektronikus okiratok - szimmetrikus vagy aszimmetrikus kriptográfiai technikák alkalmazásával - rejtjelzését és megfejtését, továbbá a rejtjelkulcsok kezelését (eloállítását, szétosztását, tárolását és felhasználását). Digitális aláírás A digitális aláírás egy olyan szolgáltatás hozzáadását jelenti, amely - aszimmetrikus kriptográfiai technikák alkalmazásával - lehetové teszi az elektronikus okiratok eloállítójának vagy küldojének azonosítását, az elektronikus okirat hitelességének ellenorzését és letagadhatatlanságának biztosítását. A digitális aláíráshoz is szükséges a kulcsok kezelésének megoldása. Hozzáférés-ellenorzés Az eszközök és személyek egymáshoz rendelésével biztosítható, hogy adott eszközt csak az annak használatára feljogosítottak kezelhessenek. A hozzáférés-ellenorzo mechanizmusok általában hozzáférés-ellenorzo listákkal (ACL) és jelszóval együtt látják el szerepüket. A hozzáférés-ellenorzés általában az eszközök használatának lehetséges szintjét is meghatározza adott személy vonatkozásában. Hitelesítés-kicserélés A hozzáférés-ellenorzésen túl a felhasználó személyét, az elérendo eszközöket hitelesíteni is szükséges, hogy csak hiteles eszközök kerülhessenek kapcsolatba egymással. Ezt a különbözo hitelesíto mechanizmusok teszik lehetové. Hites bejegyzés A származásra, az integritásra, az elküldésre és az átvételre vonatkozó információknak egy kölcsönös bizalmat élvezo harmadik félre (például közjegyzore) való rábízásával ezen információk vita esetén megbízható helyrol állnak rendelkezésre. Integritásvédelem Az adatsérülések észlelésére, hibajavításra integritásvédelmi mechanizmusok használatosak. A védendo adattartalomhoz egy, az adattartalomból képzett értéket hozzáadva felfedhetok - a képzésre használt függvénynek megfelelo mértékben - a módosulások.

53


3

Az EDI szerepe a fuvarozásban

A tapasztalatok szerint az EDI bevezetése ott célszeru, ahol nagymennyiségu adatot gyakran cserélnek az üzleti partnerek. Ilyen igények a fuvarozás során is megjelennek. Ezen túl, a fuvarozási tevékenységek sajátosságai is ösztönzoen hathatnak az EDI alkalmazására. Ilyen sajátosságok a következok: ? a fuvarozási tevékenység nagy területet fed le; ? a fuvarozásra átvett áru rendszerint összetett, sok áruféleséget tartalmaz; ? a szállítási útvonal rendszerint ugyancsak összetett, az útvonalon több résztvevo érintett a fuvarozásban; ? a fuvarozás egyik leggyakoribb és legfontosabb kritériuma az árutovábbítás sebessége; ? az új termelési és elosztási módszerek (pl. JIT - Just In Time - éppen idoben) pontos szállítási és kiszolgáltatási idoket igényelnek; ? a hatékonyság növelése a fuvarozás minoségi elemeinek fejlesztésével érheto el. Ezek a sajátosságok és a fuvarozással szemben támasztott egyre növekvo igények megkövetelik a gyors és pontos információ továbbítást. A számítógépek használata szélesköruen terjedt el a közlekedésben, elsosorban két területre koncentráltan: ? irányítási folyamatok tervezése; ? adattárolás, -kezelés, -feldolgozás, -továbbítás. Az elso esetében jelenti az útvonal megtervezését, a költségek csökkentése érdekében az üresfutás minimalizálását, a jármuvezetok munkaidejének tervezését stb. Az információs tevékenységet igénylo feladatoknál adatbáziskezelést, kommunikációs kapcsolat létrehozását, fenntartását. A gyujtorakományok többségét kisebb egységekben a közlekedési hálózat különbözo (logisztikai) központjaiban gyujtik, elszállítják egy másik központba, majd újra szétosztják. A menedzsmentje ennek a gyujto hálózatnak és kézbesíto pontoknak egy olyan feladat, melyet a számítógép nagy mértékben tud támogatni. Az EDI ideális megoldása lehet ennek a feladatnak. A gyakorlatban a legtöbb cégnek már megvoltak a saját tulajdonú rendszerei ehhez a funkcióhoz, még a vonatkozó szabvány üzenetek megjelenése elott. A nemzetközi árufuvarozás során gyakran nagyobb várakozások adódnak az országhatárokon a vámellenorzés miatt. Az EDI segítségével a vámvizsgálat elore elkészítheto, amit csak egy rövid fizikai ellenorzés egészít ki a határon. A hibák

54


lehetosége jelentos mértékben csökken. A legtöbb országban a vámhatóság kívánatosnak tartja az EDI-t, ezért ez az EDI használatának leggyorsabban növekvo területe. Mivel az áruk fizikai helyváltoztatása idot vesz igénybe, az egyik legnagyobb elonye az EDI-nek, hogy a fuvarozás folyamatát képes ellenorizni. 3.1 Az EDI alkalmazásával járó elonyök, hátrányok és változások 3.1.1 Elonyök Az EDI alkalmazásával járó elonyök között feltétlenül meg kell említeni a következoket: ? gyorsabb kommunikáció; ? kisebb adminisztráció, kevesebb papírmunka; ? adatbeviteli hibák csökkenése; ? költségcsökkenés; ? bizalom növekedése, a kapcsolatok minoségének javulása a partnerek között; ? ösztönzés a vállalati folyamatok ésszerusítésére; ? új üzletek szerzése; ? szakértelem pótlása; ? független a természetes nyelvtol. A továbbiakban néhány számadattal illusztráljuk az elonyöket, melyek a COST (Európai Tudományos és Muszaki Együttmuködés) 320. számú projektjének zárójelentésébol származnak. A felmérést kérdoívekre kapott válaszok alapján végezték, fuvaroztatók, fuvarozók, szállítmányozók és közlekedési hatóságok megkérdezésével 1991-ben. Gyorsabb kommunikáció Az EDI alkalmazásával megváltoznak a vállalatok közötti kommunikáció módjai és csatornái. A korábban levélben esetleg faxon továbbított információ most távközlési hálózatokon, strukturált adatállományokkal történik. Az elektronikus okmányok (üzenetek) eloállítása, elküldése automatikusan történik. A fogadott adatok ugyancsak automatikusan épülnek be a vállalati adatbázisokba. Az elektronikus üzenet ellentétben a papírokmánnyal néhány percen belül megérkezik a címzetthez. A használók az EDI elonyei közül éppen ezt tartják a legfontosabbnak (69%). A dolgozók feladata a folyamatok elokészítése, elindítása és ellenorzése. Mindez a papíralapú kommunikációnál lényegesen kevesebb idot igényel, de elektronikus

55


adatcsere során a megtakarított ido a tényleges feladatokra (szolgáltatás, termelés) és nem a kommunikáció lebonyolítására fordítható. Kisebb adminisztráció, kevesebb papírmunka A strukturált adatok számítógépes továbbítása és fogadása lehetové teszi, hogy a partnervállalatok összekapcsolhassák ügyviteli rendszereiket. Ez az automatizáltság növekedését jelenti, egyúttal a jogosultságok függvényében közvetlenül elérhetové teszi az adatokat a használók számára. Az adminisztrációs terhek jelentos részét így a számítógépes alkalmazások veszik át. Az adatok cseréje és az adatbázisokba történo beépítése nem papírok, hanem alkalmazások segítségével történik. Adatbeviteli hibák csökkenése Az adatbevitel (gépelés) során mindig fennáll a veszély, hogy hibás adat kerül a rendszerbe. A kézi adatbevitelek számának növekedésével a hibás adatok száma is no. Minden eszköz és eljárás tehát, amely csökkenti a gépelési szükségletet az adatok megbízhatóságát javítja. A hibátlan adatforgalom a partner legfobb érdeke, hiszen kevesebb idot és munkát kell fordítania a hibás adatok helyesbítésére. Kiváltképp igaz ez olyan szervezetekre, mint az APEH és a VPOP, ahol a hibás bevallások és nyilatkozatok igen sok idot és energiát visznek el feleslegesen. Költségcsökkenés Az adminisztráció és a papírfelhasználás csökkentésével költségek takaríthatók meg. Ugyanez igaz az elozoekben említett hibaszázalék visszaszorítása esetében is. A folyamatok racionalizálása szintén jelentos költségcsökkento hatású lehet. Az EDI bevezetésének egyik mozgatórugója az volt, hogy a nagy áruházláncok így akarták kisebb beszállítóikra hárítani adatbeviteli költségeiket. A költségmegtakarítás dönto része magában a termelési, üzleti folyamatban keletkezik. A kello idoben kello helyre küldött információval lerövidítheto a termelési ciklus. Ez azt jelenti, hogy csökkentheto a raktárkészlet, a gyors elektronikus vámkezelés révén az áru elobb felszabadítható. A just in time technika valamilyen fajta elektronikus adatcsere nélkül nem képzelheto el. Elektronikus úton a banknak küldött fizetési megbízás átfutási ideje szintén rövidebb. Számítógép számítógépnek küldi az információkat, így az okmánykészítési költségek is minimálisak.

56


A bizalom növekedése, a kapcsolatok minoségének javulása a partnerek között Az EDI-kapcsolat kiépítése többnyire ido- és költségigényes folyamat. Az így kialakított kommunikáció azonban erosíti a partnerek közötti rendszeres kapcsolatot, amely a bizalom erosödéséhez, ezáltal a kapcsolatok minoségének javulásához vezet. Az EDI kapcsolat kiépítését megelozoen a partnereknek - a technika és a szabványosítás mai állása mellett - még meg kell állapodniuk bizonyos technikai és üzleti kérdésekben. Rendszerint egy ún. adatcsere szerzodést kötnek, amely tisztázza a felelosség, a költségek és a muszaki megoldások kérdéseit. Az ehhez vezeto tárgyalásokon azok az üzletfelek, akik korábban legfeljebb telefonon érintkeztek, személyesen is találkoznak, és együtt dolgozzák ki a szerzodés rendelkezéseit. Ezáltal jobban megismerik egymást, nagyobb bizalommal lesznek egymáshoz, viszont no a kölcsönös függoségük is, mivel ma még az EDI-partner nem cserélheto le egyik napról a másikra, mert a kapcsolat kiépítésére fordított energia nagy. A megkérdezettek 30%-a tartotta az EDI legfontosabb elonyének a kapcsolatok megbízhatóságát. Ösztönzés a vállalati folyamatok ésszerusítésére A vállalaton belüli ügyviteli és információs folyamatokra legnagyobb mértékben az integrált ügyviteli és termelésirányítási informatikai rendszerek hatnak. Nem lebecsülendo azonban a külso kapcsolatok hatása sem. Az EDI legígéretesebb elonye és az elonyök érvényesülésének legfontosabb elofeltétele az ésszeru vállalatszervezés. Az EDI bevezetésével a belso és külso folyamatok, valamint maga a szervezet jobban a végzett funkciókhoz igazítható. Ha az EDI által kínált racionalizálási lehetoségeket nem használják ki, az EDI-t nem integrálják, akkor az új technika csak részmegoldás, esetleg többletterhet jelent bevezetojének. Ennek okai azok a változások, melyek az egyes szervezeti egységek leterheltségében következnek be. Például ha a beérkezo számlákat nem kell többé kézzel a belso, házi számítógéprendszerbe begépelni, mivel az maga fogadja és dolgozza fel azokat, akkor nyilvánvaló, hogy ezzel a könyvelés feladatai csökkennek, a számítástechnikai, informatikai osztályé szaporodnak. Ha az ilyen súlyponteltolódást nem követi szervezeti változás, akkor az EDI-tol várt elonyöknek csak a töredéke érvényesülhet. Mindez nem jelenti azt, hogy az elonyök érdekében rövid idon belül át kell alakítani a vállalat szervezetét és minden partnerrel egyszerre kell az EDI-t bevezetni. A bevezetés csak fokozatosan történhet. A kezdeti kisebb projektekkel gyujtött

57


tapasztalatokból kiindulva lépcsozetesen kell bekapcsolni az EDI-t a vállalat munkájába. A folyamatok ésszerusítésének feltétele, hogy az EDI szervesen illeszkedjen a belso informatikai rendszerhez, integrálódjon a belso folyamatokba, a termelésirányításba vagy az ügyvitelbe. Az integráció során az EDI kikényszeríti a folyamatok racionalizálását. A COST 320 kérdoívre kapott válaszok szerint a vállalatok 45%-nál befolyásolta az EDI az információcsere struktúráját. A legnagyobb mértéku változások a nagyvállalatoknál tapasztalhatók. Új üzletek szerzése A tapasztalatok szerint az EDI hatással van az új megbízások megszerzésére. A felmérés során megvizsgálták, hogy az árutovábbító vállalatok milyen mértékben jutottak új üzletekhez az EDI eredményeként. A megkérdezettek 32 százaléka úgy találta, hogy olyan új szerzodésekhez is jutott, amelyet kizárólag az EDI-nek köszönhet. 70%-uk egyetértett azzal, hogy az EDI az árutovábbító vállalatok egyik üzletpolitikai eszköze. A fuvaroztatók véleménye viszont már nem volt ilyen egyöntetu: az áruszállítási szolgáltatást rendelok kevésbé érzik választási kritériumnak az EDI-t. Szakértelem pótlása A kereskedelmi okmányok kitöltése általában szakértelmet kíván. Az EDI megjelenésével az okmányok kitöltése jelentos részben automatizálódik, így munkaero csoportosítható át. Ha van egy szoftver, amelyik az okmányt maga elkészíti, illetve összeállítja a házi rendszerbol, akkor ezzel az EDI szakmai ismereteket pótol. Az okmányok gépi eloállításának ellenorzése más jellegu feladatok ellátását igényli, mint korábban a papírokmányok kitöltése. Független a természetes nyelvtol Mivel az EDI nagy mértékben kódokra épül, így függetleníti a természetes nyelvtol. 3.1.2 Hátrányok Az elektronikus adatcsere bevezetésekor a változás kényszeruségébol adódóan számos negatívum is jelentkezik: ? Az EDI a feladatok, a munka átstrukturálását jelenti, ami a muködési folyamatokban bekövetkezo változásokkal jár együtt. ? A felelosségek is megváltozhatnak az EDI-rendszer bevezetésekor. Kisebb mértéku lehet a változás, ha a rendszer kiépítését, más rendszerekkel létrehozott

58


?

?

?

?

kapcsolatokat nagyfokú körültekintéssel hajtják végre. Ennek kapcsán az adatkezeléssel foglalkozókat a beruházási döntésekbe és a termelésbe is bekapcsolják. Az EDI kevésbé áttekintheto, mint a papír alapú rendszer. Gyakran az alkalmazottak vizuálisan is szeretnék látni, hogy „rendben mennek a dolgok”, ezért EDI-rendszer esetén is a monitor képernyojén vagy nyomtatásban megjelennek az információk. Ez elsosorban akkor fordul elo, ha az elvégzendo feladatok prioritását (sorrendiségét) kell ellenorizni. Néhány cég esetében a prioritások elosztásának és változtatásának módját a rendszerbe is be kell építeni. Az EDI rendszerek között vannak nagyon könnyen átalakíthatók és vannak olyanok, amelyek nagyon egyszeruen megvalósíthatók. Azonban a két cél egyszerre nem teljesül. Az egyszerubb rendszerek általában merevek. Sok használó oly módon fejlesztette rendszerét, hogy kihasználja a faxok nyújtotta elonyöket, elkerülve a postai kéréseket. Faxon ugyanolyan gyorsan lehet elküldeni az üzeneteket, mint EDI-vel. Számítógépekben lévo fax-kártyával és szoftverrel eloállítható a fax tartalma, sot a faxból az adatok is visszanyerhetok. Az EDI bevezetésének költségvonzata is van: ? A bevezetés költségterhei: hardver és szoftver eszközök beszerzése, telefonvonal és a kommunikációs eszközök üzembe helyezése, oktatás. ? Folyamatos költségek: a telefonvonalak bérleti díja, hívás- és üzenetküldési díjak, más kommunikációs költségek, eszközfenntartás, folyamatos oktatás. ? Reorganizációs költségek: a szervezet új formájának, esetlegesen az irodaköltözés és a létszámleépítés költségei. ? Tanulmányozás, döntéshozás költségei: legfontosabb és gyakran a legrejtettebb költségek a piackutatás, annak eldöntése, hogy használjunk vagy sem EDI-t, kiválasztani a szervezet muködéséhez a legmegfelelobb rendszert. A tanácsadók kétségkívül tudnak segíteni, de ennek is van költségvonzata.

Továbbá néhány technikai problémával is találkozunk: ? Elromolhat a számítógép, megszakadhat a telefonvonal. Meg kell oldani egy könnyu átállást valamilyen „tartalék” rendszerre, és ismerni kell annak is a muködését. ? Nem biztos, hogy létezik szabvány arra a feladatra, amit szeretnénk EDI-vel végrehajtani. Vannak még „betömetlen lyukak” speciális területeken. ? Fontos kérdés az üzem biztonsága. Az információknak nem szabad illetéktelen kézbe jutni, különösen igaz ez a pénzügyi EDI rendszereknél.

59


3.1.3 Egyéb változások A fuvaroztatók 14%-a jelezte, hogy az EDI miatt megváltozott az árufuvarozási szolgáltatást nyújtó partnereinek a száma, az EDI-ben kommunikálni képes árutovábbító vállalatoknak 23%-kal több megbízást adtak. A kérdoívre adott válaszok szerint az EDI miatt a fuvaroztatók 15%-a cserélt partnert: 8%-a más, „edizni” tudó vállalatot bízott meg, míg 7%-a megszüntette kapcsolatait azokkal a cégekkel, akik nem tudták az EDI igényeit kielégíteni. Azt a feltételezést, miszerint az EDI vonzóvá teszi a fuvaroztatók számára, hogy bizonyos árutovábbítási feladatokat is magukra vállaljanak (fuvarozás, szállítmányozás stb.), a megkérdezetteknek 40%-a fogadta el, 40%-a tagadta. A feltételezés az adatok szerint nem igazolódott. A fuvaroztatóknak ugyan megvannak a saját kapcsolataik, például a vámszervekkel, használják is a vámüzeneteket, de ennek az aránya nem túl nagy. Az alaptevékenységekre való specializálódás valószínusége a háttérbe szorítja azt a lehetoséget, hogy az EDI segítségével újabb tevékenységek is elvégezhetok házon belül. Látható, hogy az EDI-alkalmazás számos közvetlen és közvetett elonyt nyújt a vállalat számára. Sok esetben azonban - mint ahogy erre magyar példa is mutat - az elonyök mérlegelésétol függetlenül az EDI bevezetése kényszerként jelentkezik. Elofordul, hogy a fuvarozó vállalatnak nincs választása, ha meg akarja tartani megrendeléseinek zömét adó megbízójával a kapcsolatot. Az EDI tehát nem egyformán jelent elonyt a partnerek számára. Nem biztos, hogy egy sok beszállítóval rendelkezo gyártó (fuvaroztató) számára és kisebb partnerei számára azonos elonyökkel jár az EDI bevezetése. Korábbi - foleg nyugat-európai országok fuvaroztatóinál végzett - felmérés alapján megállapítható, hogy az EDI alkalmazásának vonzereje a közlekedési vállalatoknál eltéro a vállalatméret függvényében. A nagyvállalatok kezdeményezokészsége nagyobb mint a kisvállalatoké. Manapság az EDI a cégek számára versenyelonyt jelent, de hosszú távon ennek hiánya a piacról való kiszoruláshoz vezet. 3.2

Az EDI és a menedzsment

Az EDI a vállalaton belüli viszonyokra éppen úgy hatással van, mint a külso kapcsolatokra. Az EDI elonyeinek teljes kihasználásához a vállalatnak lényegesen módosítania kell belso folyamatait, többek között az információs rendszerhez kapcsolódó és a manuális folyamatokat, ami azután többnyire a szervezet és az alkalmazotti struktúra megváltozását is magával hozza.

60


Egy szervezet struktúrájának, folyamatainak és rendszereinek kialakulásakor meghatározó az a környezet, amelyben muködik. Mi történik azonban egy folytonosan és gyors ütemben változó környezetben'? Hogyan lehet a szervezetet felkészíteni a változásokhoz történo alkalmazkodásra? Hogyan lehet kiszakadni a szervezet által diktált gondolatkörbol és újrafogalmazni a megoldásokat? Milyen szerepe lehet ebben az informatikának, az információs rendszerek nyújtotta lehetoségeknek? A fenti kérdések megválaszolásában segítségünkre lehet az a szemlélet és módszertan, mely az utóbbi években az üzleti folyamatok újratervezése (Business Process Reengineering, BPR) néven vált ismertté. A Business Process Reengineering (BPR) nem más, mint az üzleti folyamatok alapveto átgondolása, radikális újratervezése, olyan kritikus muködési mutatók, mint a költséghatékonyság, a minoség, a gyorsaság egyideju és drámai növelése érdekében. Ez a definíció négy kulcsszót tartalmaz: alapveto, radikális, drámai, folyamat. Az alapveto jelentése a BPR kérdésfeltevésében rejlik. Mind a technológiai, mind a szervezeti tényezok elsosorban az olyan típusú kérdésekre keresik a választ, hogy hogyan javíthatnánk adott folyamatot, hogyan gyorsíthatnánk bizonyos eljárásokat. Például "Hogyan végezhetnénk a vásárlói hitelellenorzést hatékonyabban? Ebben a kérdésben benne rejlik, hogy szükségesnek tartjuk a vásárlói hitelellenorzést. A BPR alapvetosége abban rejlik, hogy alapkérdéseket feszeget: "Miért csináljuk így vagy úgy a dolgokat? Miért tesszük, amit teszünk, egyáltalán? A radikális szó a latin "radix"-ból ered, melynek jelentése: gyökér. A radikális újratervezés a problémák gyökerének felkutatását jelenti. A BPR az üzleti folyamatok ismételt feltalálását, felfedezését jelenti, a módosítás, továbbfejlesztés, hatékonyság helyett. A BPR által elérheto változások valóban drámainak tekinthetok, összevetve a legfobb vezetoi, illetve menedzsment technikákkal elérheto 10-15%-os növekedéssel. 10 %-os növekedés nem jelent túl sokat, hiszen kemény munkával (átszervezés, az információs rendszer fejlesztése) elért ilyen mértéku növekedést egyetlen nagyobb ügyfelünk kiesése kapcsán elveszíthetjük. Érdemesebb, tehát eroinket a drámai változásokat ígéro módszerek alkalmazására összpontosítani. A negyedik és egyben legfontosabb kulcsszó a folyamat (processz). Az üzleti folyamat olyan, egy vagy több input-tal rendelkezo tevékenységhalmaz, amely az ügyfél számára értékesülo outputot állít elo. A legtöbb szervezet és a benne dolgozó emberek nem "folyamat-orientáltak". Feladatokra, munkákra, emberekre, szervezeti struktúrára koncentrálnak.

61


Annak ellenére, hogy az információs technológia nagy szerepet játszik a folyamatok újratervezésében, a BPR nem azonos az automatizálással. A létezo folyamatok automatizálása nem jelent mást, mint hibás folyamatok elvégzésének hatékonyabb módját. A Business Process Reengineering nem azonos a szoftver-reengineeringgel sem. Ez utóbbi a létezo információs rendszerek újraépítését jelenti, modernebb eszközökkel, hatékonyabb architektúrák felhasználásával, s mint ilyen sokszor csupán bonyolultabb információs rendszereket eredményez, melyek a régi folyamatokat támogatják. A BPR különbözik a manapság elotérbe került downsizingtól is. Ez ugyanis sajátos kifejezés a kapacitáscsökkentésre, mely a csökkent igények miatt vált szükségessé. A downsizing azt jelenti "csinálj kevesebbet kisebb kapacitással", a BPR azt jelenti "csinálj többet kisebb kapacitással". A BPR szintén nem azonos az átszervezéssel, a szervezett struktúra laposabbá tételével, bár a reengineering eredményeként létrejöhetnek laposabb szervezeti struktúrák. A szervezetek problémáit ugyanis nem a szervezeti struktúrák, hanem a folyamatok hibás mivolta okozza. A BPR lényegét egy példán keresztül lehet megvilágítani. Ha egy sokat utazó üzletembert megkérdezünk, hogy mi módon tudnánk segíteni a munkáját, valószínuleg gondolkodás nélkül rávágja: szüntessük meg a repüloterek zsúfoltságát, tegyük rugalmasabbá a helyfoglalási, illetve átfoglalási procedúrákat, oldjuk meg a nagyvárosok forgalmi problémáit stb. Rengeteg ido és pénz felhasználásával ezek közül egyiket-másikat meg is tudjuk oldani, amelytol valóban egyszerubbé válik az üzletember helyzete, munkáját hatékonyabban tudja végezni. Ezidáig a példánkban nem kérdojeleztük meg az utazás hagyományos módszerét és nem tette ezt az üzletember sem. A BPR szemlélete induktív szemben a korábban tárgyalt és jelenleg uralkodónak tekintheto deduktív megközelítéssel. A deduktív megközelítés lényege a következo lépések egymás utáni végrehajtása: a probléma azonosítása, elemzése, megoldások keresése, azok értékelése, választás majd megvalósítás. Az induktív szemlélet fordított és ezért elso ránézésre kicsit furcsának tunhet. Elobb kell felismerni a hathatós megoldást (teleportáció), azután kell megtalálni a

62


problémát, amelyrol a szervezet esetleg még mit sem tud (a muködés és a struktúra a hagyományos helyváltoztatás által meghatározott viszonyokat tükrözi). Az alapveto hiányosság a deduktív megközelítésben az, hogy a szervezetek azt keresik, "hogyan használhatnák ki a technológia, a számítógépes információs rendszerek kínálta lehetoségeket arra, hogy növeljük a hatékonyságát annak, amit csinálunk", ahelyett, hogy azt kérdeznék, "hogyan használhatnánk ki a technológiát úgy, hogy lehetové tegye a számunkra azoknak a dogoknak az elvégzését, amit ez idáig nem csináltunk". Vizsgáljuk meg az eddig bemutatottakat az információs rendszerek szemszögébol egy konkrét BPR-alkalmazási eset ismertetésével. A General Motors egyik teljesen új egységének megvalósításánál kihasználta a lehetoségeket egy alapvetoen új beszállítói rendelési és szállítási folyamat bevezetésére. Nézzük meg milyen megoldásokat kínál a bemutatott technológiai és szervezeti tényezok következetes alkalmazása és milyen többletet nyújtott ehhez a BPR-szemlélet elozetes felhasználása. A beszállítói folyamatok kissé leegyszerusítve a következo módon zajlanak. A GM figyeli a raktárait és a gyártási elorejelzéseket. A két adat felhasználásával, ismerve a szállítási idoket megállapítja, hogy mikor, milyen alkatrészbol, melyik beszállítótól, mennyit kell rendelni. A megrendelést feladja, megvárja a szállítást. A szállítást visszaigazolja, az árut átveszi, raktározza, majd a számlát kiegyenlíti. A technológiai és szervezeti tényezok következetes alkalmazásával meg kell vizsgálnunk, hogy ez a folyamat kritikus-e a szervezet szempontjából, érdemes-e gyorsítani, mondjuk, a megrendelés kitöltését, vagy számottevoen javulna-e a helyzet elektronikus levelezést alkalmazva a megrendelések közvetítésére. Amennyiben a ráfordítás-haszon elemzésbol kiderülne, hogy érdemes bizonyos átszervezést végrehajtani, vagy bizonyos procedúrákat gépesíteni (például készletnyilvántartó és rendelésfigyelo számítógépes információs rendszer fejlesztése), akkor definiálható egy projekt, melyet végre kell hajtani a kituzött céllal, ido- és eroforráskerettel. Természetesen gondoskodni kell arról, hogy a megoldás egybeessen a szervezet informatikai stratégiájával, a minoségi paraméterek jól legyenek definiálva és betartsák oket, a megfelelo technológiát és eszközöket alkalmazzák. A fejlesztési, illetve bevezetési projekt végén várhatóan elértük a kívánt hatást, a folyamat egyszerubbé vált, felgyorsult. A megrendelések idoben érkeznek, a számlák pontosan kerülnek kifizetésre, a raktárakban a megfelelo készlet áll rendelkezésre. Nézzük meg a folyamatokat BPR szempontból és vizsgáljuk meg, hogy milyen megoldást választottak a GM-nél.

63


Az alapveto kérdés amit feltettek, hogy minek is használunk megrendeléseket és számlákat? A válasz kézenfekvonek tunik. Megrendelés nélkül honnan tudná a beszállító hogy mit, mikor és mennyit szállítson? Számla nélkül mire fizessünk? A GM eldöntötte, hogy létrehoz egy központi on-line gyártási információs rendszert, amely elektronikusan elérheto minden beszállítója számára. A beszállítók nem várnak a megrendelésre, figyelik az adatbázist, amely tartalmazza a következo hetek gyártási ütemezését is. Ennek ismeretében saját maguk döntenek a szükséges alkatrészek szállításáról, tervezik meg saját szállítási ütemezésüket. Ezzel sikerült kiiktatni a megrendeléseket. A továbbiakban nem a gyártónak kell kopogtatni a megfelelo ajtón a megrendelésével (legkésobb 8:30-ig!, a megfelelo formátumban!) egyszeruen küldik neki a hiányzó alkatrészeket. Ebben a folyamatban megszunik a papírmunka. A beszállító, miután feladta az adott alkatrészt, küld egy e-mailt: "A következo alkatrészeket küldtem neked." A megérkezés után a GM-nél egy egyszeru vonalkódolvasással megállapítható, hogy milyen alkatrész van a csomagban és, hogy ki volt a feladó. A kód leolvasása automatikusan elindíthatja a fizetési procedúrát, számla nélkül. Hogy mi teszi ezt lehetové? A központi on-line gyártási információs rendszer és az elektronikus adatcsere (EDI) kombinált alkalmazása. A BPR eszközeivel megtaláltuk a megoldási lehetoséget, és hozzá a problémát, amely elozoleg nem is létezett. Ezután mindezt beépíthetjük az üzleti stratégiánkba, projektet indíthatunk a megvalósítására, megválaszthatjuk a megfelelo eszközöket és technológiát, ahogyan azt a technológiai és szervezeti tényezok vizsgálatánál láttuk. Az egész folyamat hajtómotorja az információs technológia fejlodésébol származó megoldási lehetoség kihasználása volt. A vállalati menedzsment rendszerint csak olyankor figyel oda jobban a kereskedelmi folyamatokra, ha új piacokat akar meghódítani. Ilyenkor sokkal közvetlenebbül kerülnek szembe azzal a követelményhalmazzal, amellyel a vezetésük alatt álló szervezetnek meg kell birkóznia. A folyamatok ésszerusítésére, módosítására vonatkozó intézkedések csak a vezetés tudtával és támogatásával adhatók ki. Célszeru olyankor eloállni ezekkel a javaslatokkal, amikor a régi stratégiákat amúgy is felül kell vizsgálni, mert a szervezet új technológiát vezet be, vagy megváltozott a kereskedelempolitikai, a szabályozási, illetve a versenykörnyezet stb. Az EDI radikális és tartós hatású változást jelent, ezért jó, ha a vállalat kello idoben megismerkedik az EDI lehetséges hatásaival. Az EDI nem csupán az az eszköz, amely egyszeruen leváltja a régit, hanem új munkamódszereket is lehetové tesz. A vezetoségnek ezért - mielott kialakítaná az EDI bevezetésének prioritásait különbözo szempontok szerint meg kell vizsgálni az egyes területekre kifejtett

64


hatását, mely megjelenik az adminisztráció és az azt kiszolgáló rendszerek területén is. Természetesen minden EDI-projekt valamilyen értelemben behatárolt területet céloz meg, de a hatása idovel valamennyi fo feladatkörben érezhetové válik, így mindenképpen indokolt a felsovezetés figyelme és komoly elkötelezettsége. A szakirodalom szerint az EDI 20 százalékban muszaki és 80 százalékban szervezési, menedzsment-megoldás, kezdetben a gyakorlat csak korlátozott mértékben igazolta ezt. A COST 320 1991-es felmérése alapján a válaszadók 57%-a értett egyet azzal, hogy az EDI bevezetése több szervezési és kevesebb muszaki problémát okoz. Többségük a nagy, EDI tapasztalatokkal rendelkezo vállalatok közül került ki. A kérdoívre adott válaszokból arra lehet következtetni, hogy különbség van a vezetés „aktív segítése” és a vezetés „elvi támogatása” között. 83% jelezte, hogy a felsovezetés támogatása az EDI beindításában létfontosságú, hatékony közremuködésükkel csökkenthetok a szervezési problémák. Ugyanakkor a válaszadók csupán 51%-a jelölte meg a felsovezetést, mint az elvi támogatáson túli aktív segítot. A többiek a számítástechnikai vezetot (24%) és az érintett osztály vezetojét (24%) adták meg. A legfelso vezetés aktív segítsége kisebb súlyú volt a nagyvállalatoknál. Megállapítható, hogy az EDI megvalósításában érintett vezetoi szint a szervezet méretétol függ. A felsovezetés támogatása minden esetben elkerülhetetlen (az általános stratégia kidolgozásához) a gyakorlati megvalósítás viszont már alacsonyabb vezetoi szinteken történhet. A vállalatok 30%-a külön EDI-felelost nevezett ki, 70 százalékuknál valamelyik másik vezeto felügyeli az EDI-t. A kisvállalatoknál az EDI-felelos többnyire a legfelso vezetésnek van alárendelve, a nagy vállalatoknál a számítástechnikai igazgatónak. Az EDI-felelos szokásos fobb feladatai: ? az EDI vállalaton belüli és kívüli tudatosítása; ? az EDI-partnerekkel való kapcsolattartás; ? a szabványosítási kérdések figyelemmel kísérése; ? problémamegoldás. Az EDI bevezetésének közvetett következménye lehet a vezetési stílus megváltozása. A vállalaton belüli változások (az információáramlás módosulása, a szolgálati jelentéstételi utak rövidülése, a dolgozók képzettségének javulása, a rájuk háruló felelosség módosulása) végso soron indokolja a vállalat vezetési stílusának a módosítását is.

65


Kialakulhat a participációs vezetés, amely szabad teret hagy a munkavállalói kezdeményezésnek. A dolgozók felelosségérzete és kezdeményezokészsége megno. Érzik, hogy rajtuk múlik saját boldogulásuk és a vállalat sikere. Az elozoekbol látható, hogy a felsovezetés kulcsszerepet tölt be az EDI vállalaton belüli bevezetésében, ugyanakkor az alkalmazottaknak megfelelo szinten kell elsajátítani az EDI-rendszer kapcsán felmerülo új, más jellegu feladataikat. A COST 320 felmérése azonban azt mutatta, hogy az oktatás fontossága nem minden EDI alkalmazó számára nyilvánvaló. A nagyvállalatok részérol több volt a nemleges válasz. A gyakorlatban a vállalatok 25%-a részesítette külön oktatásban dolgozóit, foként a nagy cégek. Közel 20 százalékuknál nem volt semmiféle oktatás, a többieknél tanfolyamokra küldték a dolgozókat, vagy (legfeljebb egynapos képzés keretében) betanították oket az új feladatokra. Ha az EDI nincs integrálva a belso rendszerbe, hanem csupán a külso kommunikációt érinti, akkor nem kell nagyobb összegeket áldozni az oktatásra. Megfelelo integráció végrehajtásakor a munkavállalói struktúra is módosul, csökken az alacsonyabb képzettségu munkaero iránti igény. A foglalkoztatásra a kezdeti idoszakban kisebb hatással van az EDI, a gyakorlati tapasztalatok megszerzése után csökken az alacsonyabb képzettségu (adminisztratív) alkalmazottak létszáma, mivel a szuken vett adatbevitel jelentosen csökken. A munka fajtáján és a vállalat típusán múlik, hogy áthelyezéssel vagy továbbképzéssel elkerülhetok-e az elbocsátások. 3.3 Az EDI magyarországi környezete és szereploi Az elmúlt évek jelentosebb hazai eredményei a következokben vázolhatók: ? Magyarországon kialakult az EDI-t jól ismero és elterjesztésében valami módon szerepet vállaló szuk szakértoi kör. Egy részük vállalati körben, más részük igazgatási, kutatóintézeti vagy nonprofit szervezetekben, illetve szabadfoglalkozásúként tevékenykednek. ? Vannak olyan professzionális cégek (például EDIPORT, IDOM Hungary, SZÁMALK-SOFTEC, LIAS-NETWORX), amelyek üzleti profiljukba felvették az EDI-alkalmazások konzultánsi támogatását, alkalmas szoftverekkel való ellátását, illetve az EDI-szolgáltatást. ? Az EDI-alkalmazáshoz kapcsolódó kommunikációs szolgáltatásokat vállaló cégek (például ANSWARE, EDIPORT, MATÁV) a jelenlegi igényt sokszorosan meghaladó kapacitáskínálattal állnak rendelkezésre. ? Felkészült szabványosító szakértoi munkacsoport alakult ki az EDIFACTrendszer - ezen belül az Európai Unió által EN-ként átvett szabványok - hazai honosítása céljából.

66


? Az EDI magyarországi alkalmazásában érdekelt résztvevoi körök összefogását, információellátását segíti elo a sikeresen beindult magyar "EDI Fórum" program. ? Jelentos kezdeményezések indultak a Miniszterelnöki Hivatal, az ITB támogatásával, az EDI államigazgatási alkalmazásainak elosegítése céljából. Példaként az adózás, egészségügy, statisztika egyes területei említhetok, de további megvalósíthatósági vizsgálatok ígéretes lehetoségeket körvonalaznak. Ezek szerint az EDI szakmai, szakértoi oldalának alapjai már meg is volnának. Lassúbb elorehaladás a legfontosabb szereplok - az alkalmazók - terén mutatkozik. Kétségtelen tény az, hogy néhány - foleg külföldi érdekkörbe tartozó, vagy azokkal üzleti kapcsolatban álló - cégnél (TUNGSRAM, RÁBA, GM Hungary, VOLÁNCAMION, Happich Pemü stb.) már muködnek "élo" EDI-alkalmazások. Oket a partnerek "késztették" a bevezetésre. Néhány ipari vonatkozású projekt már elokészületben van, illetve a megvalósítás útján halad, ugyancsak külföldi igény nyomán. Jelentos elorelépést jelent a MATÁV által indított EDI-szolgáltatás, és az a szervezett pilotprojekt, amelytol - az érintett résztvevok partnerkapcsolatai révén az alkalmazói kör bovülése várható. E téren a nagyobb partnerek - mindenekelott a vásárlók - szerepe fontos, akik beszállítóik számára feltételül szabhatják az EDI alkalmazását az üzleti kapcsolatukban. Néhány hazai bank - szolgáltatásbovítési céllal - ugyancsak kialakított EDIszolgáltatást, amely a következokben - érdekeltségi "késztetés" hatására - kiegészül (például DEUTSCHE BANK Magyarország). Mindezen helyenként pozitív sikerként is megítélheto tények ellenére az EDIalkalmazás elterjedésének üteme Magyarországon - még a volt szocialista országokhoz képest is - viszonylag lassúnak tunik. Nem látszik lényegi elorelépés például a pénzügyi ágazat mértékadó irányítási régióiban, jóllehet az állami ráhatás lehetosége itt nyilvánvalóan meghatározó lehetne. A hazai EDI alkalmazás elterjedésének akadályai illetve korlátai. A tudatosság- és ismerethiány említendo legfontosabbként. A lehetséges alkalmazói kör jelentos része nem ismeri az EDI-t, annak lényegét, lehetséges elonyeit, hatásait. E téren különösen az irányítási és döntési szintek szakembereinek felkészítése, meggyozése szükséges. Hangsúlyozni kell, hogy nem feltétlenül a számítástechnikai vezetokrol van szó, hanem a gazdasági alaptevékenység irányítóiról. Vélhetoen a gátló tényezok valamelyikének vagy azok együttes következménye az, hogy egyes lényeges területeken komoly érdeklodés ma még nem látható.

67


Fontos szerepet töltöttek és töltenek be a tudatosítást szolgáló EDI konferenciák, szemináriumok. A hallgatói kör bovülése az érdeklodés növekedését látszik igazolni. Az ismereteket közlo kiadványok, szabványok mellett lényegesen nagyobb szerepet kellene kapnia e területnek a médiákban is. A tudatosítási szint növelése céljából központilag, intézményesen támogatott nemzeti léptéku program szükséges, hasonlóan az EU korábbi TEDIS projektjeihez. Emberi tényezoként említhetok általában a következo visszahúzó hatások: ? A komputerektol való félelem, az ismeretek hiányából adódó viszolygás, a bizalmatlanság, amely foként az idosebb korosztályba tartozók (esetenként döntési helyzetben lévo vezetok) részérol nyilvánul meg. ? A döntési pozíció féltése, a "jól bevált" kézi vezérlés helyett várható átláthatóságtól való idegenkedés. ? Kényelmesség, a fejlesztést felesleges kockázatvállalásnak tekinto szemlélet. ? A valódi piaci késztetés vagy felismerésének hiánya. A számítógépes szakemberek körében is adódhatnak korlátozó emberi tényezok: ? A saját vagy egyéb ismert, illetve képviselt megoldáshoz való görcsös ragaszkodás, még inkompatibilitás árán is. A "más találta ki" (mtk) reflexbol fakadó elutasító hatás. ? Az EDI-alkalmazáshoz új ismeretek megszerzése válik szükségessé, presztízskockázat. ? Kényszeru együttmuködés a partnerek szakembereivel. A szabályozási igazgatási környezet terén is adódnak problémák. Ilyenek: ? Valamely jogszabály papír alapú okmányt követelhet meg bizonyos ügyletekhez. ? Belso szabályozás, iratforma, eljárási, illetve ügyrend akadályt képezhet, amelynek megváltoztatása szükségessé válhat. ? Az elektronikus okmány hitelességének, az elektronikus aláírás jogi elismerésének problematikája. ? A titkosság, bizalmasság és személyi jogosultságok eseti problémái. ? Nem állnak rendelkezésre (néhány kivétellel) a szükséges, magyar nyelvu EDIFACT-szabványok, az alapveto, egységes (kódolt) adatbázisok (cég-, helységnyilvántartás, árumegnevezés). ? A sokirányú szakági összefüggés következményeként egyik szaktárca sem vállalja, illetve vállalhatja egyedül az EDI-technológia nemzeti léptéku elterjesztésének felkarolását.

68


? Nincs - a feladat nagyságával, illetve jelentoségével arányos - intézményes állami támogatottság, még a nyilvánvalóan állami érdekeltségu illetve felelosségi körbe tartozó területeken sem. A technikai környezetre jellemzo az, hogy már a mai helyzetében is több tekintetben lényegesen kedvezobb, mint a tudatossági, emberi vagy szabályozási feltételek. Emiatt nem ez ma az igazi akadály az EDI-alkalmazás útjában.

69


4 Az ENSZ-EDIFACT 4.1

EDI-szabványok

Az elektronikus adatcsere egyik legfontosabb jellemzoje az adatok - valamilyen szabvány szerint történo - strukturált továbbítása. Az elso EDI partnerek adataikat egy közösen kialakított formátumban (meghatározott adatstruktúrában) cserélték. Mindez kitunoen megfelelt addig, amíg nem jelent meg egy újabb, immár harmadik partner, akivel újra meg kellett állapodni az adattartalmat és az adatstruktúrát illetoen. Könnyu belátni, hogy ilyen módon csak korlátozott számú partner tud megegyezni egymással. Az idok folyamán az egyes ágazatok saját üzenetformátumokat (EDIszabványokat) dolgoztak ki. Így lehetové vált, hogy az azonos szektorban dolgozók egy közös „nyelvet” használjanak az elektronikus kommunikációhoz. Ennek eredményeként alakult ki például az autógyártók szabványkészlete az ODETTE, vagy a bankszektorban használatos SWIFT. Az ágazatok közötti kommunikáció azonban továbbra is nehézségekkel járt. Idoközben az Egyesült Államokban kialakították az elso olyan adatcsere szabványt (ANSI X.12), amely lehetové tette a széles köru kommunikációt. Az X.12-es szabvány használata elsosorban az USA-ban terjedt el és továbbra is problémát jelentett az X.12 és az ettol eltéro szabványokat alkalmazó (általában nem amerikai) vállalatok kommunikációja. A probléma megoldását egy olyan szabvány jelent(het)i, amely világszerte minden ágazatban alkalmazható. Ma már létezik egy ilyen világméretu, globális szabvány, amelynek neve: ENSZ-EDIFACT Az EDIFACT fejlesztése az ENSZ Európai Gazdasági Bizottságának kezdeményezésére indult. A fejlesztés elso lépcsojeként elkészült az EDIFACT szintaktikai szabályainak gyujteménye. Ezt követte az ún. EDIFACT-tárak fejlesztése. A fejlesztés elorehaladásával az ENSZ-EDIFACT-ot mind több országban, mind több ágazatban elismerték és alkalmazták. Napjainkra az elektronikus adatcsere világszabványává vált (7. sz. táblázat).

70


Ágazati Területi Világméretu

7. táblázat

Ágazatoktól független ANSI X.12

SWIFT

ENSZ-EDIFACT

Az EDI-szabványok mátrixa

Mindez nem jelenti azt, hogy az ENSZ-EDIFACT az egyetlen használatos adatcsere szabvány. Észak-Amerikában és a világ más részein muködo amerikai vállalatoknál az X.12 alkalmazása továbbra is jelentos. Ugyanakkor egy 1992-ben hozott amerikai döntés alapján 1997-re az ANSI X.12-rol át kell térni az ENSZ-EDIFACT-ra. Európában is muködnek más szabványokat használó alkalmazások. Ennek oka - egyebek mellett - abban keresheto, hogy idobe telik, amíg egy-egy használói csoport a korábban alkalmazott szabványokról más szabványok használatára tér át. Más a helyzet azokkal a szervezetekkel, amelyek most kezdik az adatcsererendszerek telepítését, számukra a természetes választás az ENSZEDIFACT. 4.2

Az ENSZ-EDIFACT

Az ENSZ Európai Gazdasági Bizottsága 1990 márciusában a következoképpen határozta meg az ENSZ-EDIFACT fogalmát: Az Egyesült Nemzetek ajánlása igazgatási, kereskedelmi és szállítási adatok cseréjéhez. Az ajánlás olyan nemzetközileg egyeztetett szabványok, adattárak és irányelvek együttese, amelyek a strukturált - foként az áruk és szolgáltatások kereskedelmével kapcsolatos - adatoknak az egymástól független számítógépes informatikai rendszerek közötti elektronikus cseréjét szabályozzák. Az ENSZ keretén belül kidolgozott szabályokat az ENSZ-EGB fogadja el és teszi közzé az ENSZ kereskedelmi adatcseretárában (az UNTDID-ben - United Nations Trade Data Interchange Directory - Az Egyesült Nemzetek kereskedelmi adatcsere tára, amely az ENSZ-EDIFACT-ot tartalmazza). A közzétett szabályok karbantartása közösen rögzített eljárások szerint történik. Ha az elektronikus kommunikációt az emberi beszédhez hasonlítjuk, az adatcsere szabványok leginkább a beszélt vagy írott nyelvhez hasonlatos funkciót látnak el. Így van ez az EDIFACT esetében is.

71


Az ENSZ-EDIFACT-szintaktika a nyelvtani szabályoknak feleltetheto meg. Ez határozza meg, hogy a kommunikáció alapelemeit hogyan illeszthetjük egymáshoz úgy, hogy „értheto” egészet képezzenek. Az emberi kommunikáció alapeleme a betu (hang), a szó és a mondat. Az adatcsere szabványban az ezeknek megfelelo elemek a kódok, az adatelemek, a szegmensek és az üzenetek. Az üzenetek szegmenseket, a szegmensek adatelemeket, az adatelemek kódokat tartalmaz(hat)nak. A szintaxis megadja a karakterkészletet, a lehetséges elválasztó karaktereket, a karakterek ábrázolási módját. Ezektol az alapértelmezésként megadott értékektol a felek eltérhetnek. Az ilyenkor használatos értékeket a felek az adatcsereszerzodésben rögzíthetik. Az A típusú karakterkészlet kivétel nélkül nyomtatható karaktereket használ, míg a B típusú nem nyomtathatókat (vezérlokarakterek) is tartalmaz. Mindkét készletben vannak speciális funkciójú karakterek: ? Szegmens lezáró (A – aposztróf, B – IS4) ? Adatelemelválasztó (A – „+”, B – IS3) ? Összetevo adatelemelválasztó (A – „:”, B – IS1) ? A mögöttes karakter eredeti jelentését visszaállító karakter a speciális funkciójú karakterek eredeti jelentését adja vissza (A – „?”) Az ENSZ-EDIFACT felépítését tekintve ? az ENSZ-EDIFACT szabályokból és irányelvekbol, valamint ? az ENSZ-EDIFACT-tárakból áll. Az elobbi a szintaktikai szabályokat, szintaxis megvalósítási irányelveket, üzenettervezési irányelveket, raportori eljárásokat és üzenetdokumentálási szabályokat, valamint a kereskedelmi adatok adatátvitel útján való cseréjének egységes szabályait tartalmazza, az utóbbi az üzenettárat, a szegmenstárat, az összetettadatelem-tárat és a kódlista-tárat. Az ENSZ-EDIFACT-szabványrendszer fejlesztése ma is folyik. A fejleszto munkacsoportok minden évben közzéteszik az EDIFACT-szabványrendszer legfrissebb módosításait tartalmazó EDIFACT-tárakat. A tankönyv írásának idopontjában jelent meg az 1997-es változat, amely az új igényeknek megfeleloen megkülönbözteti az interaktív és a kötegelt adatátvitelt.

72


Ez gyakorlatilag két (némileg) eltéro szabványkészletet jelent. (A szabvány kétféle szintaktikát és EDIFACT-tárat tartalmaz.) Az egyik az interaktív EDI-szabványt, a másik a kötegelt adatátvitelt támogató EDI-szabványt tartalmazza. A kötegelt szintaktika egy vagy több, elore elkészített üzenet továbbítását teszi lehetové úgy, hogy a küldo és a fogadó alkalmazás az adatátvitel ideje alatt nem tudja befolyásolni a feldolgozást. Elofordulhat, hogy a felek között párbeszédes muködésmódra van szükség. Ilyen lehet például a szállítási helyfoglalás, ahol azonnal szükség van az üzenet visszaigazolására. Ez a fajta kommunikáció tipikusan kétirányú, kis mennyiségu adatot mozgat, és rövid válaszidot igényel. Ezeket a kommunikációs igényeket az interaktív EDIFACT-szintaktika képes kielégíteni. Az adatcsere során az üzeneteket elore meghatározott módon, urlapokban szerkesztik, „strukturálják”, vagyis a partnerek elore megegyeznek az üzenetek típusában és formátumában. A továbbiakban az EDIFACT-ot a kötegelt adatátvitelt támogató szabványkészlet ismertetésén keresztül mutatjuk be. 4.2.1 Az ENSZ-EDIFACT-szintaktika Az elozoekbol láthatóan a szintaktikai szabályok határozzák meg az EDI párbeszéd nyelvtani szabályait, a szintaktika a nyelv elemeit és azok egymáshoz való viszonyát. Az EDIFACT elemei hierarchikus szabályok szerint állnak össze, így az EDIFACT-üzenetek meghatározott építokockák sorozataként épülnek egymásra. A legkisebb elemtol kezdve az építokockák a következok: ? kódok (pl. ország-, valuta- és állapotkódok); ? adatelemek, amelyek tartalmazhatnak kódokat (pl. valuta, kódolva) vagy szöveget (például: városnév); ? összetett adatelemek egymással szorosan összefüggo adatokból állnak (például a pénzösszeg és a valutanem), illetve ugyanannak az adatnak a kódolt és szöveges változatát is tartalmazzák (pl. árcsoport kódolva és az árcsoport); ? szegmensek. Ezek olyan adatelemek csoportjai, amelyek együtt egységes dolgot jelölnek (pl.: árrészletezés, fuvarmozgás-részletezés és a fizetési mód alapjául szolgáló paritás); ? szegmenscsoportot képezhet több szegmens. A szegmenscsoportban található szegmensek ugyanazt a tételt írják le (pl. a fuvareszköz leírását tartalmazó szegmensek egy szegmenscsoportban találhatók); ? üzenetet képeznek a szegmensek és szegmenscsoportok. Egy üzenet egy elektronikus okmánynak felel meg;

73


? funkcionális csoportban foghatók össze az üzenetek. Ilyen funkcionális csoport lehet például egy számlaüzeneteket tartalmazó üzenetfüzér; ? adatcserefüzért képezhetnek a funkcionális csoportok és az üzenetek együttese; A szintaxis néhány speciális, az adatcsere vezérlésére szolgáló és éppen ezért különleges szintaktikai jelentést hordozó elemet is tartalmaz: ? szolgálati üzenetek; ? szolgálati szegmensek; ? szolgálati összetett adatelemek; ? szolgálati adatelemek; ? az adatelemeket, összetett adatelemeket, valamint a szegmenseket elválasztó karakterek. Az építokockák mindegyike szabványosítva van. Minden építokocka-típusra külön ENSZ-EDIFACT-tár létezik, amely része az ENSZ-EDIFACT szabványnak. Ezek a tárak biztosítják, hogy például a név és a cím (szegmens) vagy az ország (adatelem) mindig ugyanolyan módon szerepeljen - függetlenül attól, hogy melyik ENSZEDIFACT üzenetben található. Ez az ENSZ-EDIFACT egyik nagy elonye, hiszen az ilyen közös meghatározások teszik lehetové, hogy a hasonló adatok bármiféle konverzió nélkül egyik üzenetbol a másikba átvihetok, vagy az alkalmazások között kicserélhetok legyenek. A számítógép így képes arra, hogy például a nevet és a címet további feldolgozás nélkül kiemelje a megrendelésbol és átvigye a fuvarmegbízásba vagy a számlába. A szabványos ENSZ-EDIFACT-üzenet dokumentációja azt írja le, hogy miképpen kell csoportosítani meghatározott szegmenseket, hogy képesek legyenek egy bizonyos ügylet/funkció (pl. fizetési megbízás) lebonyolítására. A szegmensek üzenetbe való csoportosításának szabályai az EDIFACT-szintaxisban találhatók. A késobbiekben részletesebben is szó lesz a fenti elemekrol, felépítésükrol és használatukról. A szintaxis megadja a karakterkészletet, a lehetséges elválasztó karaktereket, a karakterek ábrázolási módját. Ezektol az alapértelmezésként megadott értékektol a felek eltérhetnek. Az ilyenkor használatos értékeket a felek az adatcsereszerzodésben rögzíthetik. 4.2.2 Adatelemek Az adatelem az adott környezetben oszthatatlannak tekintheto adategységet jelent. Az EDIFACT-ban az adatelemet a következokkel specifikálták:

74


? adatelemcímke (az adatelem egyedi azonosítója - négyjegyu szám), egyértelmu, mert az adatelemtárban egy címke csak egyetlen adatelemet jelölhet; ? név (az adatelem neve); ? leírás (az adatelem leírása); ? az adatelem értékeinek ábrázolása vagy formátuma. Az elfogadott használói adatelemeket az EDIFACT-adatelemtár tartalmazza, amely az ENSZ kereskedelmi adatelemtárának (az UNTDED-nek) a része. Az egyszeru adatelemek tartalmazzák az átvitel lényegi adatait. Az adatok kívül esnek a szabvány hatókörén. Az adatelemek címkéje négy számjegybol áll. A számjegyek jelentéseit a következo szabályok osztották ki: ? Az elso számjegy: ez határozza meg, hogy az adatelem milyen fobb csoportba tartozik, pl.: ? 0xxx: szolgálati adatelem; ? 1xxx: dokumentáló adatelem, hivatkozási célokra; ? 2xxx: a dátumot, az idopontot, az idoszakot megadó adatelem; ? stb. ? A másodiktól a negyedik számjegyig: ? x000-x499: nemzetközileg elfogadott adatelem; ? x500-x699: nemzeti használatú adatelem; ? x700-x799: kísérleti EDIFACT-alkalmazásra szánt adatelem; ? x800-x999: magánhasználatú adatelem; ? A negyedik számjegy: ? páros számjegy: szöveg típusú adatelem; ? páratlan számjegy: kódolt adatelem, egy adott adatelem kódolt formája Az adatelem megnevezése és az adatelem leírása természetes nyelven történik. Az EDIFACT-ot leíró nyelv általában az angol, de különbözo nemzeti és nemzetközi kezdeményezések hatására az adatelemtárak több nyelven is megjelentek. Ilyen esetekben a címke teszi lehetové a kereszthivatkozást a különbözo nemzeti változatok között.

75


Az adat típusát alfabetikus esetben az „a”, numerikus esetben az „n”, alfanumerikus esetben pedig az „an” betuk jelölik. Az adatelemek lehetnek rögzített vagy változó hosszúságúak. A rögzített hosszúságú adatelemek hosszát közvetlenül az adat típusának jele után adják meg. A változó hosszúságú adatelemeknél közvetlenül az adattípus jele után két pont következik, majd ezt követi az adat maximális hosszát jelölo szám (8. sz. táblázat). … 3039 A fél azonosítója Leírás: Ez az adatelem a tranzakcióban (ügyletben) részt vevo felet kóddal azonosítja Ábrázolás: an..17

3042 Leírás:

Utca és házszám/postafiókszám Ez az adatelem az utca nevét és a házszámot vagy a postafiók számát adja meg szabad szöveges formában Ábrázolás: an..35

3055 A kódlistáért felelos intézmény, kódolva Leírás: Ez a kódolt adatelem a kódlistáért felelos intézményt azonosítja Ábrázolás: an..3

…

8.táblázat

Részlet az EDIFACT-tárból.

Például: a2 n..9 an..35

alfabetikus típusú, 2 karakter hosszú (rögzített hosszúságú); numerikus típusú, legfeljebb 9 számjegy hosszú (változó hosszúságú); alfanumerikus típusú, legfeljebb 35 karakter hosszú (változó hosszúságú).

Ezen kívül néhány általános alapelv is meghatározza a szabványos adatelemek hosszát. Például: ? a kódolt adatelemek típusa és hossza mindig an..3; ? a szabad szöveges adatelemek típusa és hossza csak an..17, an..35 vagy an..70 lehet. A házon belül használt adatelemeknek mindig pontosan meghatározott jelentésük van. A jelentést explicit módon is kifejezhetik, de elofordulhat, hogy az alkalmazási környezetbol válik nyilvánvalóvá. Ezeket különleges adatelemeknek lehet felfogni.

76


Az adatcsere adatelemeit éppen ezért mindig olyan részletességgel kell leírni, hogy valamennyi résztvevo fél ugyanazt értse rajta. Ez különösen érvényes az ENSZEDIFACT-adatelemekre, mivel ezek több üzenetben, különbözo környezetben is elofordulnak. Az elektronikus adatcsere számos adateleme tekintheto általános adatelemnek. Ez azt jelenti, hogy az ilyen adatelemek általános célúak, és úgy tervezték oket, hogy használhatók legyenek több ágazat különbözo funkciójú üzeneteiben. Ezeket az adatelemeket értelmezhetjük implicit módon (az üzenetben elfoglalt hely alapján) vagy explicit módon (más adatelemek használatával). Általános adatelem például a „2380 Dátum/idopont/idoszak”, amely egyaránt használható a megrendelés dátumának, a várható érkezési idopontnak vagy a számla keltének a megadására. Ilyen esetekben az üzenet fogadójával valamilyen módon közölni kell, hogy a „2380 Dátum/idopont/idoszak” adatelemek az adott üzenetben milyen dátumra, idopontra vagy idoszakra vonatkoznak. Ezt teszik lehetové az ún. minosíto adatelemek. Vannak olyan adatelemek, amelyek meghatározott funkciót látnak el és az elozoek nem tekinthetok általános adatelemnek. Az adatelemérték az a bejegyzés, amelyet az adatelemtárban specifikált módon ábrázolt adatelem tartalmaz. Az adatelem formájától függoen az adatérték lehet szabad szöveges vagy kódolt. Egyes esetekben az adatelemértékek meghatározott felépítésuek lehetnek. Ilyen pl. az ÉÉHHNN (év, hónap, nap) formában kifejezett dátum. Az adatelemek implicit értelmezése szerint az adatelemek sorrendje meghatározott a szegmensen belül, ezért az üzenetet fogadó rendszer azonosíthat és feldolgozhat minden egyes adatelemet. Szoftveresen kell felismerni ezt a tényt ha egy adat elmarad, amit egy meglévo adat követ. Egy vagy több feltételes adatelem hiányzó értéke esetén, amelyet létezo adatelem követ, minden egyes adatelem helyén egy adatelemelválasztó karaktert kell elhelyezni („A” karakterkészlet esetén + jel). Ha a szegmens végérol hiányzik egy vagy több feltételes adatelem, akkor az utoljára használt adatelem után a szegmens lezáró karakterrel csonkítjuk a szegmenst, vagy a hiányzó adatelemek helyére elhelyezzük az adatelemelválasztó karaktert. Az utóbbi esetben azonban feleslegesen hosszú lehet az adatcsere során átküldendo üzenet. A szegmensek utolsó, nem használt összetevo adatelemeire vonatkozóan – a csonkítás normális szabályait követve – az összetevo adatelem elválasztók helyettesíthetok szegmenscímke elválasztóval.

77


Egy vagy több az összetett adatelemen belül hiányzó feltételes összetevo adatelem hasonló elv használatát jelenti, mint az elobb. Adatelem elválasztó karaktert kell beszúrni az utolsó használatos összetevo adatelem után (:). A csonkítás hasonló módon történik, mint az elobb leírtak. 4.2.3 Kódlisták A kódlista az adott adatelemhez hozzárendelt, meghatározott jelentést hordozó kódértékek gyujteménye. Az EDIFACT-kódlisták a kódok eredetét tekintve négy csoportra, osztályra oszthatók. 1. Az EDIFACT és az ISO által karbantartott, szolgálati adatelemek kódlistái; 2. Az EDIFACT által karbantartott, használói adatelemek kódlistái; 3. Az ISO vagy az ENSZ-EGB által karbantartott, használói adatelemek nemzetközi kódlistái; 4. Az EDIFACT-on, az ISO-n és az ENSZ-EGB-n kívüli szervezetek által karbantartott kódlisták. Az 1. és 2. csoportba tartozó kódlistákat az EDIFACT kódlistatárában teszik közzé. A 3. csoport kódlistáira hivatkozások találhatók az ENSZ kódlistatárában. Bár néhány adatelemhez csak egyetlen kódlista tartozik, a többségüknél több kódlista is használható. Az utóbbiak esetében a használók az adatcsere-szerzodésben rögzíthetik, hogy a kódlisták közül melyiket használják. Adott esetben a kódlistát két, külön erre szolgáló adatelem kombinációjával azonosíthatjuk: Az itt megadott kódértéket a kódlisták birtokában már egyértelmuen lehet értelmezni. 4.2.4 Összetett adatelemek Az összetett adatelem egy vagy több adatelembol álló, szabványos struktúra. Az EDIFACT-ban az összetett adatelemet a következokkel specifikálták: ? címke, amely az összetett adatelemek egyedi azonosítója (betu és 3 szám), egyértelmu, mert az adatelemtárban egy címke csak egyetlen összetett adatelemet jelölhet; ? név (az összetett adatelem megnevezése); ? leírás (az összetett adatelem leírása); ? a tartalom specifikáló megadása, azaz ketto vagy több adatelem, ahol ? az adatelemek az EDIFACT-adatelemtárból származnak, ? az adatelemek sorrendje lényeges,

78


? az egyes elemeknek az összetett adatelemen belül elore meghatározott státusuk van.

… C080 A FÉL NEVE Leírás: Az ügyletben részt vevo felet a nevévelazonosítja egy, ketto vagy három sorban A tartalom specifikáló megadása: 3036 A fél neve M 3036 A fél neve C 3036 A fél neve C

an..35 an..35 an..35

C082 A FÉL AZONOSÍTÓJÁNAK RÉSZLETEI Leírás: A tranzakcióban (ügyletben) részt vevo felet kóddal azonosítja. A tartalom specifikáló megadása: 3039 A fél azonosítója M 1131 Kódlista-minosíto C 3055 A kódlistáért felelos intézmény, kódolva C

an..17 an..3 an..3 …

9. táblázat

Részlet az összetettadatelem-tárból.

Az összetett adatelemek címkéje négy karakterbol áll. ? Az elso karakter: ? S: szolgálati összetett adatelem (olyan adatokat tartalmaz, amely az átvitel felépítéséhez szükséges); ? C: használói összetett adatelem. ? A másodiktól a negyedik karakterig: ? három számjegy (0-9) elore meghatározott jelentés nélkül. Az adatelemek lehetséges státusai az összetett adatelemen belül: M - kötelezo(en használandó) adatelem, C - feltételes(en használandó) adatelem (9. sz. táblázat). Az adatelemek elofordulására vonatkozó feltételek a szegmens definíciójában adottak. Ha nincs feltétel meghatározva, akkor a kereskedelmi partnerek megegyezése, vagy az üzenet küldojének választása alapján használatos. Az összetett adatelem kialakításánál az adatelemek sorrendjét az alábbi rendezoelvek szabják meg:

79


? a kötelezo adatelemek megelozik a feltételeseket; ? a gyakrabban használt adatelemek a ritkábban használtak elott állnak; ? az összetett adatelem módosulása esetén az új változatban az új adatelemek mindig az összetett adatelem régi adatelemei után állnak. Összetett adatelemet azért használunk, hogy ? egy általános adatelemhez minosíto adatelemeket rendeljünk hozzá; ? összerendeljük az azonos adatelemek kódolt és szöveges változatait; ? egy adott számértékhez hozzárendeljük a rá vonatkozó mértékegységet; ? egy intervallumot (értéktartományt) adjunk meg. 4.2.5 Szegmensek A szegmens funkcionálisan összetartozó - a struktúrában elfoglalt helyük alapján azonosítható - adatelemek és összetett adatelemértékek szabványos együttese. Az EDIFACT-ban a szegmenst a következokkel specifikálták: ? címke (a szegmens egyedi azonosítója - három betu), egyértelmu, mert az adattárban egy címke csak egyetlen szegmenst jelölhet; ? szegmensnév (a szegmens megnevezése); ? funkció; ? a tartalom specifikáló megadása, azaz ketto vagy több adatelem és/vagy összetett adatelem, ahol ? az adatelemeket és az összetett adatelemeket az EDIFACT-adatelemtár és az összetett adatelem-tár tartalmazza, ? az adatelemek és az összetett adatelemek sorrendje lényeges, ? az egyes elemeknek az összetételen belül elore meghatározott státusuk van. A szegmensek címkéje három betubol áll. ? Az elso betu: ? U: szolgálati szegmens; ? Bármelyik másik betu (az U kivételével) használói összetett adatelemet jelöl. ? A második és harmadik betu: ? nincs elore meghatározott jelentésük. A szegmensek címkével kezdodnek, amely egy kötelezo összetett szolgálati adatelem. Az elso összetevo adateleme a címkének kötelezo és a szegmens azonosító kódját tartalmazza. A szolgálati szegmensek kódjait a szabvány tartalmazza és nem lehet megváltoztatni azokat. A felhasználói szegmensek

80


kódjainak kiadásáért az Ellenorzési Hivatal a felelos és azok egyediek azokban az alkalmazásokban, amelyekben használják. NAD NÉV ÉS CÍM Funkció: Ez a szegmens a nevet és a címet, illetve az általuk hordozott funkciót adja meg. Ez történhet kizárólag a C082 összetett adatelemmel és/vagy strukturálatlanul a C058 összetett adatelemmel vagy strukturáltan a C080-3207 adatelemekkel. 3035 C082 3039 1131 3055 C058 3124 3124 3124 3124 C080 3036 3036 3036 C059 3042 3042 3042 3164 3229 3251 3207

A FÉL MINOSÍTOJE A FÉL AZONOSÍTÓJÁNAK RÉSZLETEI A fél azonosítója Kódlista-minosíto A kódlistáért felelos intézmény, kódolva NÉV ÉS CÍM Név- és címsor Név- és címsor Név- és címsor Név- és címsor A FÉL NEVE A fél neve A fél neve A fél neve UTCA Utca és házszám/postafiókszám Utca és házszám/postafiókszám Utca és házszám/postafiókszám A VÁROS NEVE AZ ORSZÁG ALEGYSÉGÉNEK AZONOSÍTÓJA A POSTAI IRÁNYÍTÓSZÁM ORSZÁGNÉV, KÓDOLVA

M C M C C C M C C C M M C C C M C C C C C C

an..3 an..17 an..3 an..3 an..35 an..35 an..35 an..35 an..35 an..35 an..35 an..35 an..35 an..35 an..35 an..9 an..9 an..9

10. táblázat A NAD szegmens. Részlet a szegmenstárból A többi összetevo adatelem (10 db) a címkében feltételesen használatos. Csak akkor használják, ha a szegmenst meg lehet ismételni az üzeneten belül és az üzenet specifikációban egy ellenorzo szám kerül meghatározásra, amely jelzi azt a szintet, ahol a szegmens ismétlodik. Az átvitelkor a szegmensnek legalább egy adatelemet kell tartalmaznia. Az adatelemek sorrendje a szegmensen belül elore meghatározott a szegmenstárban. A kötelezo szegmenseket el kell küldeni az adatcsere során, a feltételesen használatos szegmensekre vonatkozóan a partnerek közötti elozetes megállapodás értelmében az üzenet specifikációban rögzítik a használat feltételeit. Az összetétel adatelemeinek és összetett adatelemeinek lehetséges státusai: ? M – kötelezo(en használandó) elem;

81


? C – feltételes(en használandó) elem. (10. sz. táblázat) Egy feltételes szegmens az üzeneten belül egy vagy több kötelezo adatelemet vagy összetevo adatelemet tartalmazhat a használat során. Ebben az esetben ezek az adatelemek kötelezoek a szegmens szintjén, de nem kötelezoek az üzenet szintjén. Ugyanígy az összetevo adatelemek kötelezoek az adatelem szintjén. A vonatkozó feltételeket az üzenetdefinícióban kell megadni. Ha nincs feltétel megadva, akkor az üzleti partnerek egyezsége határozza meg azokat, vagy az üzenet küldoje. A szegmens kialakításánál az adatelemek és az összetett adatelemek sorrendjét az alábbi rendezoelvek szabják meg: ? a szegmens elso adateleme a szegmenscímke; ? a kötelezo elemek megelozik a feltételeseket; ? a gyakrabban használt adatelemek a ritkábban használtak elott állnak; ? a szegmens módosításakor az új változatban az új adatelemek a régiek mögé kerülnek. A szegmensleírásokban az adatelemeket és az összetett adatelemeket nagybetukkel, az összetett adatelemekben levo adatelemeket pedig kisbetukkel jelölik (írják). A szegmens az egymással funkcionális kapcsolatban álló adatelemeket egyetlen struktúrába fogja össze. Szegmenssel megadható információk például: az árumozgás részletei, az áru méretei vagy a fizetési feltételek. Ez a szegmenskoncepció fontos szerepet játszik az adatcserében, mivel a szegmens az a legkisebb adatcsereegység, amelyet (a szegmens címkéje révén) explicit módon azonosítunk. A következo szolgálati szegmens kategóriák találhatók az EDIFACT szintaktikai szabályban: ? Átvitel szintaktikai szegmensei, amelyek az adatátvitelt szabványos módon állítják össze, pl. adatcsere kezdete és vége, üzenet kezdete és vége, funkcionális csoport kezdete és vége. ? Szolgálati üzenetekben használt szegmesek, amelyeket egyaránt használnak szintaktikai hibák javítására és kiszurésére, a kézhezvétel megerosítéséré vagy az alkalmazói hibák javítására. ? Szegmens, amit a General Purpose Message – álalános felhasználói üzenetben használnak, amely jelzi a típusát, a címét és a hivatkozását az üzenetnek.

82


4.2.6 A minosítok A minosíto olyan adatelem, amely valamely másik adatelem, összetett adatelem vagy szegmens funkciójának ad meghatározott értelmet. A minosíto értékeit mindig kódolt formában fejezzük ki (11. sz. táblázat).

A NAD szegmenst a „3035 A fél minosítoje” adatelem minosíti (lásd az elozo pontot). A 3035 sz. adatelem értékétol függoen a szegmens különbözo partnerek nevét és címét tartalmazhatja. Például: NAD+BY+... a vevo neve és címe NAD+SE+... az eladó neve és címe NAD+CN+... a címzett neve és címe

11. táblázat Példa a minosíto használatára a „NAD, NÉV ÉS CÍM” szegmensben A minosítok és az általános adatelemek kombinációja – ugyanannak az adatstruktúrának a felhasználásával – lehetoséget teremt a különbözo típusú információk rugalmas kezelésére. Abban az esetben ugyanis, ha új típusú információra van szükség, elegendo a minosítonek egy újabb értéket adni. Így az adatelemtár és az üzenet struktúrája változatlan maradhat. Ha az összetett adatelemben a minosíto csak egyetlen adatelemet minosít, akkor a minosíto a minosített adatelem mögött helyezkedik el (az adatelemtárban), és a ketto együtt összetett adatelemet alkot. Ha az összetett adatelem a minosíton kívül két vagy több adatelemet is tartalmaz, a minosíto az adatelemek elott áll, és ezek az adatelemek együtt alkotják az összetett adatelemet. Ha a minosíto a szegmensre vonatkozik, akkor a minosíto egyszeru adatelemként közvetlenül a szegmenscímke után helyezkedik el. 4.2.7 Üzenetek Az üzenet olyan rendezett karaktersorozat, amelynek az a célja, hogy információt hordozzon. Az EDIFACT-ban viszont ennél több ismérve van az üzenetnek, mivel pontosan körülhatárolt üzleti funkciót hordoz, és szegmensekkel kifejezett, elore meghatározott struktúrája van. Az üzeneten belül minden egyes szegmenst a szegmenscímkéje és a szegmensek alkotta sorban elfoglalt helye azonosít.

83


A szabványos EDIFACT üzenetet az UN/ECE hagyja jóvá, teszi közzé és tartja karban. Az üzenet fejrészében az üzenettípus, a verzószám, a közzétételi szám és az ellenorzo hivatal mezok kitöltöttek, amit az UN/ECE határoz meg és ellenoriz. Az EDIFACT-ban az üzenetet a következo elemekkel specifikálták: ? azonosító kód (az üzenet azonosítója – hat betu), egyértelmu, mert az adattárban egy kód csak egyetlen üzenetet jelölhet; ? név (az üzenet megnevezése); ? funkció (az üzenet által hordozott funkció); ? a tartalom specifikációja. Ebben adják meg ? az üzenet fejrészében, zárórészében és – ha van – a szakaszellenorzo részben szükséges szolgálati szegmenseket, illetve az EDIFACT-szegmenstárból vett használói szegmenseket; ? az adatok hierarchikus rendjét tükrözo szegmenscsoportokat; ? az üzenetben szereplo szegmensek és szegmenscsoportok rögzített sorrendjét; ? az üzenetben szereplo valamennyi szegmens és szegmenscsoport üzeneten belüli státusát és ismételhetoségi tényezojét; ? az üzenetben szereplo valamennyi szegmens és szegmenscsoport rendeltetését, használatát. Az elfogadott státusú üzeneteket az EDIFACT-szabványtárban, a kísérleti célokra közzétett üzeneteket az EDIFACT-tervezettárban teszik közzé. (12. sz. táblázat) Minden üzenetet egy egyedi, hatbetus kód azonosít. A szegmensek és 0. Bevezetés Ez a specifikáció a „Partnerinformácó” (PARTIN) üzenet leírását tartalmazza, amely az igazgatási, kereskedelmi és szállítási ügyletekben részt vevo partnerek adatainak elektronikus cseréjére (EDI) szolgál. 1. Tárgy 1.1 Funkcionális meghatározás Ez az üzenet a telephellyel, tevékenységgel, igazgatással, pénzügyekkel, termeléssel és kereskedelemmel kapcsolatos, alapveto információt közöl. 1.2 Alkalmazási terület Az ENSZ szabványos „Partnerinformáció” üzenete a nemzeti és a nemzetközi kereskedelemben egyaránt alkalmazható. Az általános kereskedelmi gyakorlathoz igazodik, független az üzleti területtol vagy ipari ágazattól.

12. táblázat Üzenetleírás (részlet a PARTIN-üzenetbol)

84


szegmenscsoportok státusa az üzenetben lehet: ? M – kötelezo(en használandó), ? C – feltételes(en használandó). Valamely csoportban levo szegmens vagy egy másik szegmenscsoporton belül elhelyezkedo szegmenscsoport státusa (M vagy C) a szülocsoport státusától függ. Az üzenet elso szegmense az üzenetfejrész (UNH szolgálati szegmens), az utolsó szegmense az üzenetzárórész (UNT szolgálati szegmens). Legalább egy felhasználói adatszegmenst kell tartalmaznia, amely legalább egy felhasználói adatelemet tartalmaz. Az üzenet struktúrájának leírására a szegmenstáblázat (13. sz. táblázat) és az elágazásokat mutató blokkdiagram (19. sz. ábra) egyaránt használható. Feladatuk a szegmensek megfelelo sorrendjének ábrázolása. Az egyes szegmenseket és szegmenscsoportokat a szegmenstisztázás mutatja be (14. sz. táblázat).

0

1

UNH M 1

BGM M 1

...

...

UNS M 1

UNT M 1

Grp1 C 5

Grp4 C 200000

RFF M 1

NAD M 1

2

Grp5

C 20 DTM C 1

3

DTM C 2

FII C 10

19. ábra A PARTIN üzenet blokksémája (részlet)

LOC M 1

...

DTM C 2

Új üzenet kialakításakor vagy korábbi üzenetek módosításakor ügyelni kell arra, hogy szegmensek ne ütközzenek egymással. Ez akkor következik be, amikor egy szegmenst az üzenet különbözo részein különbözo célokra használnak anélkül, hogy kötelezo adatelemekkel választanák el oket.

85


Az ütközés elkerülésének egyik módja, hogy az önálló szegmenst szegmenscsoportok elé helyezik. Egy másik lehetséges megoldás az üzenet részekre tagolása a szakaszellenorzo rész (UNS) szolgálati szegmens segítségével. Címke Megnevezés

Státus

Ismételhetoség Ciklusok

UNH Üzenetfejrész BGM Az üzenet kezdete ...

M M

1 1

1. Szegmenscsoport ? ? ? ? ? ? ? RFF Hivatkozás DTM Dátum/idopont/idoszak ? ? ? ?

C ? ? ? ? M C ? ? ? ?

5 1 1

… 4. Szegmenscsoport ? ? ? ? ? ? ? ? C ? ? ? ? NAD Név és cím C DTM Dátum/idopont/idoszak C FII Pénzintézeti információ C

200000 1 5 10

5. Szegmenscsoport ? ? ? ? ? ? ? ? C ? ? ? ? LOC Hely-/helységazonosító M DTM Dátum/idopont/idoszak C

20 1 2

… UNT

Üzenetzárórész

M

1

13. táblázat A („Partnerinformáció”) PARTIN-üzenet szegmenstáblázata (részlet) Az üzenetben használt szegmenseknek a 19. sz. ábrának megfeleloen, meghatározott sorrendben kell szerepelniük (felülrol lefelé és balról jobbra). A szegmenseket kódjaikkal kell megjelölni. Az M és a C betuk mellett közvetlenül álló szám azt jelenti, hányszor jelenhet meg az adott szegmens az üzenetben annak minden egyes elofordulásakor. A kötelezo szegmensnek legalább egyszer meg kell jelennie, de nem szerepelhet többször, mint ahányszor a feltüntetett számérték szerint megengedett. A feltételes szegmens elhagyható vagy legfeljebb annyiszor szerepelhet, mint ahányszor a feltüntetett számérték szerint lehetséges. Egy adott üzenettípuson belül használhatunk explicit és implicit ismétlési technikákat. A két technika ugyanazon az üzeneten belül nem keverheto össze. Az ismétlés jelzése lehet explicit (a szegmens címkében az elso összetevo adatelem a szegmens kódja, az utolsó összetevo adatelem utal a szegmens elofordulásának gyakoriságára) vagy impliciten ismert az üzenet specifikációban meghatározott szegmenssorrendbol. Hangsúlyozni kell, hogy az üzenettervezok felelossége, hogy eldöntsék és megállapítsák minden egyes üzenetspecifikációban a jelzés melyik formáját

86


használják. A forgalomban lévo szabványos üzenetek esetében az implicit jelzés a használatos. A szegmensek ismétlésének számát az a funkció határozza meg, amelyikre specifikálták. Az n-szer ismételheto feltételes szegmensek hiányzó adat esetén nem jelennek meg, a kötelezo maximum n-szer ismételheto szegmenseknek legalább egyszer meg kell jelenniük az üzenetben. Minden szegmenspozíciónak megvan a maga egyedi funkciója. A funkcióhoz tartozó adatokat elore meghatározott szegmenstípusok hordozzák. Az üzenetek további strukturálása érdekében a szegmensek szegmenscsoportokká is összefuzhetok. … 4. szegmenscsoport: NAD–DTM–FII–SG5–SG6–SG7–SG8 Ez a szegmenscsoport adja meg a fél részletes adatait. NAD, Név és cím Ez a szegmens adja meg a felet azonosító kódot, a hozzá tartozó funkciót, nevet és címet. A fél azonosító kódját kötelezo megadni, és a strukturált címformátumot kell elonyben részesíteni. DTM, Dátum/idopont/idoszak Ez a szegmens adja meg a NAD szegmensben azonosított félre vonatkozó dátumot, idopontot és idoszakot. FII, Pénzintézeti információk Ez a szegmens adja meg a NAD szegmensben azonosított fél bankját) és számlaszámait.

pénzintézetét (pl.

5. szegmenscsoport: LOC–DTM Ez a szegmenscsoport adja meg a szóban forgó félre vonatkozó hely- és idoadatokat. LOC, Hely-/helységazonosító Ez a szegmens tartalmazza a NAD szegmensben megadott félre vonatkozó hely (pl. nagyobb területen belüli épületszám) adatait. DTM, Dátum/idopont/idoszak Ez a szegmens adja meg a LOC szegmensre vonatkozó idopontokat és idoszakokat.

dátumokat,

…

14. táblázat Szegmenstisztázás (részlet). PARTIN-üzenet Néha szegmensek ismétlése elofordulhat egy már ismétlodo szegmensen belül (pl. egy konténerben több áru, egy szállítmányban több konténer). Ha egy szegmens egy másik szegmensbe van beágyazva, akkor azt az ábrán a következo alsóbb szinten kell elhelyezni. A zérus szinten lévo szegmenseket tilos

87


ismételni és nem tartalmazhatnak beágyazott szegmenseket sem. Ugyanakkor lehetnek kötelezoek vagy feltételesek. Két vagy több szegmens csoporttá (group) fogható össze. A csoport és a benne lévo szegmensek akár kötelezoek, akár feltételesek lehetnek és annyiszor jelenhetnek meg, ahányszor a feltüntetett számérték szerint lehetséges. Egy csoport tartalmazhat másik, alacsonyabb szintu csoportot vagy csoportokat. Egy üzeneten belül 2 vagy több szegmensbol álló szegmenscsoport is ismételheto mint csoport és lehet kötelezo vagy feltételes a státusa. Bármennyi csoport lehet egy üzeneten belül és a csoportok együttesen is alkothatnak egy másik csoportot. A feltételes csoport elhagyható, ha nincs átviendo adat még akkor is, ha a feltételes csoport kötelezo szegmenseket tartalmaz. Ha egy feltételes csoport átvitelre kerül, akkor a csoportnak tartalmaznia kell a kötelezo szegmenseket. A szegmenscsoport egy téglalapban egyedi csoportazonosító számot kap, itt kerül feltüntetésre a csoport státusa, a megengedett elofordulások maximális száma. (19. sz. ábra) A szegmenscsoporton belüli elso szegmens (trigger) kötelezo és nem ismételheto. Ez a szegmens határozza meg a csoport funkcióját. Egy szegmens függhet egy magasabb hierarchiai szinten lévo szegmenstol az üzenetstruktúrában és így ennek a szegmensnek beágyazott szegmense. Egy adott üzenettípuson belül használhatunk explicit és implicit beágyazási technikákat. A két technika ugyanazon az üzeneten belül nem keverheto össze. Az beágyazás jelzése lehet explicit (egy összetett adatelem áll a szegmens élén, aminek összetevo adateleme mutatja a beágyazást) vagy impliciten ismert az üzenet specifikációban meghatározott szegmenssorrendbol. Explicit jelzés: A szegmens címkében az elso összetevo adatelem a szegmens kódja és a következo feltételes összetevo adatelemek utalnak a szintre és a szegmens ismétlésének gyakoriságára. Az összetevo adatelemek számát használják erre a célra annak függvényében, hogy melyik hierarchiai szinten jelenik meg a szegmens az üzenet struktúráját szemlélteto diagramban. A szegmens kód után a következo összetevo adatelem használatos, ha a szegmens az elso szinten, a második is, ha a második szinten stb. jelenik meg. Az adatelem értéke pedig az a szám, amely az aktuális ismétlések számát mutatja. További összetevo adatelem mutatja a beágyazási kapcsolatot. Implicit jelzés: A szegmensek sorrendje az üzenet struktúra diagramban lett meghatározva, ezt kell szigorúan követni. Ezért a szegmensek közötti beágyazási kapcsolatok impliciten evidensek és így nem igényel semmilyen további utalást.

88


Az explicit beágyazási jelzés akkor alkalmazandó, ha a fogadó fél nem képes a szegmensek logikai kapcsolatának azonosítására az üzenet definíciója alapján. A 0. szinten lévo és szolgálati szegmensek nem tartalmazhatnak beágyazott szegmenseket és nem lehetnek beágyazott szegmensek. Van lehetoség az üzenetek több lépcsos elküldésére. Az elso részben az adatcsere során az üzenet nem tartalmazza az üzenet specifikáció szerinti összes információt, csak a kötelezoen használatos részeket és azokat, amiket az üzenet küldoje megad. A második rész egy strukturált egyedi kulcs alapján kapcsolódik az elso részhez. Ez akkor hasznos, amikor eloször nem tudunk teljesen pontos információkkal szolgálni, a pontosítás késobb történik, de pl. a helyfoglalás miatt idoben kell cselekedni. A szolgálati üzenetek szolgálati szegmenseket tartalmaznak: ? hibajavításra (szintaxis protokoll szinten, vagy alkalmazási szinten), ? általános szabad szöveg céljából. A szintaktikai szabályok nem határozzák meg a felhasználói adatszegmensek sorrendjét az üzeneten belül. Ez az üzenettervezés feladata. Az adatcsereszerzodés tartalmaz minden specifikációt az adatcsere üzenetekre és azok szegmensére vonatkozóan a felhasználói csoport igényei szerint. Az átvitelhez az üzeneteket egy vagy több funkcionális csoportba gyujthetjük. Ugyanabban az adatcserében nem megengedett a funkcionális csoportok és a funkcionális csoportban nem tartozó üzenetek együttes kezelése. 4.2.8 Az üzenet felépítése, szolgálati szegmensek Az ISO 9375 szabvány határozza meg az EDIFACT alkalmazási szintu szintaktikai szabályait. Rögzíti az alkalmazandó karakterkészleteket (a különbözo elválasztó stb. jelölések számára), adatszerkezetet, a tömörítési módozatokat, az ismétlések lehetséges megoldásait, a szegmensek beágyazását, a numerikus adatelemértékek ábrázolását, valamint tartalmazza a szolgálati szegmensekre vonatkozó eloírásokat és a szegmensek és szegmenscsoportok üzeneten belüli sorrendjét. A továbbiakban az üzenetek hierarchikus felépítését (20. sz. ábra) és a szolgálati szegmensek jelentoségét részletezzük. Az ÖSSZEKÖTTETÉS egy vagy több ADATCSERÉbol áll. Az adatátvitel egy vagy több üzenetet is tartalmazhat. A felépítés, a fenntartás és a befejezés stb. muszaki protokolljai nem képezik a szabvány részét.

89


Felépítés

Összeköttetés

Felépítés

Csere

ADATCSERE

Csere

UNA UNB '

vagy FUNKCIONÁLIS CSOPORTOK

vagy csak ÜZENETEK

UNZ '

UNG '

Üzenet

ÜZENET

Üzenet

UNE '

UNH '

Adatszegmens

ADATSZEGMENS

Adatszegmens

UNT '

EGYSZERU ADATELEM

CIMKE

+

Kód

: Érték

Érték

+

ÖSSZETETT ADATELEM

ÖSSZETEVO ADATELEM

Érték

A

vonal alternatívát jelent a

:

+

ÖSSZETEVO ADATELEM

Érték

vonalhoz képest

20. ábra Az adatcsere hierarchikus szerkezete ? Az ADATCSERE részei: ? UNA, szolgálati füzér, ha használják; ? UNB, adatcsere-fejrész; ? vagy csak funkcionális csoportok, ha használják, vagy csak üzenetek; ? UNZ, adatcsere-zárórész. ? A FUNKCIONÁLIS CSOPORT részei: ? UNG, funkcionális csoport-fejrész; ? azonos típusú üzenetek; ? UNE funkcionális csoport-zárórész. ? Az ÜZENET részei:

90


?

? ? ?

? UNH, üzenetfejrész; ? adatszegmensek; ? UNT, üzenetzárórészek. A SZEGMENS részei: ? szegmenscímke; ? egyszeru adatelem, vagy összetett adatelem, vagy mindkét fajtából, ha alkalmazható. A SZEGMENSCÍMKE részei: ? egy szegmenskód és ha kifejezetten jelzik, ismétlési és beágyazási érték(ek). EGYSZERU ADATELEM és az ÖSSZETEVO ADATELEM része: ? egy adatelemérték. Az ÖSSZETETT ADATELEM részei: ? összetevo adatelemek.

A szolgálati füzér (UNA) és a szolgálati szegmensek (UNB-UNZ) meghatározott sorrendben jelenhetnek meg az adatcserében: Szolgálati füzér Cserefejrész Funkcionális csoport-fejrész Üzenetfejrész

UNA UNB UNG UNH

Felhasználói adatszegmens Üzenetzárórész Funkcionális csoport-zárórész Cserezárórész

UNT UNE UNZ

feltételes kötelezo feltételes kötelezo igény szerint kötelezo feltételes kötelezo

Az említett szolgálati szegmenseken túlmenoen szükség esetén az UNS szolgálati szegmenst fel lehet használni abból a célból, hogy egy üzenetet ezzel több szegmensre lehessen felosztani. Több funkcionális csoport és üzenet lehet egy adatcserén belül és több üzenet egy funkcionális csoporton belül. A következo szegmenssorozatok lehetnek az elozoekben leírt sorrendiséget figyelembe véve: ? Egyetlen üzenet van a funkcionális csoporton belül: UNA UNB UNG UNH adatszegmens UNT UNE UNZ

91


? Egyetlen üzenet van funkcionális csoport nélkül: UNA UNB UNH adatszegmens UNT UNZ ? Egyetlen üzenet van funkcionális csoport és UNA nélkül: UNB UNH adatszegmens UNT UNZ stb. Az UNA szolgálati füzér használata nem kötelezo, hat karaktert tartalmaz, amely az adatcsere során alkalmazott elválasztó és egyéb karaktereket (pl. tizedesjel), a szabvány verziószámát (minden módosítást követoen 1-el no) határozza meg. A szolgálati szegmensek adatelemekbol és összetett adatelemekbol épülnek fel, az elobbiekre négyjegyu numerikus azonosítóval történik a hivatkozás, az utóbbiak jelölésére az S betu és három szám használatos. Az UNA-t (ha használtuk) követo felhasználói adatcsere adatokat az UNB szegmensnek kell megelozni, és UNZ-vel kell lezárni. Az UNB szegmens funkciója az adatcsere elindítása, azonosítása és specifikálása (eloírása), mely tartalmaz SZINTAKSZISAZONOSÍTÓ (UNOA, ha A szint és UNOB, ha B szint), ADATCSERE KÜLDOFÉL ADATCSERE CÍMZETT, ELKÉSZÍTÉS DÁTUMA/IDEJE, ADATCSERE ELLENÖRZO HIVATKOZÁS, CÍMZETT HIVATKOZÁSIA, PASSWORDJE (Az adatcsere szerzodésben kell tisztázni. Akkor használatos, ha a partnerek postaládaszolgáltatáson keresztül küldik adataikat, vagy amikor a fogadó fél rendszerének eléréséhez van erre szükség), ALKALMAZÁS HIVATKOZÁS (üzenet azonosító, ha csak 1 típusú üzenetet tartalmaz), FELDOLGOZÁSI PRIORITÁSKÓD, VISSZAIGAZOLÁS IGÉNYLÉS (Csak az üzenet megérkezését jelzi vissza a címzett, ha a küldo igényli, az üzenet értelmezését nem), TÁVKÖZLÉSI EGYEZMÉNY, TESZT JELZÉS (Ha az adatcsere még csak tesztfázisban fut) összetett adatelemeket. Az UNZ szegmens az adatcsere befejezésére (lezárására) és teljességének ellenorzésére szolgál. ADATCSERE ELLENÖRZOSZÁM (üzenetek vagy funkcionális csoportok száma), ADATCSERE ELLENÖRZO HIVATKOZÁS (ugyanaz, mint UNB). Ennek a két mezonek az ellenorzésével mondható ki, hogy sikeres volt az átvitel. Ha több UNB-UNZ pár szerepel egy adatcsere során, akkor valamennyi UNB-t meg kell elozze egy UNA, ha sem az A, sem a B karakterkészletek nem használatosak. Az UNG szegmens feladata a funkcionális csoport bevezetése, azonosítása, specifikálása Összetett adatelemei: FUNKCIONÁLIS CSOPORT AZONOSÍTÁS (üzenettípus a csoporton belül), ALKALMAZÁSI KÜLDOFÉL AZONOSÍTÓ (cégen belüli osztály), ALKALMAZÁSI CÍMZETT AZONOSÍTÓ, ELKÉSZÍTÁS DÁTUMA/IDEJE (UNB-hez képest korábbi is lehet), FUNKCIONÁLIS CSOPORT HIVATKOZÁSI SZÁMA, FELÜGYELETI SZERV (kód, aki ellenorzi az üzenettípusok – funkcionális csoporton belül – specifikálását, fenntartását, megjelentetését), ÜZENETVÁLTOZAT, ALKALMAZÁS PASSWORD (a címzett

92


osztályának rendszeréhez jelszó). A funkcionális csoport végzodtetését és teljességének ellenorzését az UNE szegmens látja el. Összetett adatelemei: ÜZENETEK SZÁMA, FUNKCIONÁLIS CSOPORT HIVATKOZÁSI SZÁM (ugyanaz, mint UNG-ben). A két adatelem együttesen azonosítja a funkcionális csoport sikeres megérkezését. Az ugyanolyan típusú üzenetek csoportba foglalása használható anélkül, hogy a küldo vagy címzett belso rendszerének címzése szükséges. Ebben az esetben néhány adateleme a szegmensnek ugyanazokat az azonosító adatokat tartalmazza, mint az UNB szegmens megfelelo mezoi. Ilyenkor nincs szükség az alkalmazási jelszóra. Az UNH szegmens szerepe az üzenet bevezetése, azonosítása és eloírása, melynek során ÜZENET HIVATKOZÁSI SZÁM (Ez lehet a program által generált szám – 1-el kezdodik és egyesével no üzenetenként – ha nincs funkcionális csoport, vagy lehet a program által generált szám – 1-el kezdodik és egyesével no funkcionális csoporton belül üzenetenként, vagy a feladó belso rendszere által adott értelmes hivatkozási szám. A generált és az értelmes szám az adatcserén belül nem keverheto össze. A preferáltat az adatcsere szerzodésben kell rögzíteni.) ÜZENETAZONOSÍTÓ (Feltételes adatelemei akkor használatosak, ha az adatcserében nincs funkcionális csoport. A folyamatos üzenetátvitel lényege, hogy egy üzleti fájlhoz kapcsolódó kezdeti adatátvitel után egymásra épülo átvitelek használatosak vagy a korábban átvitt adatok javítására, módosítására, vagy új adattételek hozzáadására. A közlekedési helyfoglalások lehetnek ilyenek.), KÖZÖS HOZZÁFÉRÉS HIVATKOZÁS (Ugyanakkor az üzleti esethez tartozó késobbi adatátvitelek összekapcsolásához.) ÁTVITEL StÁTUSZA (Átvitel sorrendje – több fájl ugyanahhoz a tranzakcióhoz tartozóan a fájlok sorszáma.) összetett adatelemet használ. Az üzenet befejezését és teljességének ellenorzését az UNT szegmens látja el. Összetett adatelemei: SZEGMENSEK SZÁMA AZ ÜZENETBEN (UNH és UNT is), ÜZENETAZONOSÍTÓ SZÁM (ugyanaz, mint UNH-ban) Az UNS (SZAKASZELLENORZÉS) szegmens az üzenet fejrészét, egyéb részleteit és az áttekinto (összefoglaló) részét különíti el. Összetett adateleme: SZAKASZAZONOSÍTÓ (D – fejléc és részletezo elválasztó, S – részletezo és összegzo elválasztó). Ez akkor használatos, amikor egynél több részben azonos felhasználói adatszegmensekre van szükség, de adatelemeikben különbözo értékeket tartalmaznak. Értéke „D”, ha a fejrészt a részletezotol, „S”, ha a részletezot a lezárótól választja el. Az UNS szegmenseket csak a megfelelo pozícióba helyezhetok az üzeneten belül (a 3 üzenetrész elválasztására). 2 UNS szegmensnél több nem szerepelhet egy üzeneten belül.

93


Az UNA, UNB, UNZ, UNG és UNE szolgálati szegmenseken kívül valamennyi adatnak egy üzeneten belül kell elhelyezkednie. 4.3 Üzenetkidolgozás, a szabvány karbantartása A Nyugat-Európában jelentkezo igények nyomán szükségessé váló új, nemzetközi EDIFACT-üzenetek kidolgozását a szakterület szerint illetékes üzenetkidolgozó csoport végzi. A kidolgozás elso lépcsoje a helyzetfeltárás, majd ezt követi az üzenettervezet elkészítése. A megfelelo készültségi szinten lévo tervezeteket az EGB WP.4-es számú munkacsoportja tájékoztatásul közzéteszi. Ez az üzenet szélesebb köru megismertetését jelenti, és egyben lehetoséget teremt a véleményezésre. Az üzenet ekkor kerül a 0-ás kidolgozási státusba. Az üzenet a legutóbb kiadott adattárspecifikációkra épül, de szükség esetén tartalmazhat új vagy módosított szegmenseket, összetett adatelemeket vagy adatelemeket, illetve kódolt adatelemekhez tartozó kódértékeket. Amikor az üzenet kidolgozói úgy látják, hogy az üzenet megfelel a lefedni kívánt üzleti funkciónak és minden adatigénynek, akkor az üzenetet muszaki szempontból is értékelik. Ennek célja, hogy az üzenet konzisztens legyen a már elfogadott üzenetekkel, tehát egyetlen részében se mondjon ellent azoknak. A továbbiakban az üzenetet ajánlástervezetként vagy 1-es státusú tervezetként a munkacsoport elé terjesztik jóváhagyásra. Az üzenetet azért adják ki tervezetként, hogy tisztázzák, megfelel-e a használók igényeinek. Ha ez sikeres, akkor az üzenet 1-2 éves próbaidoszak után szabványos, 2-es kidolgozási státusú ajánlássá, ENSZ-üzenetté (UNSM - United Nations Standard Message) válik. Az üzenetet a munkacsoport akkor fogadja el 2-es státusú üzenetként, ha beigazolódott, hogy az megfelel az adott üzleti funkciónak. A kidolgozási alapciklus lezárultával a 2-es státusú üzeneteket rendszeresen felülvizsgálják. A felülvizsgálat oka lehet, hogy az adott üzenetre (a specifikációra) módosítási kérelem érkezett, de módosításra adhat okot más üzenetek változása, az üzenetek egységes szempontoknak való megfeleltetése (a konzisztencia iránti igény) is. Az üzeneteket folyamatosan karban kell tartani. A használók gyakran kérik a meglevo üzenetek módosítását, illetve az üzleti követelményekhez igazodó új üzenetek kidolgozását. Ugyanakkor más használók a megvalósításba fektetett munka értékének megorzése miatt stabil, „befagyasztott” specifikációkat igényelnek az alkalmazásokhoz. Az ilyen ellentétes érdekeket az üzenetspecifikáció az ún. üzenetváltozat-kezelo koncepció segítségével szünteti meg.

94


Az üzenetkidolgozási folyamat változásának eredményeként az üzeneteket a jövoben összefoglaló EDIFACT-üzenettárban adják majd ki. Az üzenettár vagy csak az elfogadott (2-es kidolgozási státusú), szabványos ENSZ-üzeneteket tartalmazza, vagy a 2-es státusú üzenetek mellett szerepelteti az 1-es státusúakat is. Az üzenettár egyúttal megadja a szegmenstár, az összetett adatelem-tár, az adatelemtár és a kódlisták tartalmát is. Például az adatelemtár csak azokat az adatelemeket tartalmazza, amelyek az üzenettár egy vagy több üzenetében megtalálhatók. Az együtt közreadott adattárak elnevezése EDIFACT-szabványtár vagy EDIFACTtervezettár. Az EDIFACT-szabványtár kizárólag 2-es státusú üzeneteket, míg az EDIFACT-tervezettár más státusú üzeneteket is tartalmaz. Az adott tár mindig egy meghatározott karakter-kombinációval azonosítható, amelynek elso karaktere vagy „S” – ez a szabványtárat jelöli –, vagy „D”, amely a tervezettár megjelölésére szolgál. A következo két szám a kiadás évét jelöli, az azokat követo betu pedig azt mutatja, hogy az adott tár hányadik kiadás az adott évben (pl. D97A). Jelenleg a szakemberek évi egy EDIFACT-szabványtár és egy vagy két EDIFACTtervezettár kiadását tartják célszerunek. Az eddigi tapasztalatok azt mutatják, hogy a felhasználók az adattárak kiválasztásakor fontosabb szempontnak tekintik a stabilitást, az üzenetek funkcióit, mint azt, hogy az adott tár szabvány- vagy tervezettár-e. Ebbol következoen a jövoben várható, hogy ritkábban adnak ki új adattárakat. Az adattárakhoz és üzenetekhez hasonlóan az EDIFACT-szintaktika átvizsgálása és kiadása is változatokban történik. A szintaktika jelenti az EDIFACT-tal kapcsolatos valamennyi fejlesztomunka alapját, ezért eddig csak néhány módosított változat kiadására került sor. Mivel az EDIFACT-adattárak és az EDIFACT-szintaktika felülvizsgálata nem egyforma idoközökben történik, a szintaktikaváltozatokat az adattáraktól elkülönítve kezelik. Mindebbol következik, hogy a szintaxis részeként definiált szolgálati szegmenseket, szolgálati összetett adatelemeket és szolgálati adatelemeket el kell különíteni az adattáraktól. Ennél fogva ezeket az elemeket a szintaktikával együtt teszik közzé. Az EDIFACT-fejlesztés célja olyan általános szabványok kidolgozása, amelyek megfelelo környezet megteremtésével az egész világ EDI-alkalmazóinak igényeit ki tudják elégíteni. A meghatározott funkciót hordozó EDIFACT-üzeneteket (üzenetmaszk – subset) úgy alakítják ki, hogy az alkalmazó területtol függetlenül minden információs igénynek megfeleljen. Az így létrejövo üzenet széles körben alkalmazható. A tág

95


kereteket adó üzenetstruktúra lehetové teszi, hogy az adatokat többféleképpen is el lehessen helyezni az üzenetben. Az EDIFACT-üzenet létrehozásakor az alkalmazó esetenként a szegmenseknek csupán a 10-30%-át, az adatelemeknek és kódoknak pedig esetleg még kisebb hányadát használja fel a saját üzenetének összeállításához. Az ENSZ-EDIFACT-szintaktika lehetové teszi az üzenetek ilyen mértéku egyszerusítését, így ez technikai szempontból nem okoz problémát. Mindemellett az alkalmazóknak szükségük van a segítségre az üzenetek létrehozásához. A hatékonyabb összehangolás érdekében a fobb szakmák és ágazatok számára megvalósítási irányelvek készülnek. Az ilyen irányelveket készíthetik nemzeti szervezetek vagy nemzetközi használói csoportok. A használói csoport feltárja az adott közösség, szakma vagy szektor által a szabványos EDIFACT-üzenetekkel szemben támasztott igényeket. Az így feltárt igényeket megvalósítási kézikönyvben adják ki tagjaiknak. Az EDI-kézikönyvekben rendszerint a közös kódrendszerre, a szintaktikára, a szabványos adatcsereszerzodésre és a kommunikációs eloírásokra vonatkozó ajánlások is szerepelnek. A megvalósítási kézikönyv elkészítése rendszerint az üzleti és információs folyamatok modellezésével kezdodik. A modellkészítés célja egy olyan közös, egységes és szigorúan kötött módszer kidolgozása, amellyel leírhatók az üzleti folyamatok, és meghatározható, strukturálható az információ, amely ezekhez a folyamatokhoz kapcsolódik. A modellezés eredménye az adatcseréhez szükséges, funkciókhoz kötodo információhalmazok meghatározása. (Lásd 1. fejezet) Miután kiválasztottuk, hogy mely funkciókat kell EDI-üzenetekkel lebonyolítani, a funkcionális információhalmazhoz hozzárendeljük a megfelelo EDIFACT-üzenetet. Ez utóbbi két részbol áll: eloször definiálják az adott EDIFACT-üzenet üzenetmaszkját (subset-jét), majd kidolgozzák a gyakorlati alkalmazás szabályait, konvencióit. Az ennek során kialakuló füzet tartalmazza az adott használói csoportnak a szóban forgó EDIFACT-üzenetre vonatkozó megvalósítási kézikönyvét. 4.4 Üzenettervezés Új üzenet tervezése elott az üzenet készítojének a megfelelo szervekkel fel kell vennie a kapcsolatot (raportorök, EDIFACT szabvány terjesztoi az adott országban), mivel a szükséges üzenet már létezhet, vagy egy meglévo javításokkal képes ellátni a kívánt feladatot, vagy esetleg az üzenettervezési munka már elindult azonos vagy hasonló üzenet kapcsán. Az új üzenetek meghatározott szabályok és útmutatók alapján készülnek. Ezeket az üzenettervezési irányelveket a következoknek szánták:

96


? Azok, akik beadnak egy tervüzenetet jóváhagyásra szabványos üzenetnek. Ennek érdekében: ? a javasolt üzenetet nemzetközi használatra kell tervezni; ? nem lehet már szabványos üzenet ugyanazzal a funkcióval, vagy amelyik átfogja ezt a funkciót; ? a javaslattevonek el kell fogadnia, hogy az üzenet egy közös tervezés tárgya, ha másik szektor és/vagy raportori csoport jelzi az érdeklodését az üzenet fejlesztésben való részvételre. ? Azok, akik módosítási javaslatot terjesztenek elo egy már meglévo szabványos üzenethez. ? A raportori csoportoknak. Az üzenettervezés folyamatához kapcsolódó dokumentumok: ? Útmutatók és szabályok ? ISO 9735 EDIFACT szintaktikai szabályok; ? UN/EDIFACT Syntax Implementation Guidlines – szintaxis megvalósítási útmutató; ? UN/EDIFACT Message Design Guidlines – Üzenettervezési útmutató; ? UN/EDIFACT Rapporeur’s Procedures and Message documentation rules – raportori eljárások és üzenetdokumentációs szabályok; ? Tárak: ? UNTDID – United Nations Trade Data Interchange Directory – ENSZ kereskedelmi adatcsere tára: ? ? ? ? ? ? ? ? ?

EDMD – EDIFACT messages directory – üzenettár; EDSD – EDIFACT segments directory – szegmenstár; EDCD – EDIFACT Composite data elements directory – összetett adatelemtár; EDED – EDIFACT Data Elements directory (az UNTDED része) – adatelemtár; EDCL – EDIFACT Code List directory - kódlistatár

? UN/EDIFACT Working Directory Set – ENSZ/EDIFACT munka tárkészlete: TRMD – Trial Message Directory – Próba üzenettár; TRSD – Trial Segments Directory – Próba szegmenstár; TRCD – Trial Composite Data Elements Directory – Próba összetett adatelemtár; TRED – Trial Data Elements Directory – Próba adatelemtár.

A tervezés során figyelembe kell venni, hogy az EDI üzeneteknek egy tisztán megfogalmazott üzleti funkcióval kell rendelkezni.

97


Az EDI üzenetek adattartalma és adatainak sorrendje nem feltétlenül kell azonos legyen annak a papírdokumentumnak az adattartalmával, amelyikre készül az elektronikus üzenet. Bár egy üzenet funkciója ugyanaz lehet, mint egy papírdokumentumé, az üzenettervezok számára ez nem jelenti feltétlenül azt, hogy ugyanazok az adatelemek szükségesek az elektronikus üzenethez, mint az egyenértéku papírüzenetben használtak. Továbbá új üzenet terezésekor van alkalom a hagyományos funkcionalitás elemzésére, mivel sokkal hatékonyabb lehet egy új megközelítés, mint egyszeruen utánozni az eredetit. Bizonyos esetekben az üzenetek funkciója ugyanaz lehet, mint a hagyományos papír dokumentumoknak vagy üzleti folyamatoknak. Más esetekben egy egyszeru üzenet funkcionálisan egyenértéku lehet több papírdokumentummal együttesen. Az üzenettervezés kezdeti fázisában praktikus lehet a szegmenseket és szegmenscsoportokat az egyenértéku papírdokumentum adatsorrendjét követo sorba rendezni, ami segít az üzenet funkciójának értelmezésében, de a végso fázisban a szintaktikai szabályok által megengedett csonkítások, elhagyások elonyeit számba kell venni. Az üzenettervezéshez két fontos szaktudásra van szükség, az egyik az adott üzleti terület ismerete, amelyre az üzenet készül (kereskedelmi, banki, közlekedési stb.), a másik jártasság az üzenettervezési irányelvekben, az üzleti és információs modellezésben és a számítógépes rendszerekben. 4.4.1 Az üzenettervezés lépései A tervezési folyamat szándéka, hogy az adatcsere igényeket minimális összetettséggel és redundanciával elégítse ki. A célok a következok: ? támogatni a jól meghatározott és megértett üzleti igényeket; ? viszonylagos egyszeruség (funkció és tervezés szempontjából) és ? elkerülni a szükségtelen versengést a papíralapú folyamatokkal. Az érvényes EDIFACT munkakönyvtárat kell használni a meglévo üzenetek és szegmensek áttekintésére, és ezt lehet felhasználni az új üzenet tervezésének kiindulópontjául. Ha a felhasználók egy csoportjának nemzetközi igényeket lefedo EDI üzenetre van szüksége, akkor eloször ellenorizni kell, hogy egy már létezo üzenet lefedi-e a megfelelo funkciót, amibol esetleg egy üzenetmaszk készülhet. Ha nincs ilyen akkor egy meglévon módosításokat kezdeményezhetnek, vagy egy teljesen új üzenet iránti igényt nyújtanak be a megfelelo szerveknek. A következo leírás az üzenettervezés lépéseit ismerteti:

98


1. Az üzleti igények elemzése. 2. Az üzleti környezet kulcs aspektusainak modellezése. 3. Az üzleti funkció kielégítésére alkalmas EDI üzenet meghatározása. Ellenorizni kell, hogy az EDIFACT munkakönyvtárban lévo üzenetek között van-e már olyan, ami felhasználható vagy módosítással megfelel a célnak. 4. A legmegfelelobb üzenet kiválasztása és üzleti funkció adása az üzenetnek. Ha már ebben a stádiumban eldol, hogy új üzenetre van szükség, akkor az új üzenet igénylési formanyomtatványt be kell nyújtani a megfelelo titkárságnak. 5. A szükséges üzleti adatok részletes megadása. 6. Az EDIFACT munkakönyvtárból a szegmensek kiválasztása és szabványos üzenetekben már meghatározott szegmenscsoportok használatának felülvizsgálata. 7.

7.1. Létezo EDIFACT szegmensek által nem lefedett adattételek meghatározása. 7.2. Megvizsgálni, hogy ezen adattételek egy általánosan használatos szegmenssel minosíto érték felhasználásával megadhatók-e. Ha nem akkor ellenorizni kell, hogy az aktuális EDIFACT munka adatelemkönyvtárban, vagy a kereskedelmi adatelemkönyvtárban már léteznek-e. Ha nem akkor be kell adni egy új adatelemre vonatkozó kérelmet. 7.3. Megvizsgálni, hogy az igényelt adattételeket hozzáadva egy létezo EDIFACT szegmenshez vagy összetett adatelemhez a helyes funkciót kapjuk-e. 7.4. Kategorizálni a maradék adattételeket koncepcionálisan kapcsolódó csoportokba, funkcionális leírást adni minden egyes csoporthoz az új szegmens készítését támogatandó. 7.5. Meghatározni minden egyes adatelemhez, összetett adatelemhez, szegmenshez, szegmenscsoporthoz a kötelezo és feltételes státusokat és a megengedett ismétlések számát. 4.4.2 Az üzenet alkotórészeinek tervezése Adatelem tervezés Ha egy új adatelemet kell tervezni, akkor annak általánosnak kell lennie lehetové téve a legszélesebb köru felhasználást.

99


Miután az igényelt összes adatelem meghatározásra került, amelyek az üzenet funkcióját kielégítik, ki kell deríteni, hogy az adatelemek már léteznek-e az aktuális EDIFACT munkakönyvtárban. A lépések a következok: 1. Ha az igényelt adatelem megtalálható és megegyezik a felhasználói elvárásokkal, akkor azt kell felhasználni. 2. Ha az igényelt adatelem megtalálható, de a neve, leírása és/vagy formátuma/megjelenése nem teljesen a felhasználói igényeknek megfelelo, akkor a módosítás iránti igény eljárásait kell követni. 3. Ha az igényelt adatelem nem található, egy új adatelem iránti igényt kell benyújtani a megfelelo szervnek, szükség szerinti hivatkozással az adatelemtárra. Kódolt adatelemek esetében: 1. Ha az igényelt kódolt adatelem megtalálható, és az igényelt kódérték létezik a kapcsolódó kódlistában, akkor azt az elemet kell felhasználni. 2. Ha az igényelt kódolt adatelem megtalálható, de az igényelt kódérték nem, egy új kód iránti igényt kell benyújtani. 3. Ha egy új kódolt adatelem iránti igény benyújtását kell kezdeményezni, akkor minden egyes adatelemre vonatkozó kérelmet be kell nyújtani, amelyik a kódolt értéket tartalmazza. Az új adatelem tervezésének szabályai: 1. szabály: Mindig már létezo, minosített adatelemet részesítsünk elonyben új adatelem készítése helyett. 2. szabály:

A következo névadási és formázási konvenciók jelennek meg az EDIFACT adateleme könyvtárban:

a) Egy adatelem, amely minosít egy egyszeru vagy összetett adatelemet, szegmenst, a nevében a „qualifier” – minosíto szó a végén szerepel. A minosíto formátuma an..3. A minosítok kódlistái csak az EDCL-ben vannak meghatározva. b) A nem minosíto kódolt adatelem nevében „coded” – kódolt szó a végén szerepel. A nem minosíto kódolt adatelem formátuma: an..3. c) Más kódolt adatelem nevében az „identification” – azonosítás a végén szerepel. Formátuma an..x, ahol x>3. d) Az UNTDED-ben már meghatározott alfanumerikus adatelemek ugyanazzal a névvel és formátummal elfogadhatók az UNTDID-ben is.

100


e) Az UNTDED-ben még nem specifikált új alfanumerikus adatelemek formátuma an..17, an..35 vagy an..70 lehet, az üzleti igények által meghatározott megfelelo névvel együtt. f) Más adatelemek formátumát és nevét az üzleti igények szerint kell meghatározni. A kódolt adatelemek értékei a kódlista könyvtárban találhatók meg. 3. szabály: A minosítoként használt kódolt adatelemekhez nem kapcsolódhatnak a 1131 (Kódlista azonosító kód) és a 3055 (Kódlistáért felelos hivatal kódja) adatelemek. 4. szabály:

Az általános, kódolt, egyszeru adatelemeket összetett adatelemben kell elhelyezni együtt a feltételes 1131 és a 3055 adatelemekkel.

Összetett adatelem tervezés Amikor az üzenettervezés során összetett adatelemekre van szükség, akkor az üzenetkészítonek a következo szempontok szerint tisztáznia kell, hogy az igényelt összetett adatelemek már léteznek-e az aktuális UN/EDIFACT munkakönyvtárban, ha igen felhasználhatók-e a kívánt célra: 1. Ha a szükséges összetett adatelem megtalálható és megegyezik a felhasználói igényekkel, akkor azt kell használni. 2. Ha a szükséges összetett adatelem megtalálható, de a neve, leírása és/vagy formátuma/felhasználási területe nem pontosan egyezik meg a felhasználói igényekkel, akkor a változtatási kérelemre vonatkozó eljárást kell követni. 3. Ha a szükséges összetett adatelem nem található, akkor egy új összetett adatelem iránti igényt kell benyújtani. Megkülönböztetünk minosített és nem minosített összetett adatelemeket. A nem minosített önmagában is képes egy adott funkciót értelmesen ellátni, a minosített esetében egy minosítore van szükség, hogy meghatározza a pontos funkciót vagy értelmezi az adattartalmat. Minosített összetett adatelemek használatával jelentosen csökken az összetett adatelem könyvtárban lévo tételek száma és nagy fokú rugalmasság biztosítható. Ugyanis elegendo lehet a minosíto kódlistáját kiegészíteni a szükséges adatértelmezés érdekében. Az összetett adatelemek tervezési szabályai: 5. szabály: Az összetett adatelemnek egy meghatározott funkciót kell ellátnia, amihez közvetlenül kapcsolódnia kell az összetevo adatelemeknek.

101


6. szabály:

Az összetett adatelemnek két vagy több összetevo adatelemet kell tartalmaznia.

7. szabály:

Az összetett adatelemet az UN/EDIFACT összetett adatelem munkakönyvtárából kell kiválasztani, hacsak az igényelt funkciót nem lehet elérni

? egy új minosíto érték hozzáadásával a már létezo minosített összetevo adatelemhez, vagy egy új minosített összetevo adatelem hozzáadásával. ? egy összetevo adatelem hozzáadásával a már létezo összetett adatelemhez. 8. szabály:

Az új összetett adatelemek nem tartalmazhatják a teljes összetételét egy már meglévo összetett adatelemnek és a funkcióját sem duplikálhatják.

9. szabály:

Az új összetett adatelemeket úgy kell megtervezni, hogy széles felhasználási területe legyen.

10. szabály: A minosítot, ami speciális jelentést biztosít, közvetlenül az általános egyszeru adatelem után kell elhelyezni. Mindkét adatelem együtt egy összetett adatelemet alkot. 11. szabály: Ha egy minosített összetevo adatelem más adatelemekkel együtt alkot összetett adatelemet, akkor a minosítonek a minosített adatelem után kell megjelennie. 12. szabály: Ha egy összetett adatelemet minosítünk akkor a minosítot az összetevo adatelemek elé kell elhelyezni (a minosítés valamennyi összetevo adatelemre vonatkozik). 13. szabály: Az összetett adatelemek minden kötelezo összetevo adateleme meg kell elozze a feltételes összetevo adatelemeket. 14. szabály: Az összetevo adatelemeket maximum ötször lehet ismételni egy összetett adatelemen belül, és csak akkor, ha az üzenettervezok csoportja tényleges üzleti indokot talál. 15. szabály: a) A kódból és alfanumerikus adatpárból álló részei az összetett adatelemnek maximum kétszer ismételheto, ha az alfanumerikus rész formátuma an..35. b) A kódból és alfanumerikus adatpárból álló részei az összetett adatelemnek nem ismételhetok, ha az alfanumerikus rész formátuma an..70. c) Az FTX szegmenst kell használni a szegmenscsoportban az összetett adatelem alfanumerikus összetevo adatelemei helyett, ha több mint 70 karaktert kell adatként megjeleníteni. Az UN/EDIFACT összetett adatelem karbantartásának szabályai:

102


16. szabály: Ha összetevo adatelemet adunk hozzá egy összetett adatelemhez, akkor annak végére kell tenni. A kivételek a következok: a) Ha beszúrásra jóváhagytak egy kötelezo összetevo adatelemet egy összetett adatelembe, vagy b) ha a 1131 és 3055 összetevo adatelemeket kell beszúrni a kódalfanumerikus adatelem párok közé egy már létezo összetett adatelemen belül. Ha a fenti javítások bármelyikét jóváhagyják, akkor egy új címkét kell adni és az eredeti összetett adatelemet három év múlva végrehajtandó törlésre kell megjelölni a következo munkakönyvtárban. 17. szabály: Az összes új üzenetben, ha kell mindig az új összetett adatelemeket kell használni. 18. szabály: A három éves periódus végén a törlésre megjelölt összetett adatelemeket le kell cserélni az összes kapcsolódó szegmensben és üzenetben az új összetett adatelemre. Szegmensek tervezése Üzenet tervezésekor az UN/EDIFACT munkakönyvtár már létezo szegmenseit kell használni új szegmensek tervezése helyett. Létezo szegmensek használatával felgyorsítható az üzenettervezés és a megegyezés az ágazati és nemzeti határok átlépésével. Mielott egy új szegmens tervezésére kerül sor a következo lehetoségeket kell figyelembe venni: a) Ha egy minosített szegmens lefed egy létezo funkciót, akkor a szegmens minosítot lehet felhasználni, hogy az igényelt jelentést megkapja a szegmens. Ilyenkor a minosíto kódlistáját kell kiegészíteni. b) Ha a kívánt funkció eléréséhez egy adatelemet adva a létezo szegmens végére az igény teljesítheto, akkor a módosítási igény folyamatát kell követni. c) Ha a kívánt funkció két vagy több létezo szegmens használatával megadható, akkor ezeket szegmenscsoportba kell foglalni. Ha egy új szegmenst kell tervezni, akkor annak szélesköruen alkalmazhatónak, általánosnak kell lennie. Általános szegmensek tervezésével a szegmenst szegmenscsoportokba foglalva lehetséges különbözo funkciók kifejezése. Ez

103


azonban semmilyen körülmények között nem vezethet oda, hogy bizonyos speciális igények ne legyenek kielégíthetok. Ilyenkor speciális szegmensek tervezésére van szükség. A szegmensen belüli összetett és összetevo adatelemek státusát (kötelezo, vagy feltételes) a tervezéskor el kell dönteni. A kötelezo adatok a feltételeseket meg kell elozzék a szegmensben. Ha a különbözo üzenetekben felhasznált szegmens adateleme az egyik üzenetben kötelezo, a másikban feltételes, akkor az adatelemnek feltételesnek kell lennie és a használatot az üzenet alkalmazási útmutatójában kell specifikálni. Megkülönböztetünk minosített és nem minosített szegmenseket. A nem minosített szegmenseknél nincs szükség a funkció meghatározásához minosítore. A minosített szegmens speciális használatát a megfelelo szegmens minosíto kód határozza meg. Minosített szegmensek használatával jelentosen csökken a szegmens könyvtárban lévo tételek száma és nagy fokú rugalmasság biztosítható. Ugyanis elegendo lehet a minosíto kódlistáját kiegészíteni a szükséges adatértelmezés érdekében. Ezt a technikát kell elonyben részesíteni az ugyanarra a célra készített új és speciális szegmensek tervezése helyett. 19. szabály: Az új szegmensnek egy meghatározott funkciójának kell lenni (ami minosítés alapján is történhet). A szegmensnek elegendo egyszeru és/vagy összetett adatelemeket kell tartalmaznia, hogy teljesítse a funkcióját és az elemeinek közvetlenül kapcsolódnia kell a szegmens funkciójához. 20. szabály: Az új szegmens nem tartalmazhatja a teljes tartalmát egy létezo szegmensnek, vagy nem duplikálhatja egy létezo szegmens funkcióját. 21. szabály: Az adatelemek és/vagy összetett adatelemek státusát meg kell határozni (feltételes vagy kötelezo). 22. szabály: Minden kötelezo egyszeru és/vagy összetett adatelemeket a szegmens elejére kell helyezni megelozve a feltételes egyszeru és/vagy összetett adatelemeket. 23. szabály: A szegmenscímkében az U kezdobetu használata az ISO 9735 szerint foglalt a szolgálati szegmensek számára, ezért az nem használható. 24. szabály: A minosítot, ami speciális jelentést ad a minosített szegmensnek, kötelezo adatelemként közvetlenül a szegmenskód után kell elhelyezni elso adatelemként. 25. szabály: Egyszeru és összetett adatelemek nem ismételhetok a szegmensen belül. Ha többszörös ismétlésre van szükség, akkor a szegmenst kell ismételni az üzenet szintjén.

104


26. szabály: Akkor lehet maximum ötször megismételni ugyanazt az egyszeru és összetett adatelemet, ha egy meggyozo üzleti érvet határoz meg az üzenettervezok csoportja az új szegmens igénylése során. 27. szabály: Két vagy több különbözo összetevo adatelembol álló csoport nem ismételheto meg a szegmensen belül. UN/EDIFACT szegmensek karbantartásának szabályai: 28. szabály: Szegmens bovítésekor az egyszeru és összetett adatelemeket a szegmensek végére kell hozzáadni. Csak a következo kivételek léteznek: a) ha kötelezo egyszeru vagy összetett adatelemet beszúrásra hagytak jóvá egy szegmensbe, vagy b) ha a 3 év elmúltával törlésre megjelölt adatelemet kicserélik a helyettesítojével. Ha az egyiket jóváhagyták az elozo módosítások közül, akkor egy új szegmens kódot kell megadni és az eredeti szegmenst törlésre kell megjelölni, amit 3 éves idotartam után hajtanak végre. 29. szabály: Az összes új üzenetnek mindig az új szegmenseket kell használni, ha azokra szükség van az üzenetben. Szegmenscsoportok tervezése Az üzenetek nagy része feltételes szegmenscsoportokból áll, ez lehetové teszi az üzenetek rugalmas használatát. A szegmensek csoportosítása lehetové teszi a szegmensek strukturált módon történo összekapcsolását. A szegmenscsoport, amely egy másik szegmenscsoporton belül található meg közvetlenül nem elérheto csak a „szülo” szegmensen keresztül. Ez azt jelenti, hogy legalább a „szülo” szegmenscsoport trigger szegmense szerepeljen az átvitel során, ha a beágyazott szegmenscsoportra az átvitel során szükség van. A tervüzenetek fejlesztése során a tervezoknek gyakran kell módosítani az eredeti elképzeléseiket az üzenetek struktúrájára és tartalmára vonatkozóan, ismétlodo folyamatok során alakul a végso változat. 30. szabály: Minden szegmenscsoport egy nem ismétlodo kötelezo szegmenssel kell kezdodjön. 31. szabály: Egy szegmenscsoport, amely egy másik szegmenscsoportba van beágyazva saját trigger szegmenssel rendelkezik és csak a megelozo („szülo”) szegmenscsoporton keresztül lehet elérni.

105


A szegmenscsoporton belül egyedül álló szegmensek (nincsenek hierarchiailag alattuk, tolük függo szegmensek) közvetlenül a szegmenscsoport kötelezo trigger szegmense után helyezkednek el, amelyikhez tartoznak azért, hogy csökkenjen a szegmensütközés veszélye. Szegmensütközés a következo esetekben fordulhat elo: 1. Ha két vagy több szegmens azonos szegmenskóddal úgy jelenik meg egy üzeneten belül, hogy nincs közöttük másik szegmenskódú kötelezo szegmens ugyanazon vagy magasabb szinten. 2. Ha két vagy több szegmens azonos szegmenskóddal úgy jelenik meg egy üzeneten belül, hogy nincs közöttük kötelezo szegmenscsoport eltéro szegmenskódú trigger szegmenssel. Néhány esetben egy kötelezo más szegmenskódú szegmens is szükséges az ütközo szegmens után az ütközés elkerülése érdekében. A szegmensütközéskor fellép az a rizikó, hogy az üzenetet fogadó konverter helytelenül kapcsolja össze (társítja) az azonos szegmenseket. Üzenettervezés szabályai 32. szabály: Az üzenet szegmensek és/vagy szegmenscsoportok rendezett sora, amely UNH szegmenssel kezdodik és UNT szegmenssel zárul. Legalább 1 további szegmensnek vagy szegmenscsoportnak kell megjelennie a két szolgálati szegmens között. 33. szabály: Az aktuális UN/EDIFACT munkakönyvtár tartalmát kell használni az üzenetfejlesztés kezdetén. 34. szabály: A javasolt új üzenet nem duplikálhatja egy már meglévo üzenet funkcióját. 35. szabály: Az üzeneteket nemzetközi használatra kell tervezni. 36. szabály: A meglévo üzenetstruktúrában végrehajtott módosításnak idomulnia kell a megállapított üzenet funkcionalitáshoz vagy az üzenet funkcionalitását kell megváltoztatni az üzenet megváltozott struktúrájának megfeleloen. 37. szabály: Az üzenet szerkezetét szegmensütközés nélkül kell kialakítani. 38. szabály: Minden egyes üzenettípusnak kell legyen egy hatbetus azonosítója. A tervezoknek a saját választásuk szerinti kódot kell javasolni, amit a raportori csoportnak kell ellenorizni a kódduplikáció elkerülése érdekében.

106


39. szabály: Az UNS szolgálati szegmens csak azért használható, hogy a szegmensütközést elkerüljük az üzenet fejrésze, a részletezo és az összegzo részei között. 40. szabály: Maximum 2 UNS szegmens lehet egy üzeneten belül. Az UNS szegmensek nem ismételhetok és kötelezoek. Amennyire lehet a felhasználóknak a már létezo szabvány üzeneteket célszeru használni. Elsore azonban a felhasználó azt tapasztalja, hogy az üzenet feleslegesen összetett. Közelebbrol megvizsgálva azonban kiderül, hogy legtöbbször a szegmensek és a szegmenscsoportok feltételesen használatosak. Ez azért van mert az üzeneteket nemzetközi és nemzeti használatra a gazdaság széles spektrumának használatára tervezték. Mivel a feltételes szegmensek teljesen elhagyhatók az üzenetbol, a felhasználói igények kielégíthetok az üzenetben meghatározott szegmensek relatíve kis részének felhasználásával. Amennyiben ez nem lehetséges, akkor az üzenettervezési útmutatót kell tanulmányozni. Üzenetstruktúra tervezése Az üzenet dokumentációjának kialakítása egy ENSZ dokumentumban van meghatározva, amelyek a raportori titkárságokon szerezhetok be. Ha az üzenet funkciója és tartalma már eldöntött, akkor az üzenet szerkezetét kell megtervezni. A továbbiakban az üzenet leíró, szöveges ismertetésén kívül az üzenet dokumentációjában meg kell jeleníteni a grafikus branching diagramot és a szegmens táblát. Ezek az üzenet logikai struktúráját mutatják be, a szegmensek, szegmenscsoportok sorrendjét és kapcsolatait határozzák meg azok státusával együtt. A státus és az ismétlésszám jelentése: M x – kötelezo minimum egyszer, maximum x-szer szerepelnie, C x – ha szükséges, akkor egyszer, maximum x-szer ismételheto, de az is lehet, hogy egyszer sem. Ez a szegmensekre, szegmenscsoportokra egyaránt vonatkozik. Az üzenettervezési szabályok szerint két lehetoség van az áruszállítás elektronikus okmányainak kialakítására: ? Már létezo üzenet felhasználásával üzenetmaszkot létrehozva. ? Teljesen új üzenet tervezése. Az EDIFACT üzenettár alapján az elso változatot találtam a kedvezobbnek, mivel léteznek olyan szabvány üzenetek, amelyek felhasználhatók az elozo fejezetben megfogalmazott célokra. Új üzenet tervezése hosszadalmas, összetett feladat,

107


amelynek eredménye az áruszállítás esetében nem jelentene – a már létezokhöz képest – lényegesen eltéro szabványüzenet-kialakítást. Üzenetmaszkok (subset-ek) Az üzenetmaszk olyan üzenet, amely EDIFACT-üzenetbol származik, azzal azonos funkciójú, de sokkal inkább konkrét körülményekre szabott. Az adott üzleti funkciót hordozó üzenetmaszk tartalmát a szakma, a szektor vagy az ágazat, esetleg az EDIpartner igényei határozzák meg. Az üzenetmaszk összeállításának technikája az alábbi, egyszeru tervezési elveken alapul: ? Az üzenetmaszk csak az EDIFACT-üzenetben meghatározott információegységeket tartalmazhat (pl. szegmenscsoportokat, szegmenseket, összetett adatelemeket, adatelemeket). Nem lehet további szegmenseket, összetett adatelemeket vagy adatelemeket az üzenethez hozzádni. ? Az üzenetmaszknak tartalmaznia kell az EDIFACT-üzenet minden kötelezo információegységét. Ezenkívül tartalmazhatja az EDIFACT-üzenet bármely szabadon használható elemét. Feltételesen használatos szegmenscsoportok tartalmazhatnak kötelezo szegmenseket, ilyenkor a teljes csoport elhagyható a subsetbol. ? Az EDIFACT-üzenetbol az üzenetmaszkba is felvett üzenetelemeknek az EDIFACT-üzenetben megadott sorrendet kell követniük. ? Az EDIFACT-üzenetbol az üzenetmaszkba felvett üzenetelemek státusának (M kötelezo; C - feltételes) meg kell egyeznie az EDIFACT-üzenetben szereplo elemek státusával. A szegmenscsoportok, szegmensek sorrendje, összetétele nem változhat meg, ugyanez vonatkozik a szegmensen belüli összetett és öisszetevo adatelemekre. ? Az üzenetmaszknak az üzenetazonosítóban (UNH/S009) ugyanazt az értéket kell tartalmaznia, mint az EDIFACT-üzenetnek. A szabványos üzenetek úgy lettek kialakítva, hogy általános használatúak legyenek, különbözo cégek, szervezetek használhassák. Pl. a számla üzenet olyan szegmenseket, adatelemeket használ, amelyek közösen használatosak a számlát alkalmazó applikációk többségében. A többi adatelem és szegmens csak bizonyos alkalmazásokkor használatosak és így csak bizonyos gazdasági területek, cégek használják. Ezért az esetek többségében ipari alkalmazásokhoz igazodó sub-set-eket alakítanak ki és ezek karbantartásáért felelosek. A kialakított sub-set-hez egyedi azonosítót rendelhetünk egy kód formájában, amit az UNH és/vagy UNG szegmensek „Association assigned code” mezojébe kell írni.

108


Ezt javasolt a rapportori csoporttal megkonzultálni egy másik felhasználói csoport hasonló kódjának elkerülése érdekében. Az egyes használói csoportok meghatározott szabályokat, konvenciókat alakítanak ki a különbözo üzenetek alkalmazására. A konvenciók legfontosabb része az a leírás, amely meghatározza, hogyan kell értelmezni az üzleti tevékenységbol kiindulva az adott üzenetet, és rögzíti azt, hogy az üzenet küldoje és fogadója milyen kötelmet vállal, amikor elküldi az adott üzenetet, vagy a kapott üzenetre reagálva cselekszik. A konvenció szabályozza (specifikálja) a különbözo fajta üzenetek egymáshoz való viszonyát is. Eloírhatja például, hogy a „Megrendelés” üzenetet „A megrendelés visszaigazolása” üzenetnek kell követnie, és ezután egy „Lehívás/Szállítási utasítás” üzenet következhet, ha ezt az utasítást a megrendelés nem tartalmazta. Az üzenetmaszkot megvalósítási kézikönyvvel egészítik ki, amely tartalmazza például a használói csoport terminológiáját és az üzenetmaszk elemei közötti megfeleltetést, a különbözo információegységek közötti kapcsolatok leírását, a használói csoport által alkalmazott kódlistákat stb. A következo használatmutatók a megvalósítási kézikönyvben tovább finomítják a feltételesen alkalmazandó információegységekre vonatkozó jelöléseket: R Szükséges (Required). A kézikönyv szerint kötelezo alkalmazni. D Függo (Dependent). Meghatározott feltételek esetén kell alkalmazni. A Javasolt (Advised). Lehetoség szerint alkalmazni kell. O Választható (Optional). Az üzenet küldojének belátása szerint használható. N Nem használatos (Not used). A kézikönyv szerint nem alkalmazható. A megvalósítás során a használók a közös kézikönyvet egyedi igényeikre szabhatják, azaz tovább szukíthetik. Ez azonban csak akkor célszeru, ha vannak olyan információegységek, amelyeket más EDI-kapcsolatokban nem alkalmaznak és nem is fognak alkalmazni. Mindez természetesen attól függ, hogy a szóban forgó szervezet milyen szerepet játszott a használói közösség információmodelljének kidolgozásában. 4.5 Az adatcsereszerzodés Az elektronikus adatcserét alkalmazó partnereknek az elektronikusan lebonyolított kommunikáció kialakítását megelozoen adatcsereszerzodést kötve szabályozzák a közöttük kialakítandó kapcsolatot. A szerzodés – többek között – a küldendo üzeneteket is rögzíti, amelyek tervezése nem a résztvevo partnerek feladata,

109


ugyanakkor elofordulhat, hogy egy üzenetmaszk kialakítását a partnerek egyike készíti vagy közösen végzik el. A tényleges elektronikus kommunikációt megelozo munkafolyamatok rendkívül fontosak a késobbiekre nézve, ami az adatcsereszerzodés megkötése zár le. Természetesen nem csak ketto, hanem több partner is csatlakozhat a szerzodéshez, nyilván ez a folyamatban résztvevok számától függ. Mint látható volt az áruszállítás folyamata is többszereplos. Tulajdonképpen minden adatcsere applikáció adatcsere szerzodésen alapszik, ami felhasználói segédlet kialakítású. Egyszer kell elkészíteni és ugyanúgy kell karban tartani, mint minden számítógépes rendszer kezelési útmutatását. Az adatcsere szerzodés kialakítását megelozo feladatok: ? A funkciók meghatározása, az adatcserénél használatos üzenettípusok meghatározása hivatkozással az elfogadott adatelemekre különös tekintettel azok kötelezo vagy feltételes használati státusukra. ? Az igényelt adatelemek, azok méretének, formátumának meghatározása és a felhasználói adatelemtár összeállítása. (Ez általában az ENSZ adatelemtárára történo hivatkozással történik, amennyiben nemzetközi adatelemek kerülnek használatra.) A nemzeti és az ipari speciális használatú adatelemek esetében helyi megállapodás szükséges. ? A szükséges felhasználói adatszegmensek funkcióinak meghatározása az ENSZ szegmenstárából különös tekintettel azokra a szegmensekre, amelyeket szélesköru használatra (több gazdasági ág, több alkalmazás) alakítottak ki. Új adatszegmensek tervezésére is szükség lehet, amit az üzenettervezési útmutató szerint kell elkészíteni, és a javaslatokat a helyi rapportori felelosnek kell eljuttatni. ? Az alkalmazáskor használt szintaktikai szabályok szintjének meghatározása (A vagy B karakterkészlet). ? Az alkalmazás során a fizikai adatátvitelnél használatos módszer meghatározása. ? Az információk átadásához kapcsolódó törvényi és biztonsági problémák meghatározása, amelyek döntést igényelnek. (Itt kell megjegyezni, hogy az UNCID ajánlások – Uniform Rules of Conduct for the Interchange of Trade Data – Az igazgatás egységes szabályai a kereskedelmi adatok cseréjéhez, megjelöli az összes jogi kérdést, amit figyelembe kell venni. Az UNCID része az UNTDIDnek). ? Javaslatot tenni a közös kódtechnikákra és kódlistákra, amelyet a használói csoport valamennyi tagja alkalmazni fog. ? Javaslatot tenni az adattitkosítási technikákra (ha szükséges).

110


? Javaslatot tenni a teszt fázis formájára, idejére a teljes megvalósítást megelozoen. Az elozoeket figyelembe véve a használati utasításnak a következoket ajánlott tartalmaznia: ? a használt EDIFACT szintaxis szintjének a leírása; ? a megállapodás értelmében alkalmazott karakterkészlet leírása; ? a használt üzenettípusok struktúrájának teljes és részletes leírása (amennyire lehetséges a szabványos üzeneteket kell használni, vagy ha azok nem pontosan felelnek meg, akkor a módosítási útmutatást kell követni az üzenettervezési segédlet szerint); ? használói adatelemtár (felhasználva az UNTDED-t, amennyire lehetséges); ? használói szegmenstár (felhasználva a szabványos szegmenseket, amennyire lehetséges); ? használói üzenet könyvtár; ? részletezése a betartandó jogi/ biztonsági igényeknek; ? a felhasznált kommunikációs szolgáltatás leírása; ? a használt átviteli rekordok hosszának specifikálása (aminek állandónak kell lenni a felhasználási területen); ? a használt hibajavítási, nyugtázási technika megjelölése; ? a funkcionális csoportok használatának szükségességére vonatkozó rész; ? a használt adatvédelem típusának megjelölése; ? a használt jelszó típusára vonatkozó jelzés. A szolgálati szegmensek bizonyos adatmezoihez (amelyek a szintaxist határozzák meg) az adatcsereszerzodésnek kell megjelölni a kódlistákat, a minosítok listáját stb. Nyomatékosan ajánlott néhány adatcsere karbantartással foglalkozó szervezet létrehozása. Az egyik ilyen szervezet felelos az adatcsereszerzodés karbantartásáért és ellenorzéséért, különös felelosséggel a használati útmutató módosításának vezetéséért és az üzenetek új verziójának felülírásáért 4.6 A fuvarozói megbízás ajánlása Az 1. fejezet bemutatta a módszereket, amelyek a folyamatok és a kapcsolódó információáramlás elemzését lehetové teszik. Ezt követi, ha szükséges a folyamatok, az információ átadással, feldolgozással stb. kapcsolatos feladatok újraértékelése, egyszerusítése, a felesleges elemek kiszurése. Ezt a racionalizálást az információk körére is el kell végezni. A továbbiakban a folyamatokhoz kapcsolódó

111


papírdokumentumok megvizsgálni.

elektronikus

okmányokkal

történo

helyettesítését

kell

Az 1.6 fejezet ismertette azokat a dokumentumokat, melyek kulcsfontosságú szerepet töltenek be a nemzetközi közúti árufuvarozás során. A továbbiakban a fuvarozói megbízás példáján keresztül végigkövetjük egy üzenetmaszk lehetséges felépítését. A bemutatásra kerülo subset egy ajánlás. A nemzetközi közúti árufuvarozás dokumentumaira elkészített ajánlások két részbol állnak: ? Az elso, rövidebb rész a dokumentumszintu ajánlást tartalmazza, amely lényegében a dokumentumok funkcióinak megfelelo EDIFACT-üzenetek összerendelését jelenti. A vizsgálandó okmányok kiválasztása a következo szempontok figyelembevételével történt: ? az információáramlási folyamatban a partnerek adataikat levélben vagy faxon juttatják el egymáshoz; ? az alkalmazott dokumentum a fuvarozás okmánya vagy szorosan kapcsolódik a fuvarozási információáramlási folyamathoz; ? a dokumentumot vagy az azon szereplo adatokat a partnerek gyakran, nagy mennyiségben cserélik; ? a dokumentum elektronikus okmánnyal történo kiváltása várhatóan jelentos elonyöket jelent a folyamatban résztvevoknek; (Mindezek alapján a fuvarozói megbízás alkalmas elektronikus úton történo továbbításra.) ? A második rész az adatcsoportszintu ajánlásokat tartalmazza. Ebben a részben a dokumentumok adatelemeit/rovatait és az EDIFACT szegmenseket és adatelemeket rendeltük egymáshoz. A „Fuvarozói megbízás” bizonylat adatszintu elemzése az 1. sz. mellékletben található. Az üzenetmaszk kialakítása a szabvány EDIFACT-tár alapján készült. Egy meghatározott alkalmazói környezetben használt subset részletesen definiálja az adatcsere során alkalmazott adatelemeket és kódokat is, melyektol itt eltekintünk. A fuvarozói megbízás üzenetmaszkjára vonatkozó ajánlás az EDIFACT üzenettár IFTMIN „Diszpozíció” nevu üzenete alapján készült. A papírdokumentum rovatai és a szabvány szegmensek egymáshoz rendelést a 2.1 melléklet tartalmazza. Ez az ajánlás a partnerek megegyezésén alapul, melynek lényege, hogy az üzenetmaszk milyen szegmenseit, szegmenscsoportjait tartalmazza a szabványüzenetnek. A továbbiakban leírt üzenetmaszk egy lehetséges kialakítás. A fuvarozói megbízásra vonatkozóan az üzenetmaszkot 4 fo részen keresztül mutatjuk be:

112


? Az elso részben a szegmensek és szegmenscsoportok grafikus ábrázolása látható (blokkdiagram - Branching diagram). A 2.2 sz. mellékletben jól áttekintheto az üzenet felépítése. ? A második rész a szegmenstáblát (Segment Table) tartalmazza. Ez az elozo, grafikus ábrázolásmódnál annyival nyújt többet, hogy itt a szegmenscímkéken kívül szerepelnek a szegmensek megnevezései is. (2.3 sz. melléklet) ? A harmadik rész a szegmensek összefoglalását tartalmazza (Segment Summary). Itt már a szegmensek és a szegmenscsoportok mellett rövid magyarázó szövegrészek is megtalálhatók. (2.4 sz. melléklet) ? A negyedik rész a szegmensek leírását tartalmazza. Ebben a részben a szegmensek által tartalmazott adatelemek és összetett adatelemek, valamint az azokhoz tartozó leírások is megtalálhatók. (2.5 sz. melléklet) Az adatelemeket tartalmazó táblázatrészek 6 oszlopból állnak. Az elso oszlop az adatelemek kódját, a második az adatelemek nevét tartalmazza. A harmadik oszlop az adatelemek típusát és hosszát adja meg.(Pl. AN..6: maximálisan 6 alfanumerikus karakterbol álló adatelem.) A negyedik oszlop azt határozza meg, hogy az adatelem kötelezoen (M - mandatory), vagy választásunktól függoen (C conditional) használandó. Az ötödik oszlop jelöli, hogy használni kívánjuk-e az adatelemet. Az üzenetmaszkban a teljesség kedvéért mindenütt a „használni kívánt” (R - required) jelzés szerepel. (Konkrét subset esetén természetesen nem szükséges minden adatelemet felhasználni.) A hatodik oszlop az adatelemmel kapcsolatos megjegyzéseket, magyarázó szövegrészeket tartalmaz. Az IFTMIN üzenet 37 szegmenscsoportból áll. A szegmenscsoportokban elhelyezhetok a „Fuvarozói megbízás” papírdokumentumon szereplo adatai. Az üzenet az elhelyezheto adatok alapján négy fo részre bontható. Bár az üzenet ilyen fajta részekre bontása önkényesnek mondható, segítséget nyújthat a subset-ek elkészítésekor. Az elso csoportot az 1.-9. szegmenscsoport alkotja. Az elso 9 szegmenscsoport közös jellemzoje, hogy az itt megadható adatok az üzenet egészére vonatkoznak. Ilyen adat például a dokumentum sorszáma, vagy a szállítás egészére vonatkozó állami, hatósági eloírások. A második csoportot a 10.-15. szegmenscsoport képezi úgy, hogy a 10. szegmenscsoport magába foglalja a 11.-15. szegmenscsoportokat is. Az üzenetnek ebben a részében a partnerekre vonatkozó adatok adhatók meg. A harmadik részt a 16.-33. szegmenscsoportok alkotják. Az elozohöz hasonló módon a 16. szegmenscsoport tartalmazza a 17.-33. szegmenscsoportokat. Ez az üzenetrész a fuvarozandó áru leírására használható.

113


A negyedik rész a 34.-37. szegmenscsoport alkotja. Itt a 34. szegmenscsoport tartalmazza a többi (35.-37.) szegmenscsoportot. Ebben a részben adható meg a szállítóeszköz(ök) leírása. Az elozoek figyelembevételével a „Fuvarozói megbízás” papírdokumentum adatai az üzenet (IFTMIN) szegmenseiben a 2.1 sz. mellékletben látható módon helyezhetok el.

114


5 Az EDI-projekt Az elektronikus adatcsere bevezetése több ok miatt válhat idoszeruvé egy cég esetében: 1. Partner(ek) kényszeríto ereje. A legáltalánosabb ok a nagyobb vevo vagy ritkábban a fuvarozó/szállítmányozó igénye. A partnerekre rákényszerítik az EDI alkalmazását annak érdekében, hogy ne veszítsenek piacot. Ez a legfontosabb gerjesztoje az EDI nagyméretu terjedésének. A partnerek megpróbálnak ellenállni a nyomásnak, de nagyon kevés vagy egyáltalán nincs választási lehetoségük, így elfogadják az EDI-t. 2. A szakma kollektív döntése. A második ok a szakmai szervezetek kezdeményezései. A szakmai szövetségek gyakran résztvevoi az EDI-nek, mivel a szabványosítási bizottságok tagjai. Így kezdeményezokké válnak, hiszen látják, hogy mi az egyik módja a költségek megtakarításának. A kezdeményezo nagyobb vállalatokra tudják terhelni a költségek jelentos részét, a kisebb cégek már a megalapozott EDI-be kapcsolódnak be, a nagyok által meghatározott iránymutatás szerint. 3. Problémamegoldás. Az EDI megoldása lehet néhány speciális problémának: a dokumentumokban megjeleno nagyszámú hiba, vagy a folyamatok alacsony ellenorzöttsége. Ha azonban az EDI-t csak a felszínen jelentkezo problémák megoldására használjuk, akkor a mélyben rejlo nehézségek kezelése elmarad. A muködési, stratégiai gondokat az EDI nem tudja önmagában megoldani, ehhez szervezési és egyéb feladatok végrehajtása is szükséges. 4. Stratégia. A legelorelátóbb, de valójában kevésbé általános ok, hogy az EDI, mint választási vagy döntési lehetoség jelenik meg a szervezet átfogó stratégiai felülvizsgálatakor. Az EDI-projektek két esetre bonthatók. Egyrészt az EDI megvalósítását kezdeményezo (proaktív) szervezetek indíthatják el azt a folyamatot, amely során egy használói csoport számára készül el az EDI-specifikáció. Másrészt az ún. alkalmazkodó (reaktív) szervezetek már meglévo - más szervezetek által alkalmazott - elektronikus adatcsere megoldásokhoz csatlakoznak. Részletesen az elobbivel foglalkozunk, amely összetettebb feladatsort jelent. A készülo EDI-megoldás minden részletére specifikációt kell kidolgozni: kezdve a jogi és auditálási (könyvvizsgálati) vonatkozásokkal, az adatcsere-szerzodésen és az adatspecifikációkon át egészen a kommunikációs protokollig stb. Ezek a specifikációk képezik majd az egyedi megvalósítások közös nevezojét.

115


A tervezés és a bevezetés szakaszait külön kell választani, mert a kétféle munkát különbözoképpen kell szervezni, mivel a legtöbb EDI partner nem vesz részt a tervezési munkában, de felhasználja az eredményül kapott specifikációt. A tervezési projektben ugyanakkor gondoskodni kell valamennyi résztvevo érdekeltségérol és hasznáról. Mindezek alapján az EDI projektnek a következok a fázisai: 1. Felkészülés a munkálatokra. 1.1 Elozetes áttekinto tanulmány. 1.2 Az EDI-bevezetés stratégiai céljainak meghatározása. 2. Elozetes tervezési feladatok. 2.1 2.2 2.3 2.4

Az „edisíteni” kívánt terület vagy funkciók kiválasztása. Az üzleti partnerek kiválasztása a leendo EDI kapcsolatokhoz. A kommunikációs lehetoségek és a szoftverválaszték elemzése. A szintaxis és üzenetszabványok kiválasztása.

3. A kiválasztott terület EDI-fejlesztése. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

A projekt-csapat felállítása, projekttervezés. Megállapodás a kiválasztott üzleti partnerrel. Az információáramlás elemzése. Adatelemzés és üzenettervezés. Az adatcsere üzleti tervezése. Technikai megvalósítás. Jogi és biztonsági követelmények vizsgálata. Üzemeltetési mód meghatározása.

4. Megvalósítás és az EDI használata. 4.1 4.2 4.3 4.4

A rendszerelemek kipróbálása. Próbaüzem. A rendszer felülvizsgálata. Az EDI használata.

1. Az elokészítés során elemezni kell a megcélzott terület problémáit, és alternatív cselekvési programot vagy megoldásokat kell felvázolni a helyzet javítására. Ebben a szakaszban még egészen általános szempontból kell a helyzetet vizsgálni, és nem kell feltétlenül abból kiindulni, hogy az EDI az egyedül kedvezo megoldás. Az elokészíto szakaszban különbözo kereskedelemkönnyíto intézkedések vagy más hagyományos megoldások (pl. oktatás és átszervezés) is szóba jöhetnek. Ebben a szakaszban például a következo általános jellegu tevékenységeket kell elvégezni:

116


? Az ügy- vagy üzletvitelt támogató és a szervezet adatigényeit kielégíto eszközök értékelése. ? Az olyan belso szervezeti egységek és külso partnerek körének feltárása, amelyekre a megoldás hatással lesz. ? Azoknak a területeknek vagy alkalmazásoknak a meghatározása, amelyek számára elonyösek a javasolt megoldások. ? A lehetséges megoldás költség-haszon elemzése. Az elokészíto elemzés a vezetés számára megalapozza a projektrol hozandó döntést. A lehetséges megoldásként vázolható az elektronikus adatcsere, melyhez a kapcsolódó célokat is meg kell fogalmazni. 2. A következo mérlegelési szempontoknak van hatása a kísérleti terület kiválasztására: ? Elozetesen ismert haszon, amely a sikeres megvalósítás után realizálódik. Ez nagy, mérheto és elfogadható kell legyen. ? Könnyed megvalósíthatóság és határozott valószínusége a sikernek. A terület kiválasztása meghatározza az üzleti partnerek körét is, akiket a projekt folyamatába valamilyen módon szükséges bevonni. A partnerek között fontossági sorrendet kell felállítani aszerint, hogy mely cég alkalmaz már EDI-t, milyen volumenu a papíralapú kapcsolat és mennyire jó az együttmuködési készség. A lehetoleg kis számú résztvevonek érdekeltnek kell lennie a projektben, jól gépesített, házon belüli rendszerrel kell rendelkeznie, és muszaki felkészültségük révén képesnek kell lennie a projektben való aktív részvételre. A partnerekkel kialakítandó kapcsolatokhoz meg kell vizsgálni a kommunikációs lehetoségeket, mely a hálózat (a hálózati szolgáltató), a kommunikációs protokoll megválasztását jelenti. A lehetséges EDI-szoftverek elemzését el kell végezni annak érdekében, hogy döntés születhessék: megvásárolható szoftvert célszeru beszerezni vagy saját fejlesztés történjék. A választ jelentosen meghatározza a házi alkalmazások fejlettségi szintje. Az EDI-szabványok közül a kísérleti területnek megfelelot kell kiválasztani (nemzetközi vagy elég a nemzeti; hosszabb távon állandó; a jövobeni EDI partnerek által támogatott). 3. A feladatok sora a végrehajtásért felelos személy a projekt vezetojének kiválasztásával kezdodik, akinek rendelkeznie kell mindazzal a szakértelemmel, ami szükséges ahhoz, hogy valamennyi felhasználói igényt le lehessen fedni.

117


A projekt vezetoje határozza meg a célt, illetve annak eléréséhez megszerzi a partnerek határozott felelosségvállalását, elosztja a forrásokat, vállalja a felelosséget a projekt lezárása után is. A konkrét alkalmazástól függ, hogy mely területekrol kell szakembereket bevonni, de mindenképpen törekedni kell arra, hogy minél több legyen képviselve: használók, szoftverfejlesztok, távközlési, biztonsági, jogi, auditálási szakemberek stb. Az üzemeltetok és a használók képviseletében résztvevo tagoknak vezeto szerepet kell vállalniuk, hiszen az új megoldás az o igényeiket hivatott kielégíteni. A használók tisztában vannak az információáramlással, a többi szervezeti egység és a külso partnerek információigényével is. Ok a rendszerek, rutinok és eljárások szakértoi, ok tudják felbecsülni a módosító javaslatok hatásait is. A partnerekkel történo megállapodásnak a következokre kell kiterjednie: ? az információk köre; ? az EDI-szabvány; ? az adatátviteli utak (pont-pont közötti vagy értéknövelt hálózat); ? a kísérleti EDI célja; ? a projekt menedzsment mechanizmusa (önálló vagy közös fejlesztés); ? a projektben résztvevo személyek kapcsolatai; ? a projekt tervezésének és megvalósításának idoterve. A sikeres tervezés, fejlesztés és megvalósítás jelentos mértékben függ a jelenlegi rendszer megismerésétol. Elsosorban az információáramlás elemzését kell elvégezni, amelyre vonatkozó módszert az 1. fejezet mutat be. Rögzíteni kell az információk áramlási útvonalát, a használt adatátviteli eszközöket (telefon, fax stb.), és magát a folyamatot. Ezek alapján a tervezett rendszerre vonatkozóan modellt kell készíteni. Az adatok elemzését követoen lehet a használók körére specifikált üzenetet tervezni. Ebben segítséget nyújtanak az EDI-szabványok dokumentációi. Az adatcserének számos hatása közül a legfontosabb az üzletmenetre vonatkozó, melyet részleteiben kell megvizsgálni (pl. ez jelenti az árképzés, árváltozás elemzését.). A technikai megvalósítás magában foglalja mindazon tevékenységeket, melyek az EDI hardver és szoftver kiválasztásához, telepítéséhez szükségesek: ? a rendszer specifikálása - kommunikáció; ? a hálózati összeköttetés módjának meghatározása; ? a kommunikációs protokoll kiválasztása;

118


? ? ? ? ?

a szükséges hardvereszközök megállapítása; szoftverspecifikáció és az alkalmazási interfész kidolgozása; a biztonsági követelmények meghatározása; a rendszerelemek beszerzése, használói jogosultságok megállapítása; a rendszer telepítése.

A jogi és biztonsági követelmények vizsgálatakor tisztázni kell a papírdokumetumok hiányából adódó kérdéseket. Ilyen kulcsfontosságú probléma az elektronikus aláírás megoldása, vagy az adathozzáférés tiltásának módszere illetéktelen felhasználók esetében. Az EDI bevezetése magával vonhatja az üzemeltetési folyamatok és a kapcsolódó adatáramlás változását. Így módosulhat az adatküldés, adatérkezés idobelisége (üteme), bizonyos folyamatok, feladatok elmaradhatnak, ugyanakkor meg kell határozni a teendoket azokra az esetekre vonatkozóan, amikor valamilyen ok miatt az EDI-üzenetek küldése, fogadása nem lehetséges (pl. hálózati hiba). Ha az EDI-rendszer nem automatikus üzemeltetésu, hanem emberi beavatkozást igényel, akkor új feladatként jelentkezik az operátor napi tevékenysége. Mindezen változások magával vonhatják az oktatás szükségességét (nem feltétlenül, hiszen elképzelheto, hogy ugyanazokat a feladatokat kell végrehajtani, ugyanazokat a házi alkalmazásokat ugyanúgy használják, mint eddig). Amennyiben új szoftver-, hardvereszközök és kommunikációs programok kerülnek be a szervezet munkájába, akkor azok használatára vonatkozó oktatás elkerülhetetlen. 4. Az „éles” üzemeltetés elott ellenorizni kell, hogy az EDI-rendszer valóban minden eleme az elvárásoknak megfeleloen muködik. Elsoként a rendszer kipróbálására vonatkozó tervet kell összeállítani, amely tartalmazza ? a próbaüzem idotervét (valamennyi partner egyetértésével); ? a billentyuzetek valamennyi karakterének ellenorzését; ? a programokban használatos valamennyi karakter ellenorzését; ? az adatküldési, -fogadási folyamat tesztjét (a kis és nagy adatmennyiségekre egyaránt vonatkoztatva); ? az érvénytelen adatok továbbításának tesztjét (a rendszer a nem megfelelo adatok esetén ad-e hibajelzést); ? a nem gyakori folyamatok, események tesztjét; ? a lehetséges hálózati hibák tesztjét (pl. a hálózati kapcsolat megszunése során a helyreállítási folyamatok üzemképessége megfelelo-e).

119


Ha minden elem az elvárásoknak megfeleloen muködik, akkor következhet a próbaüzem. Ilyenkor elképzelheto, hogy a folyamatok ellenorzése érdekében az EDI-rendszert és a papíralapú rendszert egyszerre üzemeltetik (az elektronikusan elküldött adatok valóban megérkeznek-e a címzetthez). Mindezek után megtörténhet a rendszer felülvizsgálata. A próbaüzem rávilágít azokra a területekre, amelyek módosítást igényelnek. Az EDI használata során megjelenhetnek új üzleti partnerek, akik az elektronikus adatcserében részt fognak venni, a már meglévo szakértelem számukra nagy segítséget nyújt, ugyanakkor új feladatokra, funkciókra vonatkozóan meg kell vizsgálni, hogy milyen mértékben és hogyan integrálhatók az EDI-rendszerbe. Elozetes áttekinto tanulmány A vállalati EDI-bevezetés stratégiai céljainak meghatározása Az „edisíteni” kívánt terület vagy funkció(k) kiválasztása A kommunikációs lehetoségek és a szoftverválaszték elemzése

Projekttervezés Az üzleti kapcsolatok elemzése Megállapodás a kiválasztott üzleti partnerrel Projekttervezés

Az értéknövelo hálózati szolgáltatók áttekintése és kiválasztása

A szintaxis és az üzenetszabványok kiválasztása a partnerrel közösen

Kereskedelmi és jogi vonatkozások

Adatelemzés és üzenettervezés

Rendszerspecifikáció: kommunikáció

Rendszerspecifikáció: szoftver Rendszerspecifikáció: üzemeltetés A rendszerelemek beszerzése A rendszer telepítése Integrálás a házi rendszerbe, próbaüzem és a kísérleti alkalmazás üzembeállítása A kísérleti alkalmazás kiterjesztése A rendszer felülvizsgálata

Rendszertámogatás

További fejlesztés

21. ábra Az EDI bevezetésének lépései

120


Ezzel a beruházás nagy része lezajlott, minden újabb EDI-kapcsolattal no a realizálható profit. A cél az, hogy ugyanazzal az üzenettípussal/üzenettípusokkal a leheto legtöbb vevot, szállítót, ügyfelet stb. tudják elérni. Attól a pillanattól kezdve, hogy az üzembehelyezés befejezodik, a feleknek maguknak kell ellenorizniük rendszereiket és a mindennapi ügymenetet. Ezért fontos, hogy a tervezés során a megfelelo hibakezelo és hibajavító muveletek kidolgozása megtörténjék (a reaktív szervezeteknek nagy segítséget nyújt), ami az EDI muködési színvonalának a fenntartását szolgálja. A feladatok egymásutániságát, a végrehajtandó lépéseket szemlélteti a 21. sz. ábra.

121


6 Néhány hazai EDI-alkalmazás 6.1 Adóbevallás elektronikusan Az APEH 1994-ben fogott az adóigazgatás korszerusítéséhez. Ennek kapcsán merült fel az elektronikus adatcsere alkalmazásának a lehetosége. 1997-ben indítottak be egy pilotprojektet, melynek során néhány kiszemelt adózó küldte be elektronikusan ÁFA-bevallását. Minden résztvevo számára alapveto a biztonságérzet megteremtése. Amennyiben ez nem történik meg, a partnerek nem fogják önként használni a rendszer nyújtotta szolgáltatásokat. Az adózónak biztosnak kell benne lennie, hogy: ? bevallása csakis az adóhivatalhoz érkezhet; ? biztosan az érkezik meg, amit elküldött; ? senki más nem férhet hozzá; ? ha mégis hozzáfér, nem tudja értelmezni; ? az adóhivatal utólag nem tudja megváltoztatni a bevallás tartalmát; ? az adóhivatal utólag nem tagadhatja le a bevallás megérkezését. Az adóhivatalnak biztosnak kell benne lennie, hogy: ? a bevallás valóban attól jön, akinek a küldoje kiadja magát; ? a bevallás küldoje nem tudja letagadni, amit beküldött. A pilot során a papírnyomtatvány beadására is igényt tartott a hivatal. (Amennyiben a muködo pilotrendszer tapasztalatai lehetové teszik, a végleges változatban csak az elektronikus dokumentumot kell majd beadni.) A kísérleti rendszer elemei: ? A 9765-ös nyomtatványt a jelentosége, mennyisége és a beadás gyakorisága miatt választották ki. ? A vonalkapcsolt telefonhálózati kommunikáció a kísérlet ideje alatt elfogadható, olcsó megoldást biztosít. ? Az X400-at a biztonságossága miatt választották. ? Az EDIFACT nemzetközi szinten karbantartott formátum, jelentéstartalma mindenki számára ugyanaz, ezáltal minimálisra csökkennek az értelmezési problémák. Például jelenleg a munkáltatók által beadott kontrolladatok feldolgozásánál egyetlen delimiterhiba értelmezhetetlenné teszi az adatokat. Jelenleg a vonalkapcsolt telefonhálózaton érkezo bevallásokat, tekintettel a pillanatnyi jogi környezetre, kinyomtatják és aláíratják az adózóval.

122


Amint elfogadottá válik az eljárás, a papír kiemelése után, tisztán elektronikusan is muködoképes marad a rendszer. A rendszer muködését mutatja be a 22. sz. ábra. Adózók Elektr. urlapok

Fordító profilok

APEH APEH feldolgozó (inhouse) rendszer

Naplózás archiválás

Fájl transzfer Urlapkezelo (kitölto)

urlap formátum

APEH MTA, EDI szerver

Telefon X400 X25

EDI konverter

EDIFACT Csatlakozó adatbázisok

Partner listák

X.400 RUA

Fordító profilok Naplózás archiválás

Partner listák

22. ábra

Az APEH EDI rendszere

? Lehetoség van a nyomtatványoknak klaviatúrán történo kitöltésére, illetve már meglévo adatoknak állományból történo beolvasására. ? Az EDI konverterben a különbözo fordító profilok segítségével megtörténik a formáknak EDIFACT üzenetté történo konvertálása. ? Az üzenetet egy X400-as runtime user agent juttatja el az APEH szerverére ? A különbözo archiválások után a fájl automatizált fájltranszfer segítségével kerül az APEH inhouse-rendszerébe. Itt az állomány szinte ugyanúgy jelenik meg, mint bármely más módszerrel rögzített bevallás. A megfelelo érdekeltségek megléte nélkül nem várható el a rendszer intenzív használata. Az érdekeltség foként a rendszer használatából adódó elonyökbol származik. 6.2 EDI a MASPED-TRIAS-nál A számítástechnika a MASPED csepeli gyujtoosztályán 1988 elején kezdodött. Egy mVAX II típusú számítógép, néhány VIDEOTON nyomtató, és tíz VT52 terminál segítségével, az IGFR (Import Gyujtoforgalmi Rendszer) került bevezetésre. Hamarosan kiderült, hogy a számítógép kapacitása az igényeknek nem megfelelo, ezután a technika folyamatos fejlesztésre került.

123


1991. május elsejére a következo eszközök álltak rendelkezésre: ? 1 db mVAX II; ? 2 db VAX 3 600; ? nyomtatók és terminálok nagy számban. Ekkor alakult meg a MASPED-TRIAS svéd-magyar vegyes vállalat a MASPED csepeli foosztályából. A késobbiekben a szoftverrendszer, és a géppark is jelentos fejlesztésen ment át. Jelenleg több, nagy teljesítményu AXP- és VAX-számítógéphálózat szolgálja ki a mintegy 120 terminálon, közel 60 nyomtatóval dolgozó osztályokat. Az import-export modul létrehozásának idején, 1978-ban az áru beérkezése és a kiszállítás között - ekkor még kézi adatfeldolgozás volt - mintegy 14 nap telt el. A cél az volt, hogy az átfutási idot 10 napra szorítsák le, ami a számítógépek bevezetésével sikerült is. A megbízók részérol azonban folyamatos nyomás nehezedett a kft-re, hogy az átfutási idot még jobban csökkentse. Elso lépésként bevezették azt, hogy a bejövo áruk esetében a szállítóeszköz indulásakor a külföldi indító által faxon küldött adatokat rögzítették még az érkezés elott. Miután az áru megérkezett, csak ellenorizni, és esetleg javítani kellett az adatokat. Ez a módszer azonban csak a távolabbi indítóállomások esetén muködött, mivel például Bécsbol a kocsi esetleg elobb érkezett meg, mint a fax. (Este indul a kamion, a fax pedig másnap reggel.) Közben bekövetkezett a rendszerváltás, ennek eredményeként nem néhány óriási külkereskedelmi vállalattal, hanem több ezer - gyakran kezdo - vállalkozással kerültek kapcsolatba. A dolgozók leterheltsége ezekben az idokben hirtelen jelentosen megnott. Keresték azt a megoldást, hogy milyen módon lehet csökkenteni az élomunka iránti igényt. A szállítmányozásban nagyon nagy mennyiségu és pontos adattal kell dolgozni. (Jellemzo, ha a megbízó az okmányon hibásan ír le egy nevet, akkor azt a szállítmányozónak ugyanúgy kell az általa kiállított okmányra leírni.) A külföldi partnerek már elobb vagy a céggel egyidoben számítógépesítették az adatfeldolgozásukat. (Tehát ok is rögzítették az adatokat, kinyomtatták, elküldték, a MASPED-TRIAS is rögzítette, továbbküldte stb.) Kézenfekvonek tunt, ha elektronikusan cserélik az adatokat, nem kell azokat rögzíteni, kevesebb lesz a hiba, és ráadásul hamarabb tudják a megbízóikat kiszolgálni áruval, valamint információval. Elkezdték keresni a megoldást ennek érdekében. Alapvetoen két feladatot kellett megoldani:

124


? Két rendszer - ami nyilván más adatstruktúra, más beszélt nyelv - között bizonylatok adatait kell kicserélni. ? Két bármilyen operációs rendszer között adatcserét kell lebonyolítani, hivatalosan naplózva. Már az adatcsere megoldása sem egyszeru, hiszen a különbözo partnereknek más és más típusú számítógépe van. Az elso jelentos probléma az, hogyan lehet különbözo típusú számítógépeket hálózatba összekapcsolni? Bérelt vonal - az ár miatt - nem használható. A telefon jó megoldás. A vonal lehet hagyományos, vagy ISDN. A kapcsolat lehet közvetlen, vagy szolgáltatón keresztüli. A közvetlen kapcsolat esetén az adatcsere olcsóbb, hiszen nincs közben szolgáltató, hátránya, hogy esetleg minden partnerhez más típusú kapcsolat szükséges. Ez meglehetosen drága és az üzemeltetés is nehézkes. A szolgáltatón keresztül történo kapcsolódás drágább, de csak egyféle módon kell a kapcsolatot kiépíteni, ezért sok különbözo partner esetén ez a gazdaságosabb. Európában ez tényleg így is van, de nem Magyarországon. Jelenleg sem találtak olyan szolgáltatót, aki egyszeruen, X.25 felett OFTP protokollal egy postaládát tudna számukra biztosítani. Az X.25-höz azért ragaszkodnak, mert többéves tapasztalataik alapján a megbízhatósága a többszöröse a kapcsolt telefonvonalnak, és kapcsolási sebessége is sokkal gyorsabb. Az OFTP protokollt pedig azért választották, mert a jármugyártásban, és a szállítmányozásban is elterjedt, külföldi partnereik is ezt használják. Az adatcsere elvileg tehát megoldható, ha van szolgáltató, vagy a partnereknek van olyan protokollja, mint nekik. Ha tudnak egyszeru adatokat cserélni, már csak azt kell megoldani, hogy a cserélt információt mindkét oldal megfeleloen értelmezni tudja. Az adatállományok felépítését kétféleképpen lehet megoldani: vagy partnerenként megegyeznek valamiféle adatformátumban, vagy keresnek egy szabványt. Nyilvánvaló, hogy ha külön-külön adatállományt hoznak létre, az a rendszert nagyon elbonyolítja. Ezzel szemben a szabványos üzenetet csak egyszer kell kiépíteni. Persze ez csak akkor járható út, ha a partnereknek is megfelel. Az EDIFACT szabványt választották. A választás azért esett rá, mivel egyrészt ezt ismerték, másrészt információik szerint ez lesz az európai vállalatok általános "szabványa". Az egész folyamat 1992 végén kezdodött.

125


Egy nagy külföldi szállítmányozó vállalattal kezdték kiépíteni a kapcsolatot. Ezt 1994 végére befejezték, ekkor azonban a köztük levo mindenféle gazdasági kapcsolat megszakadt. Azóta a MASPED-TRIAS legnagyobb partnere a SCANSPED lett, második alkalommal velük kezdték el kiépíteni az elektronikus kapcsolatot. Az EDIFACT-formátum elég bonyolult, sokféle bizonylatra ad szabványt. Nem érdemes saját konvertáló programot készíteni, a piacon ugyanis sokféle rendszer kapható. Az üzenetszabványok általában több adatot tartalmaznak, mint amennyit valójában használnak. A használandó adatokat egyeztetni kell a partnerrel, majd a konverziós programnak ezt meg kell adni. A konverziós program telepítéséhez külso szakértot kértek fel. A SZÁMALK-SOFTEC kft. volt akkoriban az egyik cég, akik erre a feladatra vállalkoztak. Azok a külföldi szállítmányozó vállalatok, amelyek belso hálózatukban már régóta használnak üzeneteket - éppen azért, mert régebben fejlesztették -, nem minden tekintetben felelnek meg a szabványnak. A konverziós programnak olyannak kell tehát lennie, hogy a nem teljesen szabványos üzenetet is fel tudja dolgozni. Például egy olyan üzenetet, amely szabványos EDIFACT-formátumú, de nem szabványos üzenet. A SCANSPED-del való kapcsolattartásukban az elektronikus adatcsere úgy muködik, hogy a belso üzenet a VMS operációs rendszer alatt futó EXPORTIMPORT modulban készül el. A rendszerben van egy PC, amely virtuális lemezként használja az egyik AXP gép tartalomjegyzékét. Ezen a lemezen külön-külön tartalomjegyzék van a kimeno, illetve a bejövo üzeneteknek. A PC-n fut egy program, amely beállítható idointervallumban megvizsgálja a lemezt, és ha talál adatállományt, konvertálja, majd elküldi azokat. Ezután letölti azokat az üzeneteket, amelyeket nekik küldenek, a kapott üzenetet konvertálja, majd a megfelelo tartalomjegyzékre teszi. Minden lépést feljegyez a késobbi visszakeresés miatt. Az üzeneteket egy központi helyre küldik, és onnan továbbítják a különbözo országok telephelyeire. A rendszer úgy muködik, mintha egy szolgáltató postaládáján keresztül cserélnék az üzeneteket.

126

MELLÉKLETEK

1. melléklet A fuvarozói megbízás adatszintu elemzése 2. melléklet A fuvarozói megbízás EDI-üzenet ajánlása 2.1 melléklet A paírdokumentum rovatai és a szabvány szegmensek egymáshoz rendelése 2.2 melléklet A szegmensek, szegmenscsoportok grafikus ábrázolása (Branching diagram) 2.3 melléklet Az üzenetmaszk szegmenstáblája 2.4 melléklet Az üzenetmasz szegmenseinek összefoglalása 2.5 melléklet Az üzenetmaszk szegmenseinek leírása

1. melléklet A fuvarozói megbízás adatszintu elemzése Dokumen- Rovattum neve szám Fuvarozói Megbízás

Rovatnév POZÍCIÓSZÁM

Adat Pozíciószám vagy sorszám

TEHERGÉPKOCSI A tehergépkocsi típusa TÍPUS KIÁLLÁS HELYE

- A kiállás helyének megnevezése - A kiállás helyének címe

KIÁLLÁS IDEJE

A kiállás dátuma és idopontja

FUVARDÍJ FIZETO

- A fuvardíj fizetojének neve - A fuvardíj fizetojének címe

KIVITELI VÁMKEZELÉS

- Vámudvar címe - Ügyintézo neve

BEVITELI VÁMKEZELÉS

- Vámudvar címe - Ügyintézo neve

CÍMZETT

- A cég neve - A cég címe, telefonszáma

LERAKÁS HELYE - A lerakás helyének címe - Ügyintézo neve

LERAKÁS IDEJE

A lerakás dátuma és idointervalluma

KISÉRO A kíséro dokumentumok összessége. OKMÁNYOK ÁRU - Az áru megnevezése MEGNEVEZÉSE, - Az áru mennyisége MENNYISÉGE - Egyéb

Tartalom Nyilvántartási szám a szállítmányozónál

Hossz max. 10 kar.

Az áru elszállításához szükséges tehergépkocsi kb. 60 kar. típusa, vagy a szükséges paraméterek megadása (hosszúság, magasság stb.). Az üres jármu a kiállás helyén veszi fel a - kb.max. szállítandó árut. kar. - kb.max. kar. Az üres jármunek a kiállás idopontjában kell az max. 20 kar. elszállítandó áruért jelentkezni (dátum és idopont) A fuvardíj kifizetojének (általában a - kb.max. szállítmányozó) neve és címe kar. - kb.max. kar. Legkésobb a magyar határig vámzár alá kell - kb.max. heyez-ni az árut. Ennek helyét és az ügyintézo kar. személyét kell rögzíteni. - kb.max. kar. A célországban a kirakás elott a vámkezelés helye - kb.max. és az ügyintézo neve. kar. - kb.max. kar. A címzetté az áru, így o határozza meg a lerakás - kb.max. helyét, a neve, címe és esetleg a telefonszáma kell kar. - kb.max. hozzá. kar. A lerakás helyének címe, ami általában raktár és - kb.max. az ügyintézo neve. kar. - kb.max. kar. A lerkás dátuma és az idointervallum, amelyik max. 20 kar. alatt az árut fogadni képesek. Az áru szállításakor a fuvarozó által magával vitt max. 80 kar. okmányok felsorolása. Az áru megnevezése és mennyisége, valamint az - kb. 40 kar. á-ru raktérben történo elhelyezésére, szállítási - kb. 20 kar. érzé-kenységére utaló megjegyzések. - kb 40 kar.

Kitölto szerv

Megjegyzés

Szállítmányozó Szállítmá- Ha ismeri a szállítmányozó a fuvarozó jármuveit, akkor elegendo a forgalmi nyozó rendszám. 50 Szállítmányozó 50 Szállítmányozó 50 Szállítmányozó 50 50 Szállítmá- A vámügyintézo nevét is megszokták nyozó adni, akit a sofornek keresni kell. 30 50 Szállítmá- A vámügyintézo nevét is megszokták nyozó adni, akit a sofornek keresni kell. 30 50 Szállítmányozó 50 50 Szállítmányozó 30 Szállítmányozó Szállítmá- 4-5 db okmány is lehet. nyozó Szállítmá- Több áru is lehet, így ennek nyozó megfelelöen ismétlodhetnek az adatok.

Dokumen- Rovattum neve szám

Rovatnév

Adat

EGYÉB MEGJEGYZÉS

Egyéb megjegyzés

FUVARDÍJ

-

Fuvardíj összege Fuvardíj pénzneme Átvételi homérséklet Szállítási homérséklet Leadási homérséklet

-

Fizetés módja Árfolyamszámítás Kitételek a kapcsolatosan Fuvarozási feladat követelményei

ÁTVÉTELI, SZÁLLÍTÁSI, LEADÁSI HOMÉRSÉKLET KIEGÉSZÍTO MEGJEGYZÉS

1. melléklet folytatása

Tartalom Bármilyen egyéb megjegyzés

Hossz

Kitölto szerv

kb. 300 kar.

Megjegyzés

Szállítmá- Ide kerülhet a kereskedelmi titkok nyozó védelmére vonatkozó és egyéb extra utasítás. Pl.: A címzett nem tudhatja meg, hogy hol volt a berakodás. A szállítmányozó a megadott kódú pénznemben kb. max. 12 kar. Szállítmáennyit fizet a fivarozónak. nyozó A három homérséklet értékét kell beírni - 4 kar. Szállítmá- 99 fok fölött nem szállítanak, tehát a - 5 kar. nyozó számjegynek elég 2 karakter - 5 kar. A fizetés módjára, az árfolyamszámításra és a kb. max. 1000 Szállítmáfuvarozással kapcsolatos mindennemu kar. nyozó fuvarozással megjegyzés itt felsorolható. teljesítésének

2.1. melléklet

A papírdokumentum adatai az IFTMIN üzenet szegmenseivel

Papírdokumentum adatai (Megbízás/megrendelés) Pozíciószám A dokumentum kelte Általános megjegyzések (Egyéb megjegyzés) Fuvarparitás (Kiegészíto megjegyzés) Fuvarparitás helye (Kiegészíto megjegyzés) Fizetés módja (Kiegészíto megjegyzés) Fuvardíj összege

Fuvardíj pénzneme, árfolyama Gépkocsi/vasúti kocsi kiállításának helye Gépkocsi/vasúti kocsi kiállításának idopontja Gépkocsi/vasúti kocsi típusa Gépkocsi rendszáma/vasúti kocsi azonosító Kiviteli vámkezelést végzo vámudvar címe Kiviteli vámkezelés ügyintézojének a neve Beviteli vámkezelést végzo vámudvar címe Beviteli vámkezelés ügyintézojének a neve Címzett neve és címe Címzett telefonszáma Fuvarozó neve és címe Fuvarozó telefonszáma, faxszáma Fuvardíjfizeto/szállítmányozó neve és címe Fuvardíjfizeto/szállítmányozó ügyintézo neve Fuvardíjfizeto/szállítmányozó ügyintézo telefonszáma Áru lerakásának helye Áru lerakásának idopontja Árutétel azonosítása Átvételi, szállítási és leadási homérséklet

IFTMIN szegmensek Szegmens Szegmensnév csoport Üzenet fejrész, zárórész -

Dátum/idopont/idoszak Szabad szöveg

Szegmens címke UNH, UNT DTM FTX

2 2

Szállítási feltétel Helymeghatározás

TOD LOC

6 7

7 8 8

Fizetési eloírások Fuvardíjszámítási adatok, Pénzösszeg, Áradatok Pénznemek Helymeghatározás Dátum/idopont/idoszak

CPI TCC, MOA, PRI CUX LOC DTM

8 8

Fuvaradatok Fuvaradatok

TDT TDT

11

Név és cím

NAD

12

Kapcsolattartó

CTA

11

Név és cím

NAD

12

Kapcsolattartó

CTA

11 12 11 12 11

Név és cím Távközlési eszköz Név és cím Távközlési eszköz Név és cím

NAD COM NAD COM NAD

12

Kapcsolattartó

CTA

12

Távközlési eszköz

COM

19 19 18 18

Név és cím Dátum/idopont/idoszak Árutétel adatok Homérséklet, kezelési

NAD DTM

GID TMP,

Papírdokumentum adatai (Megbízás/megrendelés)

Szegmens csoport

Áru megnevezése, kódja

18

Áru mennyisége Kíséro okmányok

20 24

IFTMIN szegmensek Szegmensnév

Szegmens címke utasítások HAN Áruleírás, szabad szöveg GDS, FTX Mértékek MEA Okmány/üzenetadatok DOC

3

2

1

0

BGM

M 1

UNH

M 1

FTX C 99

DTM

C 9

PRI C 1

C 1

C 9

M 1

CUX

M 1

TCC

LOC

M 1

CPI

C 99

C 9

C 2 TOD

Grp 7

Grp 6

Grp 2

C 9

MOA

COM C 9

C 9

M 1

CTA

DTM

M 1

LOC

C 9

Grp 12

Grp 9 C 99

M 1

NAD

M 99

C 99

HAN

M 1

GID

C 999

Grp 11 Grp 18

M 1

TDT

C 99

Grp 8

C 1

TMP

C 99

FTX

C 1

DTM

M 1

NAD

C 9

Grp 19

MEA M 1

GDS C 9

C 99

M 1

DOC

C 9

Grp 20 Grp 24

M 1

UNT

2.2 melléklet Az üzenet blokkdiagramja (Branching diagram)

M 9999

Message UNH BGM DTM FTX

Üzenet fejrész Üzenet kezdete Dátum/idopont/idoszak Szabad szöveg

M M C C

1 1 9 99

Group 2 TOD LOC

CPI

C 2

Fuvarparitás Helymeghatározás Group 6 Fizetési eloírások

Group 7 TCC Fuvardíj számítási adatok CUX Pénznemek PRI Ár-adatok MOA Pénzösszeg

TDT

Group 8 Fuvaradatok

1 9

M

1

C 2

C 99 M C C C

1 1 1 9

M

1

C 99

Group 9 LOC Helymeghatározás DTM Dátum/idopont/idoszak

NAD

M C

Group 11 Név és cím

C 99 M C

1 9

M

1

M C

1 9

M 99

Group 12 CTA Kapcsolattartó COM Távközlési eszköz

C 9

Group 18 GID HAN TMP FTX

NAD DTM

C 999

Árutétel-adatok Kezelési utasítások Homérséklet Szabad szöveg Group 19 Név és cím Dátum/idopont/idoszak

M C C C

1 99 1 99

M C

1 1

C 9

GDS

Áruleírás

C

9

MEA

Group 20 Mértékek

M

1

C 99

Group 24 DOC Okmány/üzenetadatok

M

1

UNT

M

1

Üzenet zárórész

C 9

2.3 melléklet Szegmenstábla

2.4. melléklet

Szegmensek összefoglalása

Üzenet kezdete UNH – M –1 – Üzenet fejrész Ez a szolgálati szegmens jelöli az üzenet kezdetét és egyértelmuen azonosítja az üzenetet. Megjegyzés: A szegmens S009-es összetett adateleme a következo összetevo adatelemeket kell tartalmaznia: 0065 – IFTMIN; 0052 – D; 0054 – 01B; 0051 – UN. BGM – M – 1 – Üzenet kezdete Ez a szegmens az üzenet kezdetét jelzi és tartalmazza az üzenet típusát és azonosítószámát. DTM – C – 9 – Dátum/idopont/idoszak Ez a szegmens az egész üzenetre vonatkozó dátumot és idopontot ad meg. Pl. az üzenet kibocsátásának dátuma. FTX – C – 99 – Szabad szöveg Ez a szegmens szabad szöveges formában adja meg a továbbítandó kiegészíto információt. Ilyen pl. a szállítás pillanatnyi helyzete, a szállítási dokumentumon szereplo megjegyzések, a rakományra vonatkozó megjegyzések, biztosítással kapcsolatos utasítások, vagy más egyéb kiegészíto információk.

Group 2 – C - 2 Ez a szegmens meghatározza a fuvarparitást és a kapcsolódó helyet. TOD – M – 1 – Fuvarparitás Ez a szegmens megadja az alkalmazandó fuvarparitást. LOC – C – 9 – Helymeghatározás Ez a szegmens megadja a fuvarparitáshoz kapcsolódó helyet.

Group 2 vége Group – 6 – C – 2 Ebben a szgmenscsoportban megadható az egész üzenetre vonatkozóan a fizetés módja. CPI – M – 1 – Fizetési eloírások Ez a szegmens megadja a díjfizetés módját.

Group 6 vége Group – 7 – C – 99 Ebben a szegmenscsoportban adható meg a tarifa és a fuvardíj. TCC – M – 1 – Fuvardíjszámítási adatok Ebben a szegmensben adható meg a fuvardíjszámítás módja, a tarifaosztály. CUX – C – 1 – Pénznemek Ez a szegmens megadja a fuvardíj/tarifa pénznemét. PRI – C – 1 – Ár-adatok Ez a szegmens díjat vagy díjtételt (pl. 1000 kg-ra vetítve) ad meg. MOA – C – 9 – Pénzösszeg Ez a szegmens megadja a fuvardíj összegét. (A szegmens ugyancsak alkalmas eloleg, a kedvezmény összegének és a teljes összeg megadására.)

Group 7 vége Group – 8 – C – 99 Ez a szegmenscsoport az áru mozgásával kapcsolatos leírásokat tartalmaz (áruszállítási mód, fuvareszköz, helymeghatározások, indulás és érkezés idopontja stb.) TDT – M – 1 Fuvaradatok Ez a szegmens megadja a fuvarozás adott szakaszára vonatkozó adatokat, például az áruszállítási módot, a fuvareszközt, a fuvareszköz típusát és a fuvarozót.

Group – 9 – C – 99 Ez a szegmenscsoport az áruszállítás adott szakaszára vonatkozó helyet, dátumot és idot ad meg. LOC – M – 1 – Helymeghatározás Ez a szegmens az áruszállítás adott szakaszára vonatkozó helyet ad meg. (Indulási, érkezési hely stb.) DTM- C – 9 – Dátum/idopont/idoszak Ez a szegmens megadja a LOC szegmenshez kapcsolódó dátumot és idopontot. (Pl. a közlekedési eszköz meghatározott helyre érkezésének dátuma és idopontja.

Group 9 vége Group 8 vége Group – 11 – M – 99 Ez a szegmenscsoport adja meg a résztvevokkel (felekkel) kapcsolatos adatokat, hivatkozásokat, helymeghatározásokat, szükséges dokumentumok azonosítását és a díjfizetéssel kapcsolatos adatokat. NAD – M – 1 – Név és cím Ez a szegmens a résztvevo nevét, címét és szerepkörét adja meg.

Group – 12 – C – 9 Ez a szegmenscsoport adja meg a felek kapcsolattartóinak nevét és a távközlési esköz(ök) azonosítóját. CTA – M –1 – Kapcsolattartó Ez a szegmens megadja a résztvevonél a kapcsolattartó részleg vagy személy nevét. COM – C – 9 Távközlési eszköz Ez a szegmens adja meg a kapcsolattartó személy vagy részleg kommunikációs azonosítóját (telefonszám, telefaxszám, e-mail cím).

Group 12 vége Group 11 vége Group – 18 – C – 999 Ez a szegmenscsoport tartalmazza a szállítási feladathoz kapcsolódóan az árutételek leírását.

GID – M – 1 – Árutétel-adatok Ez a szegmens egy szállított árutételt azonosít. Az árutétel a csomagolás három szintjéig azonosítható. HAN – C – 99 – Kezelési utasítások Ez a szegmens az árutételre vonatkozó kezelési utasításokat adja meg. TMP – C – 1 – Homérséklet Ez a szegmens az árutételhez kapcsolódó homérséklet beállításokat adja meg. FTX – C – 99 – Szabad szöveg Ez a szegmens az adattételre vonatkozó kiegészíto információkat határozza meg.

Group – 19 – C – 999 Ez a szegmenscsoport adja meg az árutétel átvételének és kiszolgáltatásának helyét és idopontját. NAD – M – 1 – Név és cím Ez a szegmens az árutétel begyujtési vagy kiszállítási helyének címét adja meg. DTM – C – 1 – Dátum/idopont/idoszak Ez a szegmens a begyujtési és kiszállítási helyhez kötodo dátumot és idopontot adja meg.

Group 19 vége GDS – M – 1 – Áruleírás Ez a szegmens a rakomány jellegét írja le.

Group – 20 – C – 99 Ez a szegmenscsoport az árutétel-mértékek megadására szolgál. MEA – M – 1 Mértékek Ez a szegmens az árutételre vonatkozó (nem kiterjedés jellegu) mértékegységet ad meg.

Group 20 vége Group – 24 – C – 9 Ez a szegmens az árutételre vonatkozó okmányokat és a kapcsolódó dátumot és idopontokat tartalmazza. DOC – M – 1 – Okmány/üzenetadatok Ez a szegmens az árutétellel kapcsolatosan kiállított okmányt azonosít.

Group 24 vége Group 18 vége UNT – M – 1 – Üzenetzárórész Ez a szolgálati szegmens jelzi az üzenet végét, tartalmazza a szegmensek teljes számát éa az üzenetet ellenorzo hivatkozási számot.

Üzenet vége

2.5 melléklet Szegmensek leírása (részlet)

IRODALOMJEGYZÉK 1. European Free Trade Association: Guide to the implementation of EDIEDIFACT, 1994 és ennek magyar fordítása: KTI Rt.: EDI és EDIFACT-kézikönyv, 1995. 2. HUNPRO: Bevezetés a kereskedelemkönnyítésbe és az ENSZ-EDIFACTba, 1994. 3. HUNPRO: Az adatátvitel lehetoségei (Hazai áttekintés az elektronikus adatcsere szempontjából),1995. 4. Mike Hendry: Implementing EDI,1993. 5. The National Computing Centre LTD: The EDI Implementors’ Handbook, 1992. 6. Hírközlési Fofelügyelet (szakértoi csoport): Adathálózatok együttmuködésének muszaki, tarifális és szabályozási megalapozása, 1996. 7. Gehl Gábor - Simon Csaba - Dr. Tóth János: Áruszállítási kézikönyv (Információáramlási modell a közúti áruszállításban - Ajánlások), 1996. 8. MSZ ISO 9735; Igazgatási, kereskedelmi és szállítási adatok elektronikus cseréjének (EDIFACT) alkalmazási szintu szintaktikai szbályai, 1992. 9. Dr. Westsik György: Közlekedési rendszertervezés, 1982 10. Miniszterelnöki Hivatal Informatikai Koordinációs Iroda: Elektronikus adatcsere és biztonsági jellemzoi, 1994. 11. KTI Kutatásszervezési és Fejlesztési Iroda: A közlekedési elektronikus adatcsere vállalati hatásai, 1992. 12. EDI’96 és EDI’97 konferencia eloadásai.

TARTALOMJEGYZÉK 1

Az árufuvarozás információs folyamatai..............................2 1.1 Az elektronikus adatcserét megalapozó vizsgálati módszer az árufuvarozásban.................................................................2 1.1.1 Az árufuvarozás folyamatának elemzési módszere.......2 1.1.1.1 A dinamikus struktúra rögzítésének technikája......3 1.1.1.2 Az információs rendszer elemzése .........................7 1.2 Az árufuvarozás mint a kereskedelmi folyamat része ..........7 1.3 Az árufuvarozás szereploi és kapcsolataik ...........................8 1.4 Az árufuvarozáshoz kapcsolódó tevékenységei....................9 1.5 Az árufuvarozás folyamata .................................................10 1.6 Kulcsszerepet betölto okmányok és funkcióik....................12

2

Az elektronikus üzleti kommunikáció és az EDI ...............15 2.1 Az elektronikus kommunikáció kialakulása .......................19 2.2 Kommunikációs lehetoségek és kommunikációs protokollok..........................................................................24 2.2.1 Hálózati szolgáltatások................................................24 2.2.2 Távközlési szolgáltatások............................................30 2.3 Kommunikációs protokollok ..............................................32 2.3.1 Értéknövelo szolgáltatások (VANS Value Added Network Service) ..................................41 2.3.2 Az EDI és a hálózat.....................................................42 2.4 Az EDI-szoftver ..................................................................46 2.4.1 A kommunikációs interfész.........................................46 2.4.2 Konverter.....................................................................47 2.4.3 Alkalmazási interfész ..................................................49 2.4.4 Üzemeltetés .................................................................50 2.4.5 További funkciók ........................................................50 2.4.6 Szoftverkategóriák ......................................................51 2.5 Biztonság és adatvédelem az elektronikus kommunikációban...............................................................52

3

Az EDI szerepe a fuvarozásban ...........................................54 3.1 Az EDI alkalmazásával járó elonyök, hátrányok és változások ........................................................................55 3.1.1 Elonyök .......................................................................55 3.1.2 Hátrányok ....................................................................58 3.1.3 Egyéb változások.........................................................60 3.2 Az EDI és a menedzsment ..................................................60 3.3 Az EDI magyarországi környezete és szereploi..................66

4

Az ENSZ-EDIFACT .............................................................70 4.1 EDI-szabványok..................................................................70 4.2 Az ENSZ-EDIFACT...........................................................71 4.2.1 Az ENSZ-EDIFACT-szintaktika ................................73 4.2.2 Adatelemek .................................................................74 4.2.3 Kódlisták .....................................................................78 4.2.4 Összetett adatelemek...................................................78 4.2.5 Szegmensek.................................................................80 4.2.6 A minosítok.................................................................83 4.2.7 Üzenetek......................................................................83 4.2.8 Az üzenet felépítése, szolgálati szegmensek...............89 4.3 Üzenetkidolgozás, a szabvány karbantartása......................94 4.4 A fuvarozói megbízás ajánlása .........................................111

5

Az EDI-projekt....................................................................115

6

Néhány hazai EDI-alkalmazás...........................................122 6.1 Adóbevallás elektronikusan..............................................122 6.2 EDI a MASPED-TRIAS-nál.............................................123


Készítette: Dr. Tóth János Egyetemi adjunktus

Budapest, 2002 március

Bevezetés. Remélhetoleg ez a tankönyv sok érdeklodo számára nyújt segítséget az EDI alapjainak elsajátításában. Budapest, 1997

Recommend Documents