Elektronická výměna dat (EDI)
Co je elektronická výměna dat (EDI)?
Elektronická výměna dat (EDI) je výměna strukturovaných obchodních dokumentů mezi organizacemi z počítače do počítače pomocí dohodnutých standardů. V logistice, elektronickém obchodování a mezinárodním obchodu umožňuje systémům provozovaným kupujícími, dodavateli, sklady, přepravci a dalšími obchodními partnery vyměňovat si informace, jako jsou objednávky, avíza o odeslání, přepravní pokyny a faktury, aniž by lidé museli každý dokument znovu ručně zadávat.
Definujícím rysem EDI není pouze to, že jsou informace odesílány elektronicky. Informace jsou uspořádány do polí, segmentů a zpráv, které přijímající software dokáže interpretovat podle dohodnuté specifikace. Faktura připojená k e-mailu jako PDF proto sama o sobě není fakturou EDI: její obsah může být stále nutné extrahovat člověkem nebo nástrojem pro zpracování dokumentů, než jej bude moci podnikový systém použít.
EDI popisuje metodu výměny obchodních informací, nikoli jeden softwarový produkt, síť nebo formát souboru. Funkční uspořádání závisí na kompatibilních definicích dokumentů, komunikačních metodách, identifikátorech a obchodních pravidlech.
EDI v logistice a elektronickém obchodování
EDI propojuje činnosti, které překračují hranice organizací. Nákupní systém maloobchodníka může vygenerovat objednávku, systém dodavatele ji může potvrdit a sklad může obdržet pokyny k přípravě zboží. Informace o zásilce a faktury se pak mohou mezi příslušnými systémy přesouvat jako samostatné zprávy.
V elektronickém obchodování může EDI podporovat procesy mezi podniky, které probíhají na pozadí obchodu určeného spotřebitelům. Internetový prodejce jej může například využívat k objednávání zásob od dodavatele nebo k výměně informací o plnění objednávek se skladem. Transakce spotřebitele při dokončení objednávky a následné zprávy EDI maloobchodníka jsou související obchodní události, ale nemusí jít o stejnou transakci ani používat stejné technické rozhraní.
V přeshraničním obchodu může EDI přenášet informace potřebné pro mezinárodní přepravu a obchodní dokumentaci. Celní správy mohou také používat strukturované elektronické zprávy podle vlastních specifikací. Výměna zprávy EDI s dodavatelem nebo přepravcem však sama o sobě nepředstavuje celní prohlášení, nezakládá dodržení právních předpisů ani neopravňuje k propuštění zboží.
Běžné obchodní dokumenty
Následující příklady ilustrují funkce dokumentů, nikoli povinné pořadí. Používané zprávy závisí na obchodním vztahu a příslušné implementační příručce.
| Dokument nebo zpráva | Obchodní účel | Příklad z logistiky nebo elektronického obchodu |
|---|---|---|
| Objednávka | Sděluje objednávku zboží nebo služeb od kupujícího. | Maloobchodník objedná u dodavatele doplnění zásob. |
| Odpověď na objednávku nebo potvrzení | Sděluje odpověď dodavatele na objednávku. | Dodavatel potvrdí množství nebo navrhne změny, pokud je dohodnutá zpráva podporuje. |
| Avízo o odeslání nebo avízo o expedici | Popisuje zásilku před jejím doručením. | Sklad obdrží informace o očekávaných kartonech, položkách a množstvích. |
| Přepravní pokyn | Sděluje pokyny pro přepravní službu. | Odesílatel pošle dohodnuté podrobnosti o přepravě přepravnímu partnerovi. |
| Zpráva o stavu zásilky | Sděluje přepravní událost nebo stav. | Přepravce oznámí událost spojenou se zásilkou. |
| Faktura | Sděluje fakturační informace. | Dodavatel vyúčtuje maloobchodníkovi dodané zboží. |
Avízo o odeslání, často zkracované jako ASN, popisuje očekávanou zásilku; nedokazuje, že zboží dorazilo. Stejně tak zpráva o stavu zásilky není automaticky dokladem o doručení. Její význam závisí na nahlášené události a podpůrných informacích.
Standardy, formáty a komunikační metody
Standardy EDI definují, jak jsou obchodní zprávy strukturovány a co znamenají jejich datové prvky. Dvě zavedené rodiny standardů jsou X12 a pravidla Organizace spojených národů pro elektronickou výměnu dat v administrativě, obchodě a dopravě, známá jako UN/EDIFACT. Standardy EDI spravuje také GS1, včetně EANCOM, který vychází z UN/EDIFACT, a GS1 XML.
V rámci X12 patří mezi příklady 850 Purchase Order, 856 Ship Notice/Manifest a 810 Invoice. UN/EDIFACT poskytuje zprávy jako ORDERS pro objednávky, DESADV pro avízo o expedici a INVOIC pro faktury. Tyto příklady mají napříč standardy související obchodní účely, ale jejich struktury a požadavky na implementaci nejsou zaměnitelné.
Samotný standard nedefinuje každý detail obchodního vztahu. Partneři se musí dohodnout také na příslušné verzi a implementační příručce, povinných polích, povolených kódech, identifikátorech a validačních pravidlech. Dvě organizace mohou podporovat stejnou rodinu standardů a přesto potřebovat mapování, než jejich systémy budou moci vyměňovat použitelné zprávy.
| Komponenta | Co určuje | Příklad |
|---|---|---|
| Standard zprávy | Strukturu a význam obchodní zprávy. | Faktura X12 nebo avízo o expedici UN/EDIFACT. |
| Implementační příručka | Jak se konkrétní zpráva používá v obchodním vztahu. | Požadované identifikátory zásilky a povolené jednotky množství. |
| Komunikační metoda | Jak se zpráva přenáší mezi systémy. | AS2 nebo dohodnuté zabezpečené uspořádání přenosu souborů. |
| Překlad a mapování | Jak externí pole zprávy odpovídají interním aplikačním datům. | Mapování příchozí řádky objednávky na záznam v systému správy objednávek. |
AS2 je komunikační specifikace pro výměnu obchodních dat přes HTTP, která obsahuje mechanismy zabezpečení a potvrzení přijetí. Není to formát objednávky ani faktury. Síť s přidanou hodnotou neboli VAN může poskytovat zprostředkovatelské služby výměny zpráv; stejně tak se liší od standardu obchodních dokumentů.
Jak výměna EDI funguje
- Obchodní událost vytvoří data. Kupující například schválí objednávku v podnikovém systému ERP nebo v systému správy objednávek.
- Data se namapují do zprávy. Překladový software převede interní pole do struktury požadované dohodnutým standardem a implementační příručkou.
- Odchozí zpráva se zkontroluje. Validace může kontrolovat syntaxi, povinná pole, hodnoty kódů a požadavky konkrétního partnera.
- Zpráva se odešle. Projde dohodnutým komunikačním kanálem k příjemci nebo zprostředkovateli.
- Příjemce ji ověří a přeloží. Přijímající systém zprávu zkontroluje a přijaté informace namapuje do svého interního aplikačního formátu.
- Následuje obchodní zpracování. Přijímající aplikace může vytvořit objednávku, zaznamenat očekávaný příjem nebo předat výjimku ke kontrole.
- Odpovědi se odsouhlasí. Technická potvrzení přijetí, potvrzení a obchodní odpovědi pomáhají odesílateli zjistit, co se s výměnou stalo.
Tyto kroky nezaručují, že každá transakce bude zpracována automaticky. Neznámý identifikátor produktu, neplatné místo doručení, duplicitní číslo dokumentu nebo nepodporovaná měrná jednotka mohou vyžadovat zásah, i když je zpráva strukturálně platná.
Přijetí, validace a obchodní akceptace
Potvrzení EDI fungují na různých úrovních. Potvrzení přenosu může znamenat, že zpráva dorazila ke komunikačnímu koncovému bodu. Funkční nebo implementační potvrzení může oznámit výsledky strukturálních kontrol. Obchodní odpověď může sdělit, zda byla objednávka nebo jiný požadavek přijat, odmítnut nebo změněn.
Tyto signály by neměly být považovány za rovnocenné. Úspěšný přenos nemusí nutně znamenat, že objednávka byla přijata nebo že zboží bude odesláno. Konkrétní význam potvrzení musí být vykládán podle příslušné specifikace a dohody s obchodním partnerem.
Ilustrativní příklad od objednávky k odeslání
Maloobchodník může prostřednictvím EDI odeslat objednávku zahraničnímu dodavateli. Systém dodavatele zkontroluje identifikátory produktů, množství a požadované informace o doručení. Pokud obchodní uspořádání zahrnuje odpověď na objednávku, může dodavatel svou akceptaci nebo navrhované změny sdělit prostřednictvím samostatné zprávy.
Po přípravě zboží může dodavatel vystavit avízo o odeslání s identifikací zásilky a jejího obsahu. Přijímající sklad může tyto informace využít k přípravě na příjem a porovnat očekávaná množství se skutečně přijatým zbožím. Dodavatel může také zaslat fakturu ke zpracování ve finančním systému maloobchodníka.
Tento příklad ukazuje, jak EDI propojuje záznamy napříč organizacemi. Neznamená to, že všechny strany používají stejný software, že je každá zpráva doručena v reálném čase nebo že obchodní dokumenty nahrazují požadavky na přepravu a clo. Spárování objednávek, referencí zásilek a faktur stále vyžaduje konzistentní identifikátory a dohodnutou obchodní logiku.
EDI a související technologie
| Související pojem | Vztah k EDI | Důležitý rozdíl |
|---|---|---|
| Rozhraní pro programování aplikací (API) | Rozhraní, jehož prostřednictvím software vyměňuje požadavky a data. | EDI klade důraz na standardizované obchodní zprávy; API definuje interakci se softwarovou službou. Obě technologie mohou existovat společně. |
| XML | Značkovací jazyk používaný ke strukturování dat. | Samotná syntaxe XML nezakládá dohodnutý standard obchodních zpráv. |
| Elektronická fakturace | Elektronické vystavování a výměna faktur. | EDI může podporovat elektronickou fakturaci, ale právní a technické požadavky se liší podle jurisdikce. |
| ERP nebo systém řízení skladu | Aplikace, která vytváří nebo využívá obchodní informace. | Tyto systémy řídí provoz; EDI poskytuje způsob výměny informací s jinými organizacemi. |
| Sledování zásilky | Hlášení a interpretace událostí zásilky. | EDI může přenášet informace o stavu, ale samo o sobě není sledovacím webem ani kompletní sledovací službou. |
EDI a API nejsou v každé architektuře vzájemně se vylučující alternativy. Organizace může používat zprávy EDI pro transakce s partnery a API k propojení těchto transakcí s interními aplikacemi. Vhodné uspořádání závisí na požadavcích dokumentů, schopnostech partnerů, časových potřebách a provozních kontrolách, nikoli pouze na označení technologie.
Aspekty implementace a omezení
EDI může omezit opakované ruční zadávání dat, pokud si systémy úspěšně vyměňují a zpracovávají kompatibilní zprávy. Neopravuje však nepřesná zdrojová data, neřeší obchodní spory ani neodstraňuje potřebu zpracování výjimek. Automatizace závisí jak na technické kompatibilitě, tak na kvalitě vyměňovaných obchodních informací.
Před navázáním připojení EDI by si obchodní partneři měli vyjasnit následující provozní body:
- Rozsah dokumentů: Které zprávy jsou vyžadovány a které obchodní události je spouštějí?
- Identifikátory: Jak budou identifikovány a spárovány produkty, místa, strany, objednávky a zásilky?
- Požadavky na zprávy: Které verze, povinná pole, seznamy kódů a pravidla mapování platí?
- Komunikace a zabezpečení: Která metoda připojení, nastavení ověřování a přístupové kontroly jsou vyžadovány?
- Potvrzení: Které odpovědi označují doručení, validaci a obchodní akceptaci?
- Zpracování výjimek: Kdo prověřuje odmítnuté zprávy, chybějící odpovědi a nekonzistentní data?
- Prevence duplicit: Jak budou opakovaná odeslání odlišena od nových obchodních transakcí?
- Testování a řízení změn: Jak budou mapování a požadavky partnerů testovány před nasazením změn do produkce?
Provozní monitoring by měl rozlišovat mezi komunikačními chybami, chybami validace dat a obchodními výjimkami. Opětovné odeslání zprávy může vyřešit neúspěšný přenos, ale neopraví neplatný kód produktu. Bez kontroly duplicit by opětovné odeslání úspěšně zpracované objednávky mohlo také vytvořit nechtěnou druhou transakci.
Časté dotazy
Co znamená EDI v logistice?
EDI znamená elektronickou výměnu dat: strukturovanou výměnu obchodních dokumentů mezi systémy. V logistice mohou tyto dokumenty zahrnovat avíza o odeslání, přepravní pokyny, faktury a zprávy o stavu zásilky.
Je PDF zaslané e-mailem dokumentem EDI?
Samo o sobě ne. PDF může obchodní dokument elektronicky prezentovat, ale EDI vyžaduje strukturované informace, které přijímající systémy dokážou interpretovat podle dohodnuté specifikace.
Je EDI totéž co API?
Ne. EDI se týká standardizované výměny obchodních dokumentů, zatímco API definuje, jak software interaguje s jinou službou. Integrace může využívat obojí.
Znamená potvrzení EDI, že objednávka byla přijata?
Ne nutně. Potvrzení mohou potvrzovat přenos nebo strukturální validaci, nikoli obchodní akceptaci. Jeho význam určuje typ zprávy a dohoda s obchodním partnerem.
Zdroje
- UNECE: UN/EDIFACT — Oficiální rámec pro strukturovanou elektronickou výměnu administrativních, obchodních a přepravních dat.
- X12: Transaction Sets — Oficiální popisy obchodních transakčních sad včetně objednávek, faktur, avíz o odeslání a potvrzení.
- GS1: Electronic Data Interchange — Standardy obchodních zpráv a vztah mezi GS1 EDI, EANCOM a GS1 XML.
- RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 — Přenos AS2, bezpečnostní mechanismy a oznámení o přijetí.
