← Articles · EDI Basics

How EDI works

Az EDI működését összefoglaló cikksorozat első része

Hogyan működik az EDI a valóságban? – 1. rész

Az EDI egy automatizált e-mail rendszerhez hasonlítható

Amikor egy cégvezető vagy logisztikai menedzser először hall az EDI (Electronic Data Interchange) fogalmáról, gyakran egy misztikus, méregdrága és nehezen definiálható fogalom jelenik meg lelki szemei előtt. Pedig a valóság sokkal közelebb áll a mindennapjainkhoz, mint hinnénk.

Nagyon leegyszerűsítve az EDI egy automatizált üzleti e-mail rendszer.

Természetesen ez egy tudatosan leegyszerűsített analógia, amit most a közérthetőség kedvéért használunk. Az alapelv azonban hasonló:

  • az üzenetet a cég ügyviteli rendszere megkreálja, vagy akár az egyik dolgozó Excel-ben készíti azt el,
  • ez az üzenet eljut a fogadó félhez,
  • a fogadó feldolgozza azt,
  • majd visszajelzés érkezik a sikeres kézbesítésről.

 


1. lépés: Megszületik az üzenet

A digitális levélírás

Ahogy egy e-mailt is meg kell írnia valakinek, az EDI folyamat is egy kiinduló adattal kezdődik.

Ezt az adatot létrehozhatja például:

  • ERP rendszere,
  • raktárkezelő rendszere,
  • logisztikai modulja,
  • webshopja,
  • vagy gyártási rendszere
  • adminisztratív kolléga

Az üzeneteknek sok típusa van, a leggyakoribbak:

Üzenettípus

Jelentése

ORDERS

Megrendelés

ORDRSP

Rendelés visszaigazolás

DESADV

Szállítási értesítő

INVOIC

Számla

RECADV

Áruátvételi visszaigazolás

PRICAT

Árlista

CONTRL

Technikai visszaigazolás

A háttérben ezek valójában teljesen hétköznapi üzleti események:

  • „rendeljünk árut”,
  • „elküldtük a számlát”,
  • „holnap érkezik a kamion”,
  • „megérkezett az áru”.

Nem csak EDIFACT létezik!

Gyakori tévhit, hogy az EDI egyenlő az EDIFACT-tal.

Valójában az EDIFACT csak egy szabvány a sok közül.

A kiinduló dokumentum rengeteg formátumban létezhet:

Egyszerűbb formátumok

  • CSV
  • Excel
  • TXT

Modern strukturált formátumok

  • XML
  • JSON

Vállalati szabványok

  • SAP IDoc
  • ANSI X12
  • UBL
  • cXML

Az egyik legismertebb nemzetközi szabvány a UN/EDIFACT, amelyet főleg Európában használnak.

Elképzelhető, hogy egy kisebb cég olcsóbb ERP-je például akár csak egy ilyen egyszerű fájlt tud generálni:

Cikkszam;Mennyiseg;Ar
ABC123;10;2500
XYZ555;5;4200

Ez még nem szabványos EDI üzenet, de kiindulási alapnak tökéletes.

A következő lépésben egy EDI rendszer vagy mapping motor ezt alakítja át a partner által elvárt formátumba.


Miért az ERP a projekt lelke?

Sok EDI projekt nem technikai problémán, hanem rossz előkészítésen bukik el.

A leggyakoribb probléma:

az ERP rendszer nem tudja a partner által várt adatokat szolgáltatni.

  • nem tud automatikusan exportálni,
  • nem kezeli a partner-azonosítókat,
  • nem támogatja az interfészeket,
  • nincs hozzá tapasztalt fejlesztő,
  • az üzenet tárgyát képező tranzakciók adatai hiányosak (dátumok, időpontok, szállítólevélszám, palettaszám stb. hiányzik)

akkor az EDI projekt lassú és drága lesz.

A nagy rendszerek, mint például:

  • SAP,
  • Microsoft Dynamics,
  • Oracle,
  • abas,
  • proALPHA

általában már rendelkeznek EDI kapcsolódási lehetőségekkel.


2. lépés: A „Posta” kiválasztása

Irány a szolgáltató!

Miután az ERP elkészítette az üzenetet, azt el kell juttatni a partnerhez.

Ehhez általában szükség van:

  • EDI szolgáltatóra,
  • integrációs partnerre,
  • vagy saját EDI infrastruktúrára.

Ők biztosítják a „digitális autópályát” az adatküldéshez.


Hogyan jut el az üzenet a partnerhez?

Kommunikációs protokollok

Az EDI-ben a kommunikációs protokoll olyan, mint az e-mail világában az SMTP.

Ez határozza meg:

  • hogyan küldjük az adatot,
  • mennyire biztonságos a kapcsolat,
  • hogyan történik a hitelesítés,
  • és milyen visszajelzések érkeznek.

AS2

Az internetes EDI „királykategóriája”

Az AS2 az egyik legismertebb és legbiztonságosabb EDI protokoll.

Leggyakrabban HTTPS kapcsolaton keresztül működik.

Az AS2 támogatja:

  • az SSL/TLS titkosítást,
  • a digitális aláírást,
  • a tanúsítvány alapú hitelesítést,
  • és az automatikus visszaigazolást.

Mi az SSL tanúsítvány?

Az SSL/TLS tanúsítvány olyan, mint egy digitális személyi igazolvány.

Segítségével a két rendszer ellenőrizni tudja:

  • valóban a megfelelő partnerrel kommunikál-e,
  • nem módosult-e az adat,
  • biztonságos-e a kapcsolat.

Ez különösen fontos, mert az EDI üzenetek gyakran tartalmaznak:

  • számlaadatokat,
  • árakat,
  • rendeléseket,
  • logisztikai információkat,
  • partner adatokat.

Mi az MDN?

Az EDI világ „tértivevénye”

Az AS2 egyik legfontosabb funkciója az MDN (Message Disposition Notification).

Ez gyakorlatilag az EDI világ olvasási visszaigazolása.

Email analógiával:

„A címzett megkapta és megnyitotta az üzenetet.”

EDI esetén:

„A partner rendszere sikeresen megkapta, ellenőrizte és hitelesnek találta az üzenetet.”

Az MDN visszajelzi például:

  • sikeres volt-e az átvitel,
  • helyes volt-e a digitális aláírás,
  • sérült-e az adat,
  • sikerült-e a dekódolás.

Fontos:

Az MDN még nem üzleti visszaigazolás.

Csak azt igazolja, hogy az üzenet technikailag rendben megérkezett.


SFTP

A digitális páncélszekrény

Az SFTP biztonságos fájlátvitelt biztosít SSH kapcsolaton keresztül.

Egyszerű, stabil és nagyon elterjedt.

Olyan, mint egy közös, zárt digitális mappa, amelyhez mindkét fél rendelkezik kulccsal.


OFTP / OFTP2

Az autóipar kedvence

Az OFTP2 protokollt főleg autóipari környezetben használják.

Tipikus partnerek:

  • Audi
  • BMW
  • Mercedes
  • Bosch

Nagy méretű fájlokra és rendkívül stabil kommunikációra tervezték.


SLMP

Az SLMP (Secure Link Management Protocol) a SEEBURGER saját fejlesztésű protokollja, amelyet a vállalat a Business Integration Server (BIS) és Managed File Transfer (MFT) rendszereihez fejlesztett ki. Nem összekverendő a Mitsubishi által kifejlesztett SLMP protokollal.

Célja a nagyméretű, rendszer-a-rendszer közötti (system-to-system) adatcserék biztonságos és gyors lebonyolítása, a következő tulajdonságok révén:


Mire van szükség a kapcsolat beállításához?

Ahhoz, hogy a két rendszer „kezet foghasson”, számos technikai adatot kell egyeztetni.

Például:

  • AS2 ID-k
  • GLN számok
  • IP címek
  • portok
  • SSL tanúsítványok
  • titkosítási algoritmusok
  • retry szabályok
  • időtúllépési beállítások

A rendszernek azt is tudnia kell:

  • hányszor próbálkozzon újra hiba esetén,
  • mikor küldjön riasztást,
  • és hogyan naplózza a kommunikációt.

Összefoglalás

Az EDI folyamat első része tehát:

ERP rendszer
    ↓
Kiinduló üzleti adat
    ↓
EDI konverzió / szabványosítás
    ↓
Biztonságos kommunikációs protokoll
    ↓
Partner rendszere
    ↓
MDN / technikai visszaigazolás

Az EDI valójában nem más, mint automatizált, szabványosított és biztonságos üzleti kommunikáció vállalatok között.

A következő részben megnézzük:

  • mi történik az EDI szolgáltató „fekete dobozában”,
  • mi az a mapping,
  • miért nem lehet „csak úgy” fájlokat küldözgetni,
  • és miért olyan fontosak a guideline-ok.