techone --pruvodce=edi
EDI integrace pro výrobce: od specifikace k provozu
EDI propojuje objednávky, avíza, dodací listy a faktury s ERP. Spolehlivý provoz vyžaduje jasné zprávy, zdroje dat, testování, monitoring a odpovědnost za chyby.
Ve zkratce
- Vstupní podklady
- Potřebujeme implementační příručku partnera, vzorové zprávy, číselníky, kontakty, požadovaný termín a popis akceptace.
- Obchodní tok
- Každá zpráva musí navazovat na konkrétní událost, obchodní doklad a stav v obou firmách.
- Způsob napojení
- Při volbě platformy, přímého napojení nebo portálu rozhoduje také to, kdo bude spravovat mapování, komunikaci, dohled a budoucí změny.
- Akceptace
- Před spuštěním ověřujeme běžné varianty, duplicity, chybné hodnoty, potvrzení a obnovení přenosu po výpadku.
- Podklady pro realizaci
- Získáte rozsah zpráv, návrh napojení, mapovací dokumentaci, testovací plán, rozdělení provozních odpovědností a podklady pro odhad.
Co musí určit partnerova EDI specifikace
UN/EDIFACT definuje standardizované obchodní zprávy a GS1 EANCOM jejich používanou podmnožinu. Pro realizaci ale nestačí název standardu. Rozhoduje profil konkrétního partnera, jeho obchodní proces, povinná data, způsob komunikace a podmínky akceptace.
Obchodní tok a zprávy
Nejdřív určujeme, která událost zprávu vytváří, kdo ji odesílá, jaký doklad vznikne u příjemce a co následuje. ORDERS, DESADV nebo INVOIC jsou běžné příklady, konkrétní směr a návaznost však stanoví partner.
Formát, verze a profil
Označení EDIFACT nebo XML nepopisuje povinná pole ani číselníky. Potřebujeme verzi, podmnožinu standardu, partnerův profil, příklady a pravidla pro segmenty, které mohou být v obecném standardu volitelné.
Identifikátory a kmenová data
Mapování musí spojit partnery, provozovny, položky, jednotky, balení a daňové údaje. GLN nebo GTIN se použijí tam, kde je partner vyžaduje; jiné scénáře pracují s vlastními kódy odběratele a dodavatele.
Komunikační kanál a zabezpečení
Specifikace určuje AS2, SFTP, OFTP2, síť VAN nebo rozhraní platformy, včetně adres, účtů, certifikátů a potvrzení. V automobilovém průmyslu se často používají DELFOR, DELJIT a OFTP2, konkrétní požadavky však vždy stanoví obchodní partner.
Testování, akceptace a provoz
Součástí zadání jsou testovací případy, kontakty, reakční časy, podmínky schválení a datum přechodu. Pro provoz potřebujeme také význam jednotlivých potvrzení, postup při chybě a určení, kdo ji na každé straně opraví.
Jak připravujeme EDI napojení
EDI integrace má dvě navazující části: výměnu zpráv mezi obchodními partnery a jejich zpracování ve firemních systémech. Před vývojem proto musí být potvrzený tok zpráv, zdroje dat a způsob testování.
Shromáždíme specifikaci a vzorové zprávy
Projdeme implementační příručku, zprávy, číselníky, komunikační požadavky, testovací kontakty a termíny. Chybějící nebo rozporné informace sepíšeme jako otevřené otázky pro partnera.
Zmapujeme obchodní tok a zdroje dat
U každé zprávy určíme spouštěcí událost, zdroj hodnot, cílový doklad, stav po zpracování a návaznou odpověď. Zahrneme také změny, storna, částečná plnění a další běžné varianty.
Vybereme integrační a komunikační cestu
Porovnáme EDI platformu, přímé systémové napojení a portál partnera. U zvolené varianty popíšeme protokol, identifikátory, certifikáty a odpovědnost za transformace, dostupnost, archivaci a provozní dohled.
Navrhneme mapování a chování při chybě
U každého pole popíšeme zdroj, cílový prvek, transformační pravidlo a příklad. Doplníme validace, převody jednotek, číselníky, rozpoznání duplicit, potvrzení a postup pro bezpečnou opravu a opakování.
Ověříme napojení s partnerem
Nejdřív ověříme zpracování uvnitř firmy a potom projdeme testovací postup obchodního partnera. Vedle správných zpráv testujeme chybné hodnoty, návaznost dokladů, duplicity, nedostupnost a opakované doručení.
Spustíme napojení a nastavíme dohled
Před přechodem ověříme produkční adresy, identifikátory, certifikáty, fronty a kontakty. Po spuštění sledujeme přenos, potvrzení i obchodní zpracování a nastavíme obnovu certifikátů a eskalaci.
Platforma, přímé napojení nebo portál
Všechny tři varianty mohou splnit požadavek obchodního partnera. O volbě rozhoduje, kdo bude spravovat komunikaci, transformace, certifikáty, monitoring a změny, nikoli jen počet partnerů nebo objem zpráv.
EDI platforma
Platforma může převzít komunikační kanály, část transformací, archivaci a dohled. Firma však stále potřebuje spolehlivé rozhraní do ERP, vlastní datová pravidla a jasný postup pro chyby, které musí opravit její tým.
Přímé systémové napojení
Firma řídí komunikaci, mapování i provoz ve vlastní architektuře. Tato cesta nabízí větší kontrolu nad řešením, současně však vyžaduje kapacitu pro certifikáty, změny specifikací, dostupnost, monitoring a podporu.
Portál obchodního partnera
Portál může splnit požadavek bez systémové integrace, ale lidé zprávy zadávají nebo stahují ručně. Je vhodný hlavně pro méně častou výměnu dokladů a jednoduchý tok; s rostoucím objemem je potřeba znovu posoudit přínos automatizace.
Varianty porovnáváme na stejném obchodním scénáři, požadované dostupnosti, očekávaných změnách a odpovědnosti za provoz.
Jak EDI zpráva navazuje na ERP
EDI nekončí doručením souboru. Zpráva musí projít kontrolou, spojit se se správným partnerem a dokladem a bezpečně změnit stav v ERP. Napojení může využít API, soubory, databázové rozhraní nebo integrační vrstvu. U Dynamics 365 Business Central lze pracovat se standardními a vlastními API; vždy ověřujeme konkrétní verzi, entity, autentizaci a rozšíření.
Příjem a přiřazení zprávy
Při přijetí se zprávě přiřadí technický identifikátor a vazba na odesílatele. Integrace uchová původní obsah a údaje potřebné pro dohledání přenosu, potvrzení a případného opakování.
Technická a obsahová validace
Nejdřív se ověří syntaxe, verze a povinné prvky, potom obchodní pravidla. Neznámá položka, jednotka nebo provozovna se nesmí tiše propsat do platného dokladu.
Mapování kmenových dat
Kódy partnera se převádějí na interní partnery, položky, jednotky, sklady a další objekty. Musí být určeno, kdo mapování spravuje, jak dlouho platí a co se stane s hodnotou, která zatím v ERP neexistuje.
Bezpečný zápis do ERP
Integrace používá podporované rozhraní ERP a respektuje jeho obchodní logiku. Před zápisem ověřuje cílový doklad a stav; při opakovaném doručení nevytvoří stejný případ podruhé.
Potvrzení a stav zpracování
Technické doručení ještě neznamená, že ERP zprávu přijalo obchodně. Návrh proto rozlišuje přenos, syntaktickou validaci, vytvoření dokladu, zamítnutí a případnou odpověď partnerovi.
Dohled a kontrola úplnosti
Provozní přehled propojuje zprávu, partnera, obchodní doklad a poslední stav. Umožní najít čekající nebo odmítnuté zprávy a pravidelně ověřit, že mezi oběma stranami nic nechybí.
Co musí integrace prokázat před spuštěním
Jedna správná vzorová zpráva nestačí. Akceptace musí pokrýt běžný tok, jeho varianty i stavy, které by v provozu vytvořily chybný doklad nebo zastavily další zpracování. Přesnou sadu určuje scénář a testovací postup partnera.
Správný doklad a stav
Platná zpráva vytvoří nebo změní správný obchodní doklad, použije odpovídající kmenová data a pokračuje do očekávaného stavu bez ruční opravy.
Chybějící nebo neznámá hodnota
Chybějící povinné pole, neznámý kód nebo neplatná kombinace se zastaví před obchodním zápisem. U chyby musí být srozumitelný popis, odpovědná osoba a postup opravy.
Duplicitní zpráva
Opakované doručení stejné zprávy nevytvoří druhý doklad ani další pohyb. Integrace rozpozná duplicitu a zaznamená, že zpráva už byla zpracována.
Změna, storno a částečné plnění
Zpráva naváže na správný původní doklad a respektuje jeho aktuální stav. Nepovolenou změnu odmítne nebo předá k rozhodnutí podle dohodnutého postupu.
Potvrzení nebo odmítnutí
Chybějící, záporné nebo opožděné potvrzení vyvolá definovanou reakci. Tým ví, kdy čekat, kdy opakovat přenos a kdy kontaktovat partnera.
Výpadek a bezpečné obnovení
Po přerušení komunikace nebo nedostupnosti ERP lze zpracování obnovit bez ztráty zprávy a bez dvojího zápisu. Fronty a opakování mají vlastní limity a dohled.
Dohledatelnost celého toku
Z identifikátoru partnera, zprávy nebo obchodního dokladu lze dohledat přijetí, validaci, zápis, potvrzení, chybu i následnou opravu.
Zkušenost TechOne s EDI projekty
Máme zkušenosti s realizací EDI v ERP i s analytickou přípravou, která pomáhá zvolit vhodný způsob výměny dokladů.
Lagardère Travel Retail
Pro nákupní procesy Lagardère jsme popsali tok dokladů, namapovali zprávy DESADV a INVOIC, nastavili jejich zpracování v ERP a ověřili komunikaci v testovacím i produkčním prostředí.
Tecam PCV
Při analýze elektronické výměny dokladů jsme zmapovali nákup, příjem zboží, fakturaci a současné importní skripty. Prověřili jsme EDI zprávy, jejich mapování do ERP a komunikační scénáře s dodavateli. Výsledkem byl podklad pro rozhodnutí využít platformu wflow.
Holík International
V rámci analýzy výroby a skladu jsme navrhli EDI komunikaci s dodavateli jako jednu z částí postupné digitalizace. Návrh navázal na plán změn ERP, skladové evidence a práce ve výrobě.
Konkrétní rozsah nového napojení určuje specifikace obchodního partnera, současné ERP a rozdělení odpovědností při realizaci i v provozu.
Často kladené otázky
Jaké podklady potřebujete pro návrh a odhad EDI napojení?
Potřebujeme implementační příručku obchodního partnera, vzorové zprávy, číselníky, popis komunikačního kanálu, testovací postup, požadovaný termín a kontakty. Na straně firmy ověřujeme ERP a jeho verzi, zdroje dat, vlastníky procesu, současné doklady a provozní požadavky.
Kdy prověřit EDI platformu, přímé napojení nebo portál partnera?
Platformu prověřujeme, když má převzít více komunikačních kanálů, transformace a část provozu. Přímé napojení dává smysl, pokud firma chce a umí spravovat vlastní integrační cestu. Portál může stačit pro méně častou výměnu dokladů a jednoduchý tok. Rozhodují také SLA, bezpečnost, změny, monitoring a schopnost řešit chyby.
Lze EDI napojit i na ERP bez vlastního EDI modulu?
Ano, pokud ERP nabízí podporované API, souborové nebo databázové rozhraní, případně lze použít integrační mezivrstvu. Před návrhem ověřujeme verzi, autentizaci, dostupná data, obchodní logiku a podporu dodavatele. Přímý zápis do databáze bez dohodnutého rozhraní může obejít pravidla ERP a ztížit aktualizace.
Co určuje rozsah, termín a cenu realizace?
Rozsah ovlivňuje počet toků a zpráv, rozdíl mezi daty partnera a ERP, kvalita kmenových dat, komunikační kanál, certifikáty, potřebný vývoj, testovací postup, reakce partnera, přechod a požadovaný provozní dohled. Odhad lze připravit po shromáždění těchto podkladů a vyjasnění otevřených otázek.
Co lze znovu využít při napojení dalšího obchodního partnera?
Znovu lze použít komunikační infrastrukturu, část konektoru do ERP, monitoring, archivaci a některé mapovací komponenty. Nový partner však může mít jinou verzi, profil, číselníky, testy a provozní pravidla. Každé napojení proto potřebuje vlastní kontrolu rozdílů a akceptaci.
Související témata
ERP integrace (služba)
Podporované rozhraní, vlastnictví dat a provozní dohled mezi ERP a navazujícími systémy.
Logistika a ERP
Jak EDI zprávy navazují na příjem, zásobu, expedici a skutečný pohyb materiálu.
ERP ve výrobě
Návaznost dodavatelských a odběratelských zpráv na plánování a provedení výroby.
Řešíte EDI napojení?
Na úvodní schůzce projdeme příručku obchodního partnera, vzorové zprávy, současné ERP, požadovaný termín a způsob testování. Společně určíme, co je potřeba doplnit pro návrh, odhad a realizaci.