ZÁPADOČESKÁ UNIVERZITA V PLZNI

Transkript

1 ZÁPADOČESKÁ UNIVERZITA V PLZNI FAKULTA EKONOMICKÁ Bakalářská práce Implementace EDI v organizaci EDI implementation in organization Jakub Zahrádka Plzeň 2018

2

3 Čestné prohlášení Prohlašuji, že jsem bakalářskou práci na téma Implementace EDI ve společnosti Vypracoval samostatně pod odborným dohledem vedoucího bakalářské práce za použití pramenů uvedených v přiložené biografii. V Plzni, dne... podpis autora

4 Poděkování Tímto bych chtěl velmi poděkovat svému vedoucímu bakalářské práce, RNDr. Mikuláši Gangurovi, Ph.D., za věcné rady a veškerý volný čas, který mi věnoval. Dále bych chtěl také poděkovat panu Ing. Lukáši Rampovi ze společnosti AIMTEC a.s. za čas a rady, které mi během konzultací věnoval.

5 Obsah Úvod Teoretická východiska Informační systém Zavádění informačního systému Enterprise Resource Planning (ERP) EDI Posílání EDI zpráv EDI standardy Typy EDI řešení Typy EDI zpráv Struktura EDIFACT dokumentu Konvertor a mapovací programy EDI v různých průmyslech Výhody zavádění a implementace EDI Implementace EDI XML a XSL jazyky XML Syntaxe XML dokumentu XSL XPath XSLT XSL šablony XSLT elementy Představení společnosti AIMTEC a.s Vznik tématu práce Metodika práce Použitý software OxygenXML Editor Atom XSL Transformer Proces výměny zpráv Získávání vstupních dat

6 2.3.1 Konverze dat pomocí XSL Odeslání zprávy Vlastní řešení Fiktivní společnost XYZ s.r.o Implementace EDI ve společnosti XYZ s.r.o Proces konverze Transformace EDIFACT na IDoc Transformace INVOICE EDIFACT na EDIFACT Zhodnocení EDI řešení Závěr Seznam použitých zkratek Seznam obrázků Seznam tabulek Seznam použité literatury Seznam příloh

7 Úvod Téma bakalářské práce vzniklo na základě předchozí spolupráce se společností AIMTEC a.s., kde autor již v minulosti vypracoval dvě semestrální práce, jednu z nich, jež se zabývala právě mapováním elektronické výměny dat (EDI). Elektronická výměna dat je moderním způsobem komunikace mezi dvěma nezávislými softwarovými systémy, při které dochází k výměně standardních strukturovaných dokumentů elektronickou formou. Hlavním cílem práce je implementovat nejvhodnější EDI řešení pro autorem vybranou fiktivní firmu a na základě toho vytvořit EDI konvertor zpráv, který mapuje objednávku a fakturu tak, aby mohla být odeslána příjemci. Jako nejvhodnější řešení se považuje takové, které společnosti přinese největší úspory, zrychlí tok dokumentů a zároveň bude vyhovovat organizační i finanční struktuře firmy. Mezi dílčí cíle práce patří: základní seznámení se s technologií EDI, způsobem přenosu elektronických dat a jednotlivými EDI standardy popsat různé druhy výměny elektronických zpráv identifikovat různá odvětví, ve kterých se EDI implementuje a popsat výhody jeho implementace Práce je rozdělena na tří hlavní část. V první kapitole práce autor popisuje hlavně teoretické znalosti z oblasti informačních systémů a ERP, obecně pak čtenáře seznamuje s technologií EDI, typy EDI řešení a jednotlivými druhy zpráv. Dále také popisuje proces implementace EDI a výhody s ní spojené. V neposlední řadě také popisuje programovací jazyky XML a XSLT, které jsou nedílnou součástí praktické části práce. Na závěr první kapitoly je čtenář seznámen se společností AIMTEC, jež poskytla data k praktické části, a jsou objasněny důvody vzniku práce. Ve druhé kapitole je představen software, který byl používán při praktické části. Dále je popsán proces výměny EDI zpráv a způsob získávání vstupních dat pro konverzi. Ve třetí kapitole je popsána fiktivní firma, do které bude vybráno a naimplementováno EDI řešení, což umožní započít práci na samotné konverzi elektronických dat. Závěrem 7

8 praktické části práce je pak zhodnocení toho, zdali bylo vybrané EDI řešení zvoleno správně a jaké přineslo společnosti výhody. 8

9 1 Teoretická východiska 1.1 Informační systém Informační systém definujeme jako uspořádání vztahů mezi lidmi, datovými a informačními zdroji a procedurami jejich zpracování za účelem dosažení stanovených cílů. [1] Abychom správně pochopili předchozí definici, je důležité si vysvětlit rozdíl mezi datovými a informačními zdroji. Informace tvoří obsah toho, co si vyměňujeme s okolním světem, zatímco data jsou údaje o sledovaných objektech a stavech s cílem jejich převedení na informace. Další definice informačního systému zní takto: Informační systém je soubor technických prostředků (hardware, software) a dat, které zajišťují udržování a poskytování informací nebo dat jeho uživatelům. [2] Pokud bychom tedy shrnuli obě definice, můžeme říci, že hlavním cílem informačního systému je udržování a poskytování informací neboli dat jeho uživatelům. Uveďme si jednoduchý příklad na turistických značkách, které nás provázejí na našich pěších túrách. Turistické značky tvoří soustavu značení, které předávají informace o tom, kudy bychom měli pokračovat abychom dorazili do cíle a stejnou funkci plní i informační systém. Ovšem nejdůležitější částí informačního systému jsou lidé, kteří tvoří jeho nedílnou součást. Lidé jsou totiž ti, kteří využívají anebo dokonce tvoří informace, které jsou poté v systému ukládány a dále užívány. Výstup informačního systému tvoří informace. Tyto informace musí být kvalitní a spolehlivé, protože dezinformace vždy povede ke špatnému rozhodnutí. Shrnutím všech informací se tedy dostaneme k závěru, že informační systém slouží k získávání přehlednějších a jasných informací, čímž se zvýší efektivita práce a sníží se vynaložené náklady. [1, 2, 3] 1.2 Zavádění informačního systému Zavedení informačního systému můžeme rozdělit do několika částí zobrazených na obrázku 1. První je zadání, což je dokument, který obsahuje požadavky podniku pro výrobu informačního systému. Tyto požadavky jsou formulovány konceptuálně a zahrnují návrh řešení a realizace systému. Již v zadání musí být přesně definována věcná, technologická a provozní rizika, včetně způsobu jejich eliminace či snížení dopadů. V projekční části se vytváří již detailní specifikace funkčnosti a realizace informačního systému, časového a rozpočtového plánu a také se pomocí prototypování 9

10 ověří funkčnosti zpracování a ověřování dat. Během implementace již probíhá samotné zavádění do provozu. Předtím, než se spustí ostrý provoz, se informační systém otestuje v pilotním režimu, čímž se finálně ověří jeho funkčnost a minimalizuje se tak riziko spojené s migrací do produkce. Po samotném zavedení systému do produkce následuje ještě fáze, kdy klient převezme informační systém od IT firmy, která ho navrhla a převezme tak odpovědnost za jeho správu v produkčním prostředí. [4, 5, 6] Obr. č. 1 Výroba informačního systému Zdroj: Enterprise Resource Planning (ERP) V českém jazyce také známý jako podnikový informační systém je komplexní systém, který slouží k řízení firemních procesů jako je plánování, zásoby, nákup, prodej, marketing, finance nebo například personalistika. [7] Jako ERP označujeme různé systémy od těch nejmenších, které pokrývají jen část podnikových zdrojů až po ty největší, které řídí většinou celé podnikové procesy (SAP). Důležité je, že díky ERP jsme schopni spojit všechny podnikové informace, aplikace, lidské zdroje a procesy z různých částí organizace do jednoho funkčního celku, ve kterém se mnohem lépe plánuje a organizuje. Toto spojení a jednotlivé moduly ERP ukazuje obrázek číslo 2. Díky tomuto jsme schopni efektivněji předávat informace v reálném čase, uchovávat, sdílet či chránit firemní data, a to v rámci celé společnosti. Pokud bychom se funkcí ERP zabývali více dopodrobna, zjistíme, že takovýto software nejčastěji pokrývá oběh 10

11 objednávek, zakázek od zákazníků až po dodání samotného výrobku či služby. Díky této funkci tak zaměstnanci vidí přesný stav objednávky, včetně toho, zdali na skladě něco chybí. Dále pak díky ERP získává firma přehled nad platební morálkou svých zákazníků a historií jejich objednávek nebo smluv. Finanční stránka ERP je velmi různorodá, protože implementace kompletního systému mnohdy převyšuje návratnost investice, a tak firmy v dnešní době začínají preferovat cloudová řešení ERP, protože toto řešení je řadí mezi mnohem dosažitelnější, a to hlavně pro menší a střední podniky. To, jaký systém si společnost zvolí, závisí na její velikosti, složitosti a požadavcích dané společnosti. Důležité je nezapomenout, že i když ERP tvoří páteř softwaru v organizaci, stále je součástí podnikového informačního systému, a tak se musí zohlednit souvislosti a návaznosti na celé jeho okolí, tedy již existující software, data a lidi. [8, 9] Obr. č. 2 Diagram ukazující typické moduly systému ERP Zdroj: EDI EDI (Electronic Data Interchange) neboli elektronická výměna dat je definována jako elektronická výměna strukturovaných standardních zpráv mezi dvěma aplikacemi dvou nezávislých subjektů. [10] Jiný zdroj zase říká, že EDI je moderní způsob 11

12 komunikace mezi dvěma nezávislými subjekty, při které dochází k výměně standardních strukturovaných obchodních a jiných dokumentů elektronickou formou. [11] Pokud bychom si to uvedli do praxe, můžeme si elektronickou výměnu dat představit tak, že objednávku, kterou vytvoříme ve svém informačním systému, automaticky přeneseme do informačního systému dodavatele, aniž bychom museli objednávku, jakkoliv tisknout, či ji odesílat em, čímž by ji dodavatel musel ještě navíc vložit do svého systému. Cílem EDI je úplně nahradit papírové dokumenty těmi elektronickými, čímž dojde ke snížení nejenom finančních nákladů spojených s jejich výměnou a pořízením, ale také nákladů časových, protože celá výměna probíhá elektronicky a není tak zapotřebí dokumenty odesílat prostřednictvím například pošty. [12] Tímto také eliminujeme chybovost lidského faktoru, což může nejenom ušetřit práci při hledání případné chyby, ale hlavně čas při zadávání jednotlivých dat do systému. [13] Obrázek číslo 3 poukazuje na to, jaké činnosti jsou vynechány, zavedením EDI do podnikového systému. Obr. č. 3 Úspory elektronické fakturace Zdroj: Dle výzkumu společnosti GS1 UK z roku 2010 dokázali společnosti díky EDI ušetřit až 14 liber za objednávku v porovnání s manuálními procesy (pošta, fax, telefonování, cena papíru, přesnost zadávání dat a kontrola údajů). Dále pak až 8,5 liber na fakturách. Pokud bychom se na problém podívali z hlediska času zjistíme, že díky EDI proběhne proces, který trval průměrně pět dní během několika minut. [14, 50] 12

13 1.4.1 Posílání EDI zpráv EDI tedy vzniká v informačním systému a přenáší různé informace o požadovaných obchodních funkcích, jako je fakturování, zaslání objednávky a podobně. Problém je ovšem v tom, že každý informační systém si tyto údaje poskládá jinak (v různých atributech či pod jinými identifikátory) a proto si různé informační systémy mezi sebou nerozumí. [16] EDI jako takové je standardizovaný formát, díky kterému mohou informační systémy mezi sebou komunikovat tak, aby si rozuměli. Posílání EDI zpráv můžeme rozdělit do tří kroků: 1. Určit, která data chceme posílat: V první řadě je důležité si určit, která data chceme sdílet se svým obchodním partnerem. 2. Vytvoření EDI dokumentu: Dalším krokem bude převést vyexportovaná data do standardního EDI formátu. To vyžaduje speciální EDI konvertor, který definuje, jak mají být interní data mapována do formátu EDI. 3. Poslání zprávy: Potom co je zpráva přeložena je odeslána po internetu nebo pomocí EDI poskytovatele. [15] Proces vytváření EDI dokumentu znázorňuje obrázek číslo 4, kde můžeme vidět společnost, která má data ve svém interním formátu. Ty pomocí EDI konvertoru převede do EDI dokumentu a následně zprávu odešle příjemci, který ji zase pomocí konvertoru namapuje tak, aby seděla do jeho vlastního interního systému. 13

14 Obr. č. 4 Proces vytváření EDI dokumentu Zdroj: [15] Přijetí EDI zprávy probíhá opačným způsobem jako její posílání. Poté, co obdržíme EDI zprávu ji překladač konvertuje z EDI standardu do formátu našeho interního systému, načež vloží všechna data do systému, aby s nimi mohl dále pracovat. [15] Pokud bychom si shrnuli tuto kapitolu, můžeme říci, že pokud dobře integrujeme EDI systém do společnosti, nemusíme k přenosu dat využít papírové dokumenty, lidi a samotný přenos bude trvat jenom zlomek času EDI standardy EDI dokument je v podstatě elektronická verze papírového dokumentu, která podléhá jistým standardizovaným pravidlům. [15] A aby spolu mohli dvě společnosti vzájemně komunikovat bez pomoci lidského faktoru, musí obě mluvit stejným jazykem. Vzhledem k tomu, že vývoj EDI standardů pro komunikaci probíhal dohodou strukturovaných zpráv mezi jednotlivými partnery, kde každý partner využíval svoji vlastní strukturu a taky protože elektronická výměna dat je kompletně zpracovávána počítači, bylo potřeba začít využívat standardy, kterým budou počítače rozumět a budou 14

15 s nimi moci dále pracovat. [10] Tyto standardy popisují, o jakou jde informaci a v jakém datovém formátu (integer, desetinné číslo, datum) daná informace je. EDI standard si můžeme představit jako lidský jazyk, protože když každý člověk mluví jiným jazykem, navzájem si nerozumí. Stejně tak je tomu tedy i v případě počítačů. V dnešní době se používá mnoho formátů specifických pro různá odvětví a ve chvíli, kdy se dvě společnosti rozhodnou společně využívat EDI, musejí se dohodnout na využívání společného EDI standardu. Vývoj vedl ke vzniku odvětvových standardů, ovšem ani ty nebyly příliš vhodné ke komunikaci mimo odvětví společnosti. Proto později vznikly mezinárodní standardy pro elektronický přenos dat. Mezi hlavní standardy patří UN/EDIFACT, který byl navržen pro Evropu a ANSI X12 více používaný v Americe. Tyto dva standardy mohou být využity v každém průmyslovém odvětví. Pro každý z těchto standardů vzniklo ještě několik dalších substandardů, které mají své specifičtější využití. Mezi tyto substandardy patří EANCOM (přidává podporu EAN kódů), ODETTE (automobilový průmysl v Evropě), SWIFT (bankovnictví) a VDA (německé automobilky). ANSI byl navržen pro různé průmysly v Severní Americe, nicméně v dnešní době je tak rozšířený, že je využíván po celém světě. EANCOM byl původně navrhnut pro využití v maloobchodu, nicméně se rozšířil tak, že se v dnešní době využívá i ve zdravotnictví a stavitelství. [17, 18, 19, 50] Typy EDI řešení Aby mohlo být EDI využíváno v co nejširším spektru odvětví, bylo vytvořeno několik typů výměny elektronických zpráv. Ať už se jedná o organizaci, která se s EDI ještě nesetkala, nebo giganta, který se rozrůstá a potřebuje pokrýt výměnu zpráv celosvětově, existuje metoda EDI, která bude pro daný případ nejvhodnější. V dnešní době existuje mnoho způsobů EDI komunikace a již dávno neplatí, že pro zavedení EDI je třeba mít silné IT zázemí a spoustu finančních prostředků. Většina EDI řešení lze tak rozdělit do tří kategorií, a to přímou výměnu mezi jednotlivými partnery, výměnu prostřednictvím VAN operátora a EDI jako služba. [20] Každé z těchto řešení je jinak finančně i provozně náročné pro obě obchodní strany. Proto je důležité si umět zvolit, které EDI řešení přinese společnosti nejvíce výhod. EDI komunikace slouží především k propojení jednotlivých informačních systému, které si obecně nerozumí, protože každý mluví svým vlastním jazykem a úkolem EDI je právě propojení těchto systému na základě obecně přijímaných standardů. Pro překlad 15

16 zpráv mezi jednotlivými informačními systémy se využívají EDI konvertory, které převedou vstupní data z informačního systému do EDI formátu, ze kterého se vytvoří zpráva, která se přenese do konvertoru obchodního partnera, který ji zase přeloží tak, aby jí rozuměl jejich vlastní informační systém. Pro lepší představu, jak fungují jednotlivé typy EDI řešení jsou dále uvedeny jejich popisy a příklady. 1. Direct EDI zabezpečené point-to-point spojení napřímo mezi dvěma obchodními partnery. Každá z obchodních stran musí vlastnit konvertor a dále také komunikační software. Z toho vyplývá, že komunikace s vícero partnery je velmi nákladná, protože pro každého partnera musí být vytvořeno vlastní spojení. Dále je také nutno počítat náklady na správu, údržbu, aktualizaci a provoz obou těchto systémů. Proto tento typ spojení využívají hlavně větší společnosti, které spolu komunikují na denní bázi. [15, 21] 2. EDI přes AS2 AS2 je jednou z nejpopulárnějších metod pro bezpečný a spolehlivý přenos EDI dat. AS2 vyžaduje, aby příjemce zprávy vždy naslouchal, aby byla zpráva doručena. Proto většina organizací využívá EDI poskytovatele, díky kterému bude příjemce vždy naslouchat. [23] 3. Výměna dat pomocí VAN (Value Added Network) operátora neboli síť s přidanou hodnotou nabízí mimo bezpečného přenosu dat také další služby. I když se v dnešní době velmi rozrůstají nízkonákladová EDI řešení, VAN sítě jsou stále oblíbeny díky přidané hodnotě (sledování a zaznamenávání zpráv, upozornění na příchozí zprávy, datové zálohy a obnovy a odstranění komplikací spojených s různými komunikačními protokoly). V případě EDI komunikace je to zaručení bezpečnosti přenosu nezkreslené informace. Proces výměny zpráv je podobný přímému spojení mezi jednotlivými subjekty, ovšem část provozu EDI přebírá operátor VAN. Operátor zajišťuje dodání konvertoru i komunikačního softwaru, který ovšem stále zůstává na straně klienta s čímž souvisí pořizovací náklady i náklady na správu. [15, 22] 4. EDI jako služba Tento případ EDI řešení je nejvhodnější pro malé a střední společnosti, protože eliminuje překážku zavádění složitého EDI systému, a tedy i poměr výkonu a ceny. Schéma této služby je podobné výměně zpráv přes VAN operátora, nicméně provozovatel EDI služeb přidává jako svoji hodnotu specializovaný software pro konverzi zpráv a jejich přenos. Díky této funkci se 16

17 nemusí klient zabývat obtížnou správou a aktualizací EDI systému, protože se o ni stará poskytovatel služby. Služby, které jsou poskytovány si můžeme prohlédnout na obrázku číslo 5. Díky této službě mají společnosti přístup k nejlepším technologiím a zkušené správě celého EDI, právě díky tomu, že společnost, která službu poskytuje, provozuje EDI řešení jako svou hlavní činnost. [26] Obr. č. 5 Schéma výměny zpráv prostřednictvím EDI poskytovatele Zdroj: 5. WebEDI Na rozdíl od předchozích způsobů, WebEDI využívá pro přenos dat běžný internetový prohlížeč a tím je ideální volbou pro malé a středně velké organizace, které EDI využívají pouze příležitostně. Díky WebEDI můžeme tou nejjednodušší a nejméně nákladnou formou vytvářet, zpracovávat a dostávat EDI dokumenty přímo ve svém prohlížeči. Hlavní nevýhodou této EDI komunikace je to, že není přímo integrovaná do podnikového informačního systému, a tedy neposkytuje největší výhodu EDI, a to automatické strojové zpracování dokladů. Je tedy stále potřeba lidské práce k tomu, aby se jednotlivé informace přepisovali z/do informačního systému ručně. [24, 25] Ukázku toho, jak vypadá WebEDI si můžeme prohlédnout na obrázku číslo 7. 17

18 Obr. č. 6 Příklad WebEDI Zdroj: [25] 6. Mobile EDI Na závěr si představíme tuto futuristickou formu EDI výměny zpráv, která je zatím ve fázi vývoje, nicméně v budoucnu by mohlo být možné stáhnout si do telefonu aplikaci, která bude umět komunikovat pomocí EDI a klient tak bude moci sledovat objednávky či odvolávky, aniž by seděl u počítače. [27] Typy EDI zpráv V rámci EDI komunikace bylo definováno mnoho druhů národních a oborových standardů, a to velmi omezovalo komunikaci mezi rozdílnými společnostmi, proto vznikl mezinárodní standard pro elektronický přenos dat UN/EDIFACT. Pro oblast obchodu hlavně se spotřebním zbožím byla vyvinuta ještě podmnožina EDIFACT EANCOM, který se využívá pro jasnou identifikaci zboží a služeb. [16] Tyto dvě normy tak společně tvoří mezioborové standardy pro komunikaci pomocí EDI. Jednotlivé dokumenty vyměňované pomocí EDI jsou pak reprezentovány různými zprávami. Pro představu, jaké zprávy jsou v EDIFACT využívány si uvedeme několik nejvíce používaných příkladů. [28] 18

19 PARTIN (Party Information/Informace o organizaci) - V podstatě první zpráva, která by měla být posílána v případě zahájení komunikace pomocí EDI. Obsahem této zprávy jsou základní data o organizaci (Global Location Number, adresa, kontaktní osoby a jiná data administrativních, obchodních či finančních charakterů). Pokud se některé z těchto údajů změní, tato zpráva se aktualizuje a odešle znovu. [29] ORDERS neboli objednávka je typ zprávy, kterou odesílá zákazník svému dodavateli, ve které objednává zboží nebo služby a dále udává specifikace, jako je množství, místo a termín dodání. [30] ORDERSP neboli potvrzení objednávky slouží jako odpověď na objednávku. V tomto typu zprávy dodavatel sděluje odběrateli, zda je schopen vyhovět jeho objednávce a informuje ho tedy o tom, co je a není schopný dodat, případě specifikuje jiné změny objednávky. [31] INVOICE neboli faktura slouží jako výzva k zaplacení za poskytnuté zboží či služby. Dodavatel může fakturovat více než jednu transakci. Většinou obsahuje informace o platebních podmínkách, dopravě a v případně zahraniční zásilky další různé informace pro celní či statistické účely. [32] RETANN neboli oznámení o vrácení zboží se využívá v případě, že chce odběratel vrátit zboží zpět (poškození, oprava) nebo bylo dodané zboží jiné, či mělo prošlou záruční lhůtu. [33] Struktura EDIFACT dokumentu Každý kousek informací v EDI dokumentu se nazývá datový element. Spojením těchto datových elementů do vyššího celku se nazývá datový segment. Datový segment tak může sdružovat více datových elementů popisujících například zboží (váha, množství, cena atd.). Spojením datových segmentů vzniká standardizovaná zpráva, ve které má každý datový element svoji přesnou pozici. [34] EDI segmenty - Aby byla data přehledně rozdělená, využívají se v EDI takzvané datové segmenty. Představme si je jako jednotlivé kolonky, které vyplňujeme do papírové faktury. V EDI segmentu má každá takováto kolonka označení, aby bylo přesně poznat, jaká informace se v daném segmentu skrývá. Každý segment začíná 19

20 úvodními třemi písmeny, které označují typ datového elementu. Tyto elementy jsou rozděleny pomocí + a každý segment končí apostrofem. Obr. č. 7 Edi segment Zdroj: Na obrázku číslo 7 si ukážeme, jak vypadá segmentovaná EDI zpráva objednávky. Stejně jako v případě jména formuláře u papírové formy má i EDI svůj úvodní segment. Ten se značí UNH a značí začátek zprávy, a hlavně také typ zprávy v tomto případě ORDERS neboli objednávku. BGM značí začátek přenosu informací. DTM ukazuje, kdy k objednávce došlo, a NAD popisuje toho, kdo objednávku udělal. LIN, QTY a PRI se zabývají přímo objednávkou a říkají nám o jaké předměty je zájem, kolik jich odběratel chce a také kolik za to zaplatí. UNT poté značí konec zprávy. [15, 35] 1.5 Konvertor a mapovací programy Konvertory si můžeme představit jako složitější datové filtry. Jejich úkolem je převést data z jednoho formátů do jiného tak, aby byl vstup stejný jako výstup. Konvertor pracuje na základě šablon, ve kterých jsou definovány oborové či národní subsety. Představme si, že máme dokument s objednávkou, který chceme pomocí šablony pro objednávky převést z jednoho formátu, například IDoc do formátu EDI. Mapovací programy slouží k vytváření jednotlivých šablon pro konvertor. Práci mapovacího programu si můžeme představit jako přiřazení identifikace určité položce, se kterou se bude dále pracovat. Poté se vytvoří subsety, které sdružují potřebné segmenty. [10] 20

21 1.6 EDI v různých průmyslech EDI mapuje různé podnikové procesy a průmyslové problémy díky čemuž se využívá v mnoha rozdílných odvětvích průmyslu. Během posledních čtyřiceti let se vyvinulo nespočet specifických typů dokumentu a komunikačních standardů pro různá odvětví. Vznikaly také průmyslové asociace a pracovní skupiny. Vytvořilo se tak mnoho soukromých sítí, aby se vyhovělo požadavkům různých průmyslových sektorů. [36] 1. Automobilový průmysl - EDI se v automobilovém průmyslu využívá už přes čtyřicet let. Výměna dat mezi výrobcem aut a jeho dodavateli umožňuje hladký průběh výroby, který stojí právě na výměně podnikových dokumentů. Spousta podnikových procesů, které se v dnešní době využívají v automobilovém průmyslu, byly vyvinuty v Toyotě v Japonsku. Mezi hlavní procesy se řadí Just-In-Time a Lean Manufacturing. Tyto dva procesy jsou klíčové pro běh mnoha výrobních linek po světě a díky EDI, které umožňuje rychle a efektivně vyměňovat informace mezi výrobcem a dodavatelem zajišťuje jejich maximální funkčnost. Možnost vidět množství zásob a upozornění na dobu, kdy přijde objednávka jsou klíčové pro efektivní práci s JIT a Lean Production. Vzhledem k tomu, že automobilový průmysl je rozšířen po celém světě, je velmi důležité, aby nebylo EDI moc složité a mohl tak s výrobcem elektronicky komunikovat i ten nejmenší dodavatel. Automobilový průmysl je velmi složitý. V autech nalezneme přibližně součástek, a pokud by i jen jediná chyběla, zastaví se celý proces výroby. Proto má automobilový průmysl rozdělenou strukturu dodavatelského řetězce do několika úrovní, jak ukazuje obrázek číslo 9. Na první úrovni se nachází společnosti, které nabízejí největší a nejdůležitější komponenty pro výrobu aut, jako jsou převodovky, motory a jiné. Tito dodavatelé jsou pro výrobce aut velmi důležití, a proto se nacházejí v blízkosti výrobní linky, aby mohli pružně reagovat na JIT. Na druhé úrovni jsou poté dodavatelé pro výrobce na úrovni jedna, kteří jim dodávají součástky potřebné pro výrobu, například různé písty, které jsou součástí motorů. Následují ještě další úrovně, které zásobují dodavatele druhé třídy od různých držáků, těsnění až po různé opracované komponenty. Tito dodavatelé jsou rozmístěni všude po světě, většinou však v zemích s levnou pracovní silou, jako je Čína či Indie. Po samotném smontování jsou automobily distribuovány dealerům po 21

22 celém světě. Celý dodavatelský řetězec se skládá až z tisíce dodavatelů, a proto je velmi důležité mít ve společnosti zavedený funkční EDI systém. Obr. č. 8 Dodavatelský řetězec v automobilovém průmyslu Zdroj: Jako hlavní standard EDI dokumentů se využívají ANSI X12 a EDIFACT, nicméně se časem vyvinuly další regionální standardy používané výrobci automobilů v Evropě. Například ve Francii se užívá ODETTE a VDA v Německu. [37] 2. Finančnictví - Podniky poskytující finanční služby a produkty jako bankovnictví, bezpečnost, platební karty, pojištění a různé obchodní služby jsou velmi závislé na schopnosti zpracovávat obrovská kvanta informací a také jejich bezpečnost. Další problémy vznikají ve chvíli, kdy se začíná pracovat na zahraniční úrovni kvůli různé měně, regulacím a účetnickým praktikám. Po dlouho dobu byly tyto procesy řízeny manuálně a papírově, nicméně díky EDI se podařilo zautomatizovat některé z těchto procesů a funkcí. EDI řeší tyto problémy tak, že řadí finanční informační tok k pohybu fyzického zboží, což můžeme vidět na obrázku níže. Díky EDI může 22

23 organizace dostat fakturu a ihned ji zaplatit. Mezi hlavní standardy EDI dokumentů se tradičně využívají ANSI X12 a EDIFACT, ale také jiné populární standardy pro správu peněz a bezpečnost jako ISO XML, NACHA, BAI2, SAP IDoc, SWIFT. V mezinárodním bankovnictví a komunikací mezi bankami se nejvíce využívá SWIFT, který byl vytvořen pro potřeby výměny dat mezi finančními institucemi a je rozdělen na čtyři části: výplaty, obchodní služby, bezpečnost a obchodování. [38] Obr. č. 9 Dodavatelský řetězec ve finančnictví Zdroj: 3. High Tech průmysl - High Tech je označení nejpokročilejší technologie 21. století, tyto produkty mají ve většině případů jako svoji součást velmi výkonné počítače. A protože dodavatelský řetězec v tomto odvětví je velmi složitý kvůli závislosti na množství partnerů, kteří pomáhají s designem a výrobou produktu, je velmi důležité využívat EDI k výměně dokumentů více než v jiných odvětvích. 23

24 Toto odvětví je také velmi závislé na zákazníkovi, a proto musí být řetězec velmi flexibilní, aby mohl reflektovat požadavky odběratele. Stejně jako v případě automobilového průmyslu i tady využívají společnosti výhody nízké pracovní síly jiných zemí, a to ještě násobí důležitost funkčního, jednoduchého a rychle implementovatelného EDI systému. Dodavatelský řetězec zobrazený na obrázku číslo 10 je v tomto případě ten nejsložitější ze všech průmyslů z důvodu velké závislosti na outsourcování a výrobě. Jako příklad si uvedeme Cisco, jednoho z největších poskytovatelů síťových řešení, který si nechává všechna svá zařízení vyrábět cizími dodavateli. Na dodavatelské straně vidíme společnosti, které od samotného materiálu vytvoří finální produkt, který pošlou do společnosti, která si k němu přidá svoje logo. Následně jsou tyto produkty poslány speciálním distributorům, které je přepošlou obchodníkům, kde, již mohou být prodány finálnímu zákazníkovi. [39] Obr. č. 10 Dodavatelský řetězec High Tech průmyslu Zdroj: 24

25 Pro kvalitní výměnu složitých dokumentů a rychle se měnící poptávku a nabídku je kritické mít efektivně zavedený EDI systém, který bude schopen zvládnout obrovské množství dat putujících od výrobců a dalších partnerů. Mimo tradičně zavedené ANSI X12 a EDIFACT standardy se v High Tech průmyslu úspěšně vytvořili standardy postavené na XML. Dále se ještě hojně využívá OAGIS (Open Applications Group Integration Specification), který využívá XML k definování podnikových zpráv a identifikování podnikových procesů, což umožňuje komunikaci mezi společnostmi. OAGIS obsahuje největší set podnikových zpráv pro výměnu dat. [39] 4. EDI v maloobchodu - EDI v maloobchodu se snaží o co největší zefektivnění a zeštíhlení organizace tím, že se nahrazují papírové dokumenty těmi elektronickými. Na základě výzkumu z roku 2010, který nechala provést společnost GS1 můžeme vidět, že 84 % podniků, kde se využívá EDI ušetřili až 650 milionů liber každý rok. [14] Dodavatelský řetězec u maloobchodu je vcelku unikátní díky tomu, že je řízen tokem daného produktu. Rychlá a nejistá změna poptávky a důraz na dostupnost zboží jsou dále umocněny zbožím, které se může zničit. V maloobchodu se využívá několik druhé EDI standardů. Tradacoms je již nepoužívaný standard, který byl nahrazen standardem EDIFACT, nicméně některé společnosti ho stále používají, z důvodu nedokonalé informovanosti o lepším řešení. Asociace Voluntary Inter-industry Commerce Solutions (VICS) pracovala na zvýšení efektivnosti a účelnosti v maloobchodu a vedla zavedení Quick Response (QR) standardů ke zlepšení produktového a informačního toku pro maloobchodníky a dodavatele. ecom je skupinou standardů která cílí na běžné standardy používané v dodavatelském řetězci maloobchodu. Většina těchto standardů je postavena na EDI, nicméně vzniká nová generace XML ecom standardů, která není ovšem zatím tak oblíbená. [40] 1.7 Výhody zavádění a implementace EDI Ač to může připadat v dnešní době zvláštní, většina firem stále zpracovává své doklady manuálně, pomocí lidských zdrojů, které s sebou samozřejmě nesou řadu příležitostných a provozních nákladů, nákladů na nákup papíru, tisk, prodlení, nebo jiné 25

26 uživatelské chyby. [41] EDI většinu těchto nákladů eliminuje a dává tak uživateli možnost soustředit se na důležitější části svého podniku. Hlavní výhody zavedení EDI ve firmě a jeho výhod pro dodavatele a odběratele si uvedeme v následujících tabulkách. Tabulka 1 Výhody zavedení EDI Před zavedením EDI Obchodní dokument je vytištěn a odeslán (většinou v rozmezí 3-5 dnů) Obchodní informace na papíře jsou analyzovány a kontrolovány lidmi Příjemce dokladu musí ručně přepsat data z dokladu do počítače Informace slouží pro jistý předem vymezený okruh problémů, a to většinou pouze v aplikaci, do kterou jsou ručně vloženy Po zavedení EDI Informace jsou přeneseny mezi dvěma výpočetními systémy okamžitě, nebo během několika minut Informace je zpracována počítačovou aplikací a lidé vstupují do tohoto procesu pouze ve výjimečných případech Informace jsou přímo zaneseny do obchodní aplikace příjemce, bez jakéhokoliv zásahu zaměstnance Použití informace je omezeno pouze jejím obsahem, většinou slouží více aplikacím. Zdroj: [10] Tabulka 2 Přínosy zavedení EDI pro odběratele a dodavatele Přínosy EDI pro dodavatele EDI pro odběratele Nákup Finance vyšší dostupnost prostředků, díky průhlednějšímu řízení cash-flow úspora tisku, poštovného a práce zaměstnanců zlepšení řízení cash-flow díky neustálému přehledu, co se s vystavenou fakturou děje (jestli ji zákazník přijal 26 snížení času a chybovosti objednávání díky přesné identifikaci zboží a cen úspora nákladů díky sjednocení faktur od dodavatelů a jejich strojovému automatickému zpracování až do podnikového informačního

27 atd.) archivace faktur dle platné legislativy (papír již není potřeba, snadné dohledání dokladů) systému. úspora času díky automatické kontrole/párování dokladů (např. porovnání objednávky, příjemky a faktury) archivace faktur dle platné legislativy (papír již není potřeba, snadné dohledání dokladů) Rychlejší identifikace a řešení cenových a množstevních rozdílů na fakturách. Možnost automatické eskalace řešení rozdílů na dodavatele. Možnost automatizace zpracování logistických a cenových opravných daňových dokladů. IT úspora pracnosti díky jedinému datovému formátu pro každý typ dokladu (objednávka, faktura) pro všechny zákazníky (EDI dnes v retailu využívá většina obchodních řetězců) Obchod úspora času a snížení chybovosti při objednávání úspora pracnosti díky jedinému datovému formátu pro každý typ dokladu (objednávka, faktura) pro všechny zákazníky snížení výpadků zboží na 27

28 zboží zákazníkem díky přesné identifikaci zboží a cen prodejních místech nižší četnost opravných daňových dokladů zlepšení vztahů se zákazníky Logistika efektivnější využití dopravních kapacit (v případě vlastního vozového parku) díky rychlejší vykládce zboží na skladech zákazníka Ostatní transparentnost celého obchodního a logistického procesu okamžitý přehled o stavu jednotlivých dokladů díky možnosti trasovat jednotlivé zprávy v zabezpečených sítích urychlení příjmu zboží díky položkové avizaci dodání možnost rychlého odbavení celých palet při využití SSCC kódů transparentnost celého obchodního a logistického procesu okamžitý přehled o stavu jednotlivých dokladů díky možnosti trasovat jednotlivé zprávy v zabezpečených sítích Zdroj: [41] Motivy pro zavádění EDI jsou ve velkých odběratelských společnostech povětšinou jasné, tyto společnosti obchodují se stovkami dodavatelů a musejí tak odesílat a přijímat obrovská kvanta dokladů denně. Menší společnosti jsou většinou motivováni tím, že chtějí vyjít vstříc svému významnému odběrateli, protože mnohé řetězce si jako jednu z podmínek spolupráce kladou právě používání EDI. Naštěstí se na to již část těchto menších společností dívá z lepší stránky a prohlašuje, že pokud již mají zavést EDI, tak ať jim alespoň zefektivní a zkvalitní procesy ve firmě. [42] Světový průzkum IDC Manufacturing Insights 2013 mimo jiné pokládal otázku: Co bylo hlavním impulzem investic do vylepšení B2B integrace s obchodními partnery pomocí zavedení EDI ve vaší společnosti? Ten ukázal, že opravdu ve většině případů vedlo společnost 28

29 k zavedení EDI požadavek zákazníka a to z 64 %. 48 % firem uvedlo, že EDI zaváděly hlavně kvůli návratnosti z investice. V českých krajích je dokonce ještě více firem, které spíše, než z důvodu návratnosti investice zavádějí EDI právě z důvodu podmínek či tlaku zákazníka. [43] Na obrázku číslo 12 můžeme vidět graf důvodů pro zavedení EDI ve firmách. Obr. č. 11 Důvody pro zavedeni EDI ve firmách Zdroj: [42] 1.8 Implementace EDI Implementace EDI řešení ve společnosti nebo síti obchodních partnerů je velmi komplexní proces, který si klade systematický přístup k jeho řešení. Tento proces bychom mohli rozdělit do několika bodů. 1. Seznámení s EDI - Cílem prvního bodu je získat představu o tom, co je nám EDI schopné nabídnout a zdali je vhodné ho nechat u sebe ve společnosti zavést. 2. Analýza podniku a jeho procesů - Analýza podniku má za úkol získat stávající data o společnosti a z nich pak vytvořit dokument, popisující stav podniku, jehož výstupem je informace o tom, zdali je podnik připravený na přechod na EDI. V potaz bychom měli vzít počet dodavatelů a zákazníků, nebo jiných obchodních partnerů, množství a typ zpráv, které se přenášejí a v neposlední řadě také vysvětlení toho, jak je EDI schopné podnik vylepšit. 3. Výběr vhodného EDI řešení a poskytovatele - Výběr řešení a poskytovatele EDI by měl být zaměřen především na požadavky podniku nežli na technickou schopnost 29

30 poskytovatele. Zamyslet bychom se tedy měli nad tím, jaké přesně EDI řešení po poskytovateli chceme (klasické EDI, WebEDI, EDI jako služba). Součástí tohoto bodu je také seznámení se s poskytovatelem, jeho zkušenostmi, ceníkem, službami a jeho historií. Tento bod je někdy ve velkých společnostech realizován jako výběrové řízení. 4. Integrace s podnikovým systémem - Nejobtížnější krok v implementaci EDI je právě integrace s podnikovým systémem. Po zakoupení potřebného hardwaru, softwaru a zajištění dobrého internetového připojení je nejdůležitějším krokem integrace EDI do vlastního in-house ERP systému. Tento krok vyžaduje dokonalou znalost EDI standardů, in-house ERP a komunikačních protokolů. Dále je třeba vytvořit systém mapování zpráv, a nakonec nainstalovat a nakonfigurovat komunikační software pro odesílání a příjem zpráv. Tento bod je také velmi komplikován množstvím obchodních partnerů, kdy každý z nich má svoje vlastní požadavky a využívá jiné EDI řešení. 5. Zajištění identifikačního čísla společnosti GLN (Global Location Number) - Toto číslo je součástí GS1 systémových standardů a slouží k jednoduché identifikaci polohy zboží. Můžeme tedy zjistit, že se zboží nachází ve skladu v České Republice. V České Republice toto číslo přiděluje sdružení GS1 Czech Republic. V podstatě se jedná o nám známý EAN kód a tedy výrobci, kteří ho již používají si nemusejí zajišťovat GLN. 6. Testování - V tomto kroku je třeba ověřit, zdali jsou data úplná, správná a odpovídají předepsaným segmentům. Nesmíme opomenout vyzkoušení konvertoru zpráv na obou stranách, kde se EDI implementuje, aby se zamezilo pozdějším problémům. 7. Samotná implementace a testování reálného provozu - Po nasazení EDI do společnosti přichází řada na jeho ostrý test, kdy se už posílají reálné dokumenty, ovšem s duplicitními dokumenty odesílanými například em nebo faxem pro kontrolu správnosti dat. V neposlední řadě je také třeba zhodnotit testovací provoz a v případě nějakých nedostatků upravit samotné EDI řešení. Po úspěšném zavedení a otestování na reálných zprávách dochází k podpisu smlouvy mezi oběma stranami. 8. Ostrý provoz výměny EDI zpráv 30

31 1.9 XML a XSL jazyky Pro potřeby této bakalářské práce je jistě třeba si představit jazyky XML a XSL XML XML (extensible Markup Langugage rozšiřitelný značkovací jazyk) je formát dokumentů, který nám říká, jak zapsat data společně s jejich významem. Je univerzálním formátem dat, protože je to velmi jednoduchý, rozšiřitelný a otevřený formát vyvinutý konsorciem W3C. Využívá se především pro výměnu dat mezi různými aplikacemi, publikování dokumentů nebo právě k transformaci do jiných typů dokumentů či XML aplikací. Mezi výhody jazyka XML řadíme mimo jiné jeho otevřenost. Není svázán s žádnou platformou, nebo technologií, může být tedy otevřen a zpracován v libovolném textovém editoru. XML není omezen pouze angličtinou a ve výchozím nastavení si rozumí i s mnoha neobvyklými jazyky a druhy kódování. Jedinou podmínkou je, že musí být v každém dokumentu specifikováno, o jaký jazyk případně kódování se jedná. [48] Syntaxe XML dokumentu Každý XML dokument začíná deklarací XML, která musí představovat první řádku dokumentu. Standardně obsahuje určení verze XML a použité kódování. <?xml version="1.0" encoding="utf-8"?> Každý XML dokument se skládá z elementů, které se do sebe navzájem vnořují. V textu je můžeme poznat podle takzvaných párových tagů. Párových, protože každý element musí mít svůj počáteční a ukončovací tag. <priklad>tohle je element s názvem priklad</priklad> Výjimkou jsou elementy, které nemají žádný obsah, ty se mohou ukončit tak, že se za jméno tagu uvede znak lomítka /. <priklad2>tohle je element<br/>na dvou řádcích</priklad2> Každý element může ve svém počátečním tagu obsahovat neomezený počet atributů, které se používají k dalšímu upřesnění obsahu daného elementu. Hodnota atributů by vždy měla být uzavřena v uvozovkách. 31

32 <priklad slozitost= jednoduchy >Tento příklad je jednoduchý.</priklad> V případě že bychom v elementu chtěli použít znak, který se využívá k syntaxi, musíme použít takzvané znakové entity, které dané znaky nahradí. Pro < použijeme < a pro > použijeme >. Ampersand & se pak zapisuje pomocí & <priklad>je 5>8 pravda?</priklad> <priklad2>pekárna Otec &amp Syn</priklad2> Každý XML dokument musí být celý obalen v jednom kořenovém elementu. Pro jednoduchý příklad, jak by měl vypadat správně naformátovaný XML dokument si uvedeme pracovní postup k pečení chleba. [48] <?xml version="1.0" encoding="utf-8"?> <!-- Poznámka verze XML a kódování. --> <recept jméno="chleba" čas_přípravy="5 minut" čas_vaření="3 hodiny"> <titulek>jednoduchý chleba</titulek> <přísada množství="3" jednotka="šálky">mouka</přísada> <přísada množství="0,25" jednotka="unce">kvasnice</přísada> <přísada množství="1,5" jednotka="šálku">horká voda</přísada> <přísada množství="1" jednotka="kávová lžička">sůl</přísada> <postup> <krok>smíchejte všechny přísady dohromady a dobře prohněťte.</krok> <krok>zakryjte tkaninou a nechejte hodinu v teplé místnosti.</krok> <krok>znovu prohněťte, umístěte na plech a pečte v troubě.</krok> </postup> </recept> XSL extensible Stylesheet Language (rozšiřitelný stylový jazyk) je souborem jazyků, které nám umožňují popsat, jak se formátují a převádějí jednotlivé XML soubory. Převod vstupního XML dokumentu můžeme vidět na obrázku číslo

33 Obr. č. 12 Princip práce s XSL styly Zdroj: XML jako takové můžeme rozdělit na tři části. XSL-FO XSL formátovací objekty slouží k přesnému popisu vzhledu dokumentu XPath slouží k adresování částí XML dokumentů a umožňuje s nimi tak dále pracovat XSLT XSL transformace sloužící k převádění XML jazyka do XML dokumentů [48] XPath Abychom mohli pracovat s XSLT je třeba být obeznámen s jazykem XPath. XPath jsou doporučení od konsorcia W3C, která se používají k popisování elementů, atributů, textu a uzlů používaných v XML dokumentech. V XSLT se XPath používá pro vyhledávání uzlů ve zdrojovém dokumentu, které pak pomocí šablon přenese na výstup. V zápisu XPath můžeme používat mnoho výrazů, funkcí a operátorů k nalezení námi požadovaného vstupu či výstupu. [48] XSLT XSLT je jazyk, který slouží k převodům zdrojových XML do jiných požadovaných formátů, nejčastěji jsou to HTML nebo jiné XML soubory. 33

34 Protože XSLT využívá pro svůj zápis syntaxi XML je nutné ji na začátku dokumentu deklarovat, stejně jako u běžného XML dokumentu. Dále se v XSLT dokumentech využívá jmenného prostoru xsl, který je celý obalen v jednom elementu a měl by být definován hned pod deklarací XML. <xsl:stylesheet xmlns:xsl=" version="1.0"> </xsl:stylesheet> [48] XSL šablony Nejdůležitější pro transformaci pomocí XSLT jsou šablony, které určují dvě důležité věci a to, co dělat v případě, že naleznu hledaný uzel a jak bude transformován do výstupního dokumentu. V samotném těle šablony pak můžeme používat další XSLT konstrukce či přímo elementy z výsledného dokumentu jako jsou například HTML tagy. Tabulka 3 XSL šablony <xsl:template match="krestni"> Hurá, našel jsem křestní jméno! </xsl:template> <osoba> <jméno> <krestni>pavel</krestni> </jméno> </osoba> Zdroj: Vlastní zpracování Atribut match nám tedy říká, že kdykoliv najdu uzel krestni, tak vypíšu tělo šablony. V tomto případě bude výstupem Hurá, našel jsem křestní jméno! Pro výběr elementů se používá atribut match, jehož výrazem je cesta k uzlu zapsaná pomocí jazyku XPath. [48] XSLT elementy V následujících odstavcích si představíme některé z XSLT elementů použitých v praktické části bakalářské práce. XSLT value-of - Pro vygenerování jednotlivých částí textu na základě XPath výrazů používáme instrukci value-of. Ta nalezne hodnotu, kterou převede na textový řetězec a vypíše ji do daného elementu. 34

35 Tabulka 4 XSLT value-of <xsl:template match="krestni"> Našel jsem jméno a jeho hodnota je <xsl:value-of select="."/> </xsl:template> <osoba> <jméno> <krestni>pavel</krestni> </jméno> </osoba> Zdroj: Vlastní zpracování Atribut select nalezne pomocí XPath uzel a na výstup vloží jeho hodnotu. Tečka (.) použitá v příkladu odkazuje na sebe sama, a výstupem tedy bude Našel jsem jméno a jeho hodnota je Pavel. [48] XSLT apply-templates - Vzhledem k tomu, že většina dokumentů obsahuje vícero šablon používá se tag xsl:apply-templates, který říká XSLT procesoru, že by měl hledat dále v XML souboru a v každém kroku zkontrolovat, zdali není v XSLT dokumentu nějaká šablona splňující podmínku match. Pro vysvětlení apply-templates použijeme trochu delší příklad využívající vícero šablon. Tabulka 5 XSL apply-templates. <xsl:template match="jméno"> <xsl:apply-templates select="/osoba/jméno/krestni"/> <xsl:applytemplates select="/osoba/jméno/prijmeni"/> </body> </html> </xsl:template> <osoba> <jméno> <krestni>pavel</krestni> <prijmeni>novák</prijmeni> </jméno> </osoba> <xsl:template match= krestni"> Našel jsem křestní jméno a jeho hodnota je <xsl:value-of select="."/> </xsl:template> <xsl:template match= prijmeni"> Našel jsem příjmení a jeho hodnota je <xsl:value-of select="."/> </xsl:template> Zdroj: Vlastní zpracování 35

36 Kdykoliv narazím ve vstupním dokumentu na uzel jméno, aplikuji šablony krestni a prijmeni, které jsou dále definované v XSL dokumentu. Výstupem tohoto příkladu potom bude Našel jsem křestní jméno a jeho hodnota je Pavel Našel jsem příjmení a jeho hodnota je Novák [48, 49] XSLT for-each - Pro použití cyklu v XSLT můžeme využít tag for-each. Ten pomocí atributu select najde hledaný uzel a pro každou jeho instanci vypíše daný obsah. Tabulka 6 XSLT for-each <xsl:for-each select="osoba/jméno"> <xsl:value-of select="krestni" /> <xsl:value-of select="prijmeni" /> </xsl:for-each> <osoba> <jméno> <krestni>pavel</krestni> <prijmeni>novák</prijmeni> </jméno> <jméno> <krestni>petr</krestni> <prijmeni>novotný</prijmeni> </jméno> </osoba> Zdroj: Vlastní zpracování V tomto případě kdykoliv nalezneme element jméno vypíšeme pro každou jeho instanci obsah uzlů krestni a prijmeni. Výstupem tedy bude Pavel Novák Petr Novotný. [48, 49] XSLT if - Tag if se používá v případě, kdy chceme otestovat, zdali je splněna nějaká podmínka. Tabulka 7 XSLT if <xsl:if test="10 > 6"> <xsl:value-of select="krestni"/> </xsl:if> <osoba> <jméno> <krestni>pavel</krestni> <prijmeni>novák</prijmeni> </jméno> </osoba> Zdroj: Vlastní zpracování Pokud platí, že 10> 6, tak se vypíše hodnota uzlu krestni. Tedy v našem případě bude výstupem Pavel. 36

37 XSLT choose - Pro komplexnější podmínky, a tedy testování vícero výrazů se používá tag choose, when a otherwise. Tabulka 8 XSLT choose <xsl:choose> <xsl:when test="cena > 5 "> <xsl:value-of select="cena"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="rok"/> </xsl:otherwise> </xsl:choose> <cd> <cena>9.90</cena> <rok>1988</rok> </cd> Zdroj: Vlastní zpracování V příkladu testujeme, zdali je cena vyšší než 5, pokud je podmínka splněna, vypíše nám na výstup její hodnotu, pokud ovšem podmínka splněná není, vypíše nám na výstup rok vydání CD Představení společnosti AIMTEC a.s. Tato bakalářská práce byla vypracována ve spolupráci s plzeňskou společností AIMTEC a.s., jejímž cílem je pomáhat průmyslu stát se digitálním. Hlavní náplní společnosti je vývoj, implementace a poradenství v oblasti informačních systémů se zaměřením hlavně na automobilový průmysl, který tvoří až 41 % obratu společnosti. Společnost pracuje v oboru již přes 20 a za tu dobu se naučila naslouchat potřebám lidí z provozu a ladit projekty s managementem na strategické úrovni. Společnost pracuje pro zákazníky po celém světě, v různých kulturách a s rozličnými přístupy k řízení. Většinu zákazníků společnosti tvoří zahraniční klienti, primárně němečtí. Překvapujícím faktem je to, že společnost má své zákazníky i v Japonsku nebo třeba USA. Roční obrat společnosti za rok 2016 přesáhl hranici 245 milionů korun a stejně jako roční obrat roste i počet zaměstnanců, který v roce 2016 dosáhl počtu Vznik tématu práce Společnost AIMTEC podporuje studentské vzdělání a ve spolupráci se Západočeskou univerzitou nabízí v semestru spoustu zajímavých činností a projektů, do kterých se mohou studenti zapojit. Autor práce tak využil hned několika nabídek na spolupráci 37

38 s touto společností a získal tak zkušenosti z oblasti EDI, Warehouse management systémů, práci v týmu na hře ve virtuální realitě a následně pak i z povinné školní praxe. Díky těmto zkušenostem a autorovým rostoucím zájmem o technologii EDI, ve které vidí budoucnost komunikace, která by se v České republice měla mnohem více implementovat se autor práce společně se zaměstnanci firmy AIMTEC, s panem Ing. Lukášem Rampou a panem Ing. Vlastimilem Šilhánem dohodli na rozšíření předchozí spolupráce s konverzí EDI zpráv a na jejím rozšíření do práce bakalářské obohacenou o výběr nejvhodnějšího EDI řešení pro fiktivní společnost a jeho následnou implementaci. 2 Metodika práce 2.1 Použitý software Součástí práce je potřeba číst jednotlivé EDI zprávy v různých formátech, které se pak převádějí do značkovacího jazyka XML. Pro práci s tímto jazykem je možno využít různé druhy softwaru od toho nejběžnějšího NotePadu, který se nachází v každé verzi operačního systému až po ty specializované pro práci s XML. Vzhledem k tomu, že autor práce není zaměstnancem společnosti, bylo potřeba nalézt takový software, který umožňuje kvalitní práci s různými programovacími jazyky a je zároveň zdarma k využití. Během psaní práce vyzkoušel autor několik druhů softwaru a některé z nich představí na následujících řádkách OxygenXML Editor OxygenXML Editor je multi-platformní javovská aplikace, která umožňuje pracovat s XML a XSL soubory a jako taková je nejvhodnější pro konverzi EDI zpráv. Hlavní výhodou tohoto editoru je okamžitá validace XML souboru, podpora různých XML standardů a dokumentů, XSLT debugger, který slouží k jednoduchému nalezení problémů, které se mohou v dokumentech vyskytnout, a hlavně zabudovaný kompilátor, který umožňuje mapování vstupních XML souborů pomocí XSL souborů na jiné, výstupní XML soubory. Hlavní nevýhodou pro autora práce bylo to, že verze zdarma byla dostupná pouze na 30 dní, a tedy nebyla úplně vhodným řešením pro práci s XML. 38

39 2.1.2 Atom Atom je taktéž multi-platformní open-source textový editor, vytvořený společností GitHub Inc. Atom v základu podporuje spoustu programovacích jazyků a díky tomu, že je open-source umožňuje tak uživatelům vytvářet a sdílet své vlastní balíčky, které přinášejí další nové funkcionality. Pro cíle této práce autor využil několik balíčků pro zpracování XML a XSL souborů. Další velkou výhodou Atomu je jeho chytré doplňování kódu a dobře propracovaný prohlížeč souborů, který umožňuje pracovat s celými projekty, které pak může otevřít v několika panelech na obrazovce. Interface editoru Atom si můžeme prohlédnout na obrázku číslo 13. Obr. č. 13 Interface editoru Atom Zdroj: Vlastní zpracování XSL Transformer Protože editor, který autor nakonec využíval pro svoji práci neobsahoval ve svém základu XSLT konvertor využíval autor pro tuto konverzi ještě externí webový transformer XSL Transformer, jež můžeme vidět na obrázku číslo

40 Obr. č. 14 Interface softwaru XSL Transformer Zdroj: Vlastní zpracování. Tento transformer má velmi jednoduché a uživatelsky příjemné prostředí, které umožňuje vkládat XML a XSL soubory pomocí funkce Kopírovat-Vložit nebo přímo nahráním souboru na web. Následně po stisknutí tlačítka Transform se provede transformace a stránka nám ukáže výstupní soubor. XSLT procesor použitý v tomto transformeru je open source SAXON-HE verze 9.8. Tato verze poskytuje možnost pracovat s XSLT verze 3.0 a XPath verze 2.0 na základní úrovni s pravidly danými konsorciem W3C. Díky tomu, že je transformer dostupný v prohlížeči, není třeba ke konverzi žádného dalšího softwaru. 2.2 Proces výměny zpráv Proces výměny zpráv probíhá ve třech základních krocích, které jsou nezbytné k tomu, aby byla zpráva doručena včas a ve správném formátu. Získávání vstupních dat 40

41 Konverze dat Odeslání dat 2.3 Získávání vstupních dat Prvním krokem je sesbírat a zorganizovat jednotlivá data, která chceme odesílat. Místo toho, abychom tiskli objednávky, vytvoří informační systém elektronický soubor s nezbytnými informacemi pro tvorbu EDI dokumentu. Pro elektronickou výměnu dat potřebujeme získat vstupní surová tzv. in-house či EDI data z informačního systému společnosti. Těchto druhů dat je několik a liší se na základě toho, jaký informační systém klient využívá. Protože rozdíly v těchto vstupních formátech jsou obrovské poukážeme si na jejich základní odlišnosti. 1. IDoc - IDoc je dokument ze SAP využívaný pro přenos elektronických dat. Ukázku prostředí informačního systému SAP si můžeme prohlédnout na obrázku číslo 15. Struktura IDoc je složena z kontrolních záznamů, které obsahují informace o typu dokumentu, verzi SAP a jeho uživateli. Dále pak obsahuje záznamy o jednotlivých datových segmentech, a nakonec záznamy o stavu například úspěšném vytvoření či doručení zprávy. Obr. č. 15 Ukázka SAP Zdroj: Segmenty v IDocu obsahují data, která jsou poslána nebo obdržena od jednotlivých obchodních partnerů. Segmenty v IDocu se dělí na typ Parent a 41

42 Child. V případě, že má typ Parent pod sebou nějaké další segmenty, nazývají se Child. Příklad větvené struktury IDoc dokumentu můžeme vidět na obrázku číslo 16. Obr. č. 16 Parent a Child segmenty v IDoc zprávě Zdroj: 1https://blogs.sap.com/2012/12/31/idoc-basics-for-functional-consultants/ IDoc je ve své surové formě velmi nečitelným standardem a proto si ukážeme a popíšeme jen velmi krátkou část zprávy. Tabulka 9 Příklad anonymizované IDoc zprávy EDI_DC XDELFOR02 D04A RDELINSNDPOR KU LS RECIPIENT DELFOR02 E2EDK S E2EDKA1 LF ABC123LF Name 1 LF Street LF City 1 LF RO E2EDKA1 AG ABC123AG XYZ123AG Name 1 AG Street AG City 1 AG HU E2EDKA1 WE ABC123WE Name 1 WE 42

43 Street WE SK City 1 WE E2EDKA1 AB ABC123AB E2EDP BJ Material description text PCECUSPLNT MLC UNLPT S Zdroj: AIMTEC a.s. Struktura IDoc dokumentů se dělí na kontrolní, datové a stavové záznamy. Každý z těchto záznamů je uložen ve své vlastní tabulce v SAP. Kontrolní záznamy (EDI_DC) obsahují informace jako číslo IDoc dokumentu, typ zprávy, informace o obchodních partnerech, datu a času vytvoření či aktualizování zprávy. Datové záznamy obsahují jednotlivá data uložená v IDoc segmentech potřebná k přenosu daných dokumentů. Stavové záznamy definují procesní stav IDoc dokumentu, slouží především ke sledování stavu odesílání dat. [44] 2. UN/EDIFACT United Nations/Electronic Data Interchange for Administration, Commerce and Transport je mezinárodním EDI standardem navržený mezivládní organizací Spojených Národů. Velké množství elektronické výměny dat probíhá právě díky tomuto standardu. Na rozdíl od ostatních standardů je zpráva z EDIFACTU mnohem lépe čitelná, protože se skládá ze segmentů, jež mají své pevně dané tří písmenné jméno a ve své nejběžnější formě jsou jednotlivé segmenty odděleny apostrofem, čímž může být celá zpráva na jednom řádku. Dále je každý segment složen z menších elementů, které nesou daná data. Těchto elementů se může v řádku nalézt vícero. Ve zprávě můžeme naleznout několik druhů oddělovačů a informačních znaků, každý má svojí specifickou funkci a neměl by být vynechán. Pro jednodušší představu, jak taková zpráva UN/EDIFACT vypadá si uvedeme jednoduchý příklad, který si popíšeme. 43

44 Tabulka 10 Příklad UN/EDIFACT zprávy UNA:+.?' UNB+UNOC:3+UNBSENDER::AHM+UNBRECEIVER : ' UNH+1+DELFOR:D:04A:UN:GAVB11' BGM+241:::DOCNAME ' DTM+137: :102' DTM+2' FTX+AAI+++Free text AAI 1' NAD+BY+BYID::92++BY NAME 1+BY STREET 1+BY CITY++BY ZIP+BYC' NAD+SE+SEID::92++SE NAME 1+SE STREET 1+SE CITY++SE ZIP+SEC' RFF+ANK:ANK_REF' NAD+SF+SFID::92++SF NAME 1+SF STREET 1+SF CITY++SF ZIP+SFC' RFF+ANK:ANK_REFUNT+13+1' QTY+113:1008:PCE' DTM+2: :102' QTY+113:1152:PCE' DTM+2: :102' QTY+113:2016:PCE' DTM+2: :102' QTY+113:720:PCE' DTM+2: :102' QTY+113:720:PCE' DTM+2: :102' QTY+113:0:PCE' UNT UNZ+1+1' Zdroj: Vlastní zpracování dle materiálů poskytnutých společností AIMTEC a.s. Segment UNA není povinný, ale v případě jeho začlenění se využívá k tomu, aby specifikoval, jaké speciální znaky budou použity k další interpretaci zprávy. S výjimkou tečky jsou všechny znaky uvedené v segmentu UNA využívané standardně. Nejdůležitějším znakem je plus +, které slouží jako oddělovač jednotlivých elementů takzvané první úrovně. V případě, že některý element není ve zprávě použit se znaménko plus nesmí vynechat, může se tedy stát, že bude řádek obsahovat vícero znaků plus za sebou. Jediná výjimka je v případě posledního elementu, kde se plus uvádět nemusí, ale celý řádek se zakončí znakem jednoduchého apostrofu. K oddělení jednotlivých dat zanořených v elementu neboli elementů druhé úrovně se využívá dvojtečka :. V případě, že ve zprávě potřebujeme využít znak, který má svoji funkci můžeme před něj napsat otazník? a dané funkce ho tak zbavit. Mezera _ slouží k rezervování pozice a tečka., slouží k označení desetinného místa. Segment UNB je povinný a obsahuje informace o odesílateli a příjemci dané zprávy, čas, datum a označení transakce. 44

45 Segment UNH je taktéž povinný a obsahuje dva povinné elementy s informacemi o referenčním čísle a identifikátoru zprávy. Dále také může obsahovat dva elementy popisující stav dopravy a přístupové reference. Dále se ve zprávě vyskytují další segmenty, které jsou specifické pro dané druhy zpráv. Jejich funkce je detailněji popsat data, která se ve zprávě přenášejí, například různá čísla objednávky, texty, počty kusů, ceny, adresy a datumy. Po všech datových segmentech musí zpráva jako předposlední segment obsahovat hlavičku UNT, která říká, kolik bylo ve zprávě použito segmentů včetně UNH a UNT a dále stejné referenční číslo, které bylo použito již v hlavičce UNH. Posledním segmentem ve zprávě je UNZ. Tento segment slouží jako kontrolní a obsahuje stejné označení transakce jako bylo v segmentu UNB, aby se dokázalo, že přenos dat proběhl v pořádku. [45] 3. VDA - Verband der Automobilindustrie jsou formátem zpráv využívaných hlavně v automobilovém průmyslu v Německu. VDA vytvořilo přes 30 druhů svých vlastních typů zpráv, které popisují typicky vyměňované dokumenty v automobilovém průmyslu. Na rozdíl od ostatních EDI formátů se ve VDA nesetkáme s názvy hlaviček jednotlivých elementů a zpráva je tak zakódovaná pomocí řetězců s přesně definovanou délkou. Většina uživatelů VDA má své vlastní interní názvosloví jednotlivých segmentů, a proto je důležité používat směrnice jednotlivých společností. Abych mohl znázornit příklad VDA zprávy použiji směrnice společnosti Volkswagen Aktiengesellschaft nalezené na webu stejně tak jednu z anonymizovaných VDA zpráv. [46] Tabulka 11 Anonymizovaná VDA zpráva L A 60114A I B H.MEERSBUSCH 01536/ FAX-401 K.LARSEVEEN / I Zdroj: [46] 45

46 Tabulka 12 Stručný popis jednotlivých segmentů VDA zprávy Segment Nutnost Popis 711 Ano Hlavička zprávy 712 Ano Obsahuje unikátní data o materiálu, partnerech a vykládce 713 Ano Odvolávková data a detailní analýzy 714 Ne Další odvolávková data 715 Ne Doplňující instrukce k odvolávce 717 Ne Data o balíčku 718 Ne Textová data 719 Ano Patička zprávy Zdroj: Vlastní zpracování, [47] Ať již data pocházejí z jakéhokoliv informačního systému klienta (Inhouse, či jiné EDI formáty), je nutno tato data převést do jazyka XML, aby se dále pomocí jazyka XSL mohli zpracovat. Tento druh konverze se řeší interně v jednotlivých společnostech a každá z nich má svůj vlastní ať již běžný či unikátní průběh Konverze dat pomocí XSL V rámci praktické části bakalářské práce se autor zaměřil na převod zprávy ORDERS a INVOICE z IDoc XML vstupů do EDIFACT XML výstupů a popis jednotlivých konverzí. Jak již bylo zmíněno v předchozích kapitolách pro konverzi je třeba převést Inhouse či EDI formát (IDoc, UN/EDIFACT, VDA) do formátu XML, se kterým mohu dále pracovat pomocí jazyka XSL. Společnost AIMTEC, která má již vytvořené systémy pro převod těchto formátů mi poskytla anonymizovaná XML data, se kterými jsem mohl pracovat. 2.4 Odeslání zprávy Po tom, co proběhne proces převodu zprávy do správného formátu, je připravena na samotný přenos. Zpráva může být přenesena hned několika způsoby, které autor zmínil v kapitole Typy EDI řešení. K připomenutí procesu výměny zpráv slouží následující obrázek, kde můžeme vidět, jak jsou data v interním formátu překonvertována EDI konvertorem a následně odeslána příjemci, který si data překonvertuje zpátky tak, aby jim jejich vlastní interní systém rozuměl. 46

47 Obr. č. 17 Proces výměny zpráv Zdroj: 3 Vlastní řešení 3.1 Fiktivní společnost XYZ s.r.o. Společnost XYZ s.r.o. je maloobchodní společnost zabývající se prodejem počítačových komponent a kompletací počítačů jak pro domácí, tak kancelářské prostředí. Na trhu působí již od roku 2010 a za tu dobu si vybudovala poměrně silnou základnu odběratelů. Společnost nyní vlastní profesionálně vybavenou dílnu pro kompletaci počítačů, sklad jednotlivých komponent a obchodní centrum, kde probíhá komunikace se zákazníkem a osobní výdej zboží. XYZ s.r.o. momentálně zaměstnává 15 zaměstnanců, kteří se starají o celý chod společnosti od správy skladu až po obsluhu zákazníků. Společnost řeší objednávky stále papírově a hned z několika důvodů si přeje zavést EDI. Hlavním důvodem implementace EDI je pro společnost nátlak ze strany dodavatelů, kteří nabízejí po zavedení EDI jisté benefity a také systém udržování minimálních skladových zásob, čímž by firmě odpadla nutnost dále provozovat sklad. Dále pak chce společnost zamezit chybovosti, která se váže na práci s papírovými dokumenty a využít rychlosti a bezpečnosti elektronické výměny dat. Další výhodou zavedení EDI je pro společnost rozhodně důvěryhodná archivace dokladů, která je již 47

48 v dnešní době součástí všech EDI systémů. Do začátku by si společnost přála posílat pouze dva druhy elektronických zpráv a to fakturu (INVOICE) a objednávku (ORDERS). Později by v případě spokojenosti uvítala zavedení dalších druhů zpráv. 3.2 Implementace EDI ve společnosti XYZ s.r.o. Prvním krokem k úspěšnému zavedení EDI ve společnosti je seznámení se s EDI a výhodami, které může společnosti přinést. V případě společnosti XYZ s.r.o. je to především požadavek ze strany dodavatele zboží, tedy splnění jeho podmínek dalšího obchodování. Dále také pak snížení nákladů na jednotlivé výměny dokumentů, rychlost a bezpečnost výměny a v neposlední řadě archivace elektronických dokumentů. Společnost se rozhodla pro využití dvou druhů zpráv ORDERS a INVOICE. S EDI nemá žádné zkušenosti a vzhledem k tomu, že zboží odebírá od většího množství dodavatelů, je vhodné doporučit společnosti využití EDI jako služby, kdy za veškerou EDI komunikaci odpovídá poskytovatel služby, se kterým se domluví na dalších podmínkách spolupráce. Integraci a testování s podnikovým systémem bude provádět poskytovatel EDI služby, který na základě výsledků upraví systém výměny zpráv tak, aby vyhovoval oběma stranám a mohlo tak dojít k podepsání smlouvy o spolupráci. Proces zavádění EDI se liší na základě jeho komplexnosti v případě společnosti XYZ s.r.o. by se jednalo přibližně o pár měsíců po kterých by byla firma připravena začít vyměňovat elektronické dokumenty se svými partnery. 3.3 Proces konverze Společnost AIMTEC poskytla autorovi práce vzorek anonymizovaných ORDERS a INVOICE XML zpráv pocházejících z různých Inhouse či EDI formátů, které pomocí XSL transformace převedl na výstupní XML dokumenty, které by se dále převedly na klientské Inhouse či EDI formáty a byly by odeslány do jejich systému. Konverze každé ze zpráv probíhala trochu jiným způsobem. Zatímco u zprávy INVOICE měl autor k dispozici vstupní i výstupní dokument, dle kterého tvořil samotnou konverzi, což je ve své podstatě jednodušší a rychlejší způsob, jak daný problém vyřešit u zprávy ORDERS dostal pouze vstupní XML soubor, mapovací 48

49 specifikaci pro převod ORDERS10A zpráv a soubor se schématem, který obsahuje strukturu dokumentu. To práci z jisté stránky komplikuje, protože je třeba hlídat přesné pozice jednotlivých elementů. Na úvod řešení tedy bylo důležité se nejprve seznámit s jednotlivými vstupními a výstupními dokumenty a dále také mapovací strategií (obrázek číslo 18), která popisuje, jak vytvořit správnou konverzi dokumentu a na základě této znalosti pomáhá vytvořit strategii, jak zprávu nejjednodušeji přetransformovat na správný výstupní dokument. Obr. č. 18 Mapovací specifikace Zdroj: Mapovací specifikace poskytnuté společností AIMTEC V obou případech začíná práce na XSL konvertoru deklarací XML dokumentu a jmenného prostoru XSL, dále definováním výstupního formátu dokumentu a pak již psaním jednotlivých šablon či kódů sloužících k tvorbě výstupního dokumentu. V tomto případě je nejdůležitější najít způsob, jak konvertovat na výstup to, co klient vyžaduje tak, aby to bylo co nejjednodušeji podané a konverze nebyla zbytečně složitá. Postup transformace zprávy se dále řídí podle toho, o jakou zprávu se jedná. Podrobnější postup konverze si popíšeme v následujících kapitolách. 49

50 3.4 Transformace EDIFACT na IDoc Zpráva ORDERS neboli objednávku zasílá zákazník dodavateli, aby objednal zboží nebo služby v požadovaném množství. Ve zprávě může také specifikovat místo a termín dodání. První segment na výstupu IDoc dokumentu je EDIDC což je kontrolní záznam, který má ve své větvi několik segmentů, obsahujících informace o vstupních a výstupních IDoc dokumentech. Některé segmenty mají hodnoty přiřazené natvrdo a některé se přiřadí až při volání vstupu. Tyto vstupní hodnoty se nazývají parametry, které se naplní při spuštění konverze a později se volají přímo do daného elementu, jak můžeme vidět na obrázku číslo 19. Obr. č. 19 Hodnoty segmentu EDIDC Zdroj: Vlastní zpracování Jako další segment se ve zprávě nachází E1EDK01, který ze vstupního EDI dokumentu konvertuje informace týkající se transportu, jako je druh dopravy, referenční čísla a identifikační čísla týkající se dopravy obsažené v segmentu TDT a uloží je do segmentu VSART. A protože v každém formátu se druh dopravy značí jinak, musí se v případě segmentu TDT využít substituční tabulky z obrázku číslo 20, díky které jsme schopni převést správné kódy dopravy, tak, aby jim rozuměly obě komunikující strany. Obr. č. 20 Substituční tabulka z mapovací specifikace Zdroj: Mapovací specifikace EDI - IDoc 50

51 Pro vytvoření substituce v XSLT využijeme elementu choose a řekneme mu, aby otestoval jednotlivé hodnoty podle substituční tabulky a v případě rovnosti vypsal odpovídající kód. V případě, že nenajdeme žádnou shodu, vypíšeme hodnotu, která se nachází na vstupu. Obr. č. 21 Substituce v elementu VSART Zdroj: Vlastní zpracování Dalším segmentem na výstupu je E1EDK03, který přenáší informace o různých druzích datumů, jako jsou datumy vytvoření dokumentu, či domluvené dny doručení objednávky. Do tohoto segmentu se konvertují data z EDIFACT segmentu DTM (Date/Time/Period). Kde na výstupu bude uloženo prvních 8 znaků v elementu DATUM a dalších 6 v elementu UZEIT. Je tedy třeba napsat jednoduchou podmínku, která otestuje velikost vstupního řetězce a na základě toho vytvoří jeden nebo dva segmenty, které naplní požadovanými daty. A protože je třeba v případě řetězce delšího než 8 znaků informace rozdělit do dvou elementů je třeba využít parametru substring, který rozdělí daný řetězec dle zadaných podmínek. Celý kód, který tvoří segment E1EDK03 můžeme vidět na následujícím obrázku. 51

52 Obr. č. 22 Segment E1EDK03 Zdroj: Vlastní zpracování Dalším segmentem na výstupu je E1EDKA1. Tento segment obsahuje adresy obchodních partnerů, jejich role a informace o místě vyložení dodávky. Do tohoto segmentu se budou konvertovat data ze segmentu NAD (Name and Address) a LOC (Location). Protože každý obchodní partner má jinou adresu a funkci, je pro každého z nich vytvářen vlastní NAD segment s kvalifikátorem, který určuje, o koho se jedná. Kvalifikátor BY (BUYER) se používá pro nakupujícího, SE (SELLER) pro prodávajícího a ST (SHIP TO) je zkratka pro adresu dodání. Poté se jen do správného elementu zavolá hodnota NAD dle kvalifikátoru a na výstupu se v případě následujícího obrázku objeví adresa nakupujícího. Obr. č. 23 Volání elementu NAD Zdroj: Vlastní zpracování Dále se v segmentu E1EDKA1 nachází ještě segment LOC, který se stejně jako předchozí segment NAD, tentokrát bez jakéhokoliv kvalifikátoru jen zavolá se správnou hodnotou do správného elementu. 52

53 Obr. č. 24 Volání elementu LOC Zdroj: Vlastní zpracování E1EDK02 je dalším segmentem, který se objeví ve výstupním IDoc dokumentu. Mapuje informace z BGM (Beginning of Message) a obsahuje tedy informace o čísle objednávky, jejím typu a funkci. Volá se jednoduše jako hodnota segmentu BGM. Obr. č. 25 Volání hodnoty segmentu BGM Zdroj: Vlastní zpracování Dále do IDoc segmentu E1EDK02 patří ještě EDIFACT segment FTX, u kterého jako jednoho ze dvou segmentů je nutno použít šablonu a volat výstupní data přes ní, protože je na vstupu vícero FTX segmentů a nejsou rozděleny podle kvalifikátoru, jako tomu bylo v případě NAT. Šablona jako taková specifikuje, co se stane, když se během průchodu vstupním dokumentem nalezne shoda. Proto je třeba šablona předtím, než bude volána ještě specifikovat. Specifikaci šablony pro FTX nalezneme na následujícím obrázku. 53

54 Obr. č. 26 Šablona segmentu FTX Zdroj: Vlastní zpracování Vidíme, že kdykoliv nalezneme na vstupním souboru FTX_01, vytvoříme na výstupu element E1EDK02 a pomocí if exists otestujeme, zdali existuje nějaký vstup pro zadaný XPath. Pokud vstup existuje, vypíše se element BELNR a do něj se vloží hodnota daného uzlu. Důvodem testování je to, že tento segment není povinný a nemusí se tak v něm nacházet žádné hodnoty. 54

55 Následuje segment E1EDK35 bude mít na výstupu dva segmenty z EDIFACT dokumentu a to TOD (Terms of Delivery), který popisuje dodací podmínky a části TDT, která byla zmíněna o pár řádků výše. Obr. č. 27 Volání hodnoty TDT Zdroj: Vlastní zpracování Posledními segmenty před uzavřením zprávy jsou LIN (LINE ITEM), který popisuje jednotlivé řádkové položky v objednávce a QTY (QUANTITY), který popisuje, množství objednaného zboží. Tyto EDIFACT segmenty se volají do IDoc segmentu E1EDP01. Stejně jako v případě FTX je i zde nutné pro volání vytvořit šablonu, protože v objednávce je pro každý jednotlivý objednaný předmět vlastní řádka. Je tedy nutné, aby pro každou shodu LIN byl vytvořen element POSEX, který jednoznačně identifikuje, o jaké zboží se jedná a element ACTION, který říká, co se má s předmětem stát předtím, než bude odeslán, nebo co má příjemce s předmětem udělat. Tato skutečnost se mapuje pomocí substituční tabulky stejně jako v případě segmentu TDT, ukázku šablony pro segment LIN si můžeme prohlédnout na následujícím obrázku. 55

56 Obr. č. 28 Šablona segmentu LIN Zdroj: Vlastní zpracování 3.5 Transformace INVOICE EDIFACT na EDIFACT Zpráva INVOICE neboli fakturu zasílá dodavatel odběrateli jako výzvu k zaplacení zboží či služeb, které odběrateli poskytl. Prodávající má možnost fakturovat jednu nebo i více transakcí. Tato zpráva většinou obsahuje informace o platebních podmínkách, podrobnosti o dopravě a může také obsahovat další doplňující informace pro celní nebo statistické úřady jedná-li se o zahraniční zásilky. V případě konverze tohoto druhu zprávy měl autor k dispozici výstup dokumentu a mohl tedy XSL konverzi nastavit tak, aby vypadala přesně podle přání klienta. Je nutno podotknout, že předchozí konverze probíhala z EDIFACTU do IDoc a tato konverze se tedy liší od té předchozí svojí strukturou. Zpráva začíná segmentem BGM, jehož účelem je identifikovat typ a funkci zprávy. Protože faktura má více druhů (proforma-faktura, zálohová faktura, dluhopis a dobropis), je třeba v tomto segmentu přesně určit, o jaký typ se jedná. Na vstupu nám to prozradí kód uložený v uzlu DocumentMessageNameCoded a s pomocí mapovací specifikace jsme schopní pomocí jednoduché XSL podmínky vypsat, o jaký typ se jedná. V případě, že nebude kód specifikován, vypíše se hodnota Undefined, jak můžeme vidět na následujícím obrázku. 56

57 Obr. č. 29 Podmínka segmentu BGM Zdroj: Vlastní zpracování Dále se ještě na výstup uvádí jednoznačný identifikátor zprávy, který se jednoduše volá pomocí value-of a XPath. V segmentu BGM se také určuje, zdali se jedná o originální či duplikovanou zprávu. Následuje segment DTM, který určuje datum vystavení faktury a datum zdanitelného plnění. To, o jaký datum se jedná, určí kvalifikátor, na jehož základě vypíšeme na výstup datum ve formátu rok, měsíc a den, jak můžeme vidět na dalším obrázku. Obr. č. 30 Segment DTM Zdroj: Vlastní zpracování Následuje segment FTX, který dává prostor volnému textu ve zprávě. Většinou se do tohoto segmentu zadávají různé správní, daňové či účetní informace. To, jakou informaci daný uzel přenáší určuje kvalifikátor FTX, který je popsán ve specifikaci a k prohlédnutí je i na následujícím obrázku. 57

58 Obr. č. 31 Kvalifikátor segmentu FTX Zdroj: Vlastní zpracování Nyní následuje skupina segmentů s číslem 2, která přenáší informace ze segmentů NAD, RFF (Reference) a FII (Financial Institution Information) tedy specifikace jmenných adres, jejich funkcí a informace sloužící k identifikaci platebních účtů a s nimi spojených platebních institucí. Proces konverze NAD je velmi podobný jako v případě předchozí zprávy. Dle kvalifikátoru se určí, o jakého obchodního partnera se jedná a na základě toho jsou mu na výstupu přiřazeny data s adresou a jménem. V případě segmentu RFF voláme hodnoty dle kvalifikátoru tak, aby byly přiřazeny ke správnému obchodnímu partneru a stejně tak je tomu i u segmentu FII, jak můžeme vidět na následujícím obrázku. Obr. č. 32 Část šablony skupiny segmentů 2 Zdroj: Vlastní zpracování Následuje skupina segmentů s číslem 8, která obsahuje segmenty DTM a PYT (Payment Terms). Tato skupina slouží k přenosu dat o platebních podmínkách. Na konverzi této skupiny není nic složitého a stejně jako v případě předchozích segmentů se testuje hodnota na vstupu a na jejím základě se uloží hodnota na výstup. Poslední skupinou segmentů ve zprávě je skupina 26. Ta sdružuje informace o fakturovaných předmětech. Můžeme se tedy dozvědět, o jaké předměty se přesně jedná, 58