Návrh a realizace vylepšení objednávkového systému pro prodej pneumatik

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh a realizace vylepšení objednávkového systému pro prodej pneumatik Bakalářská práce

Vedoucí práce: doc. Ing. Oldřich Trenz, Ph.D.

Brno 2015

Tomáš Kolník

Na tomto místě bych rád poděkoval svému vedoucímu práce doc. Ing. Oldřichu Trenzovi, Ph.D. za mnohé rady, které mi byly oporou při psaní práce i analýze a implementaci řešení. Dále bych rád poděkoval celé své rodině za podporu, dále firmě S2EP, která mi propůjčila server a všem, kteří mi s prací pomáhali.

Čestné prohlášení Prohlašuji, že jsem tuto práci: Návrh a realizace vylepšení objednávkového systému pro prodej pneumatik vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 22. května 2015

_______________________________

Abstract Kolník, T. Design and implementation of improvements in ordering system for tire sales. Bachelor thesis. Brno: Mendel University in Brno, 2015. This Bachelor thesis deals with tire sales for the use of import by third party using the SAP system. The purpose of this work is to analyze business process in the company and design improvements. Based on this analysis, a new business process is implemented and integrated into SAP ERP and SAP PI. Keywords SAP, ABAP, ERP, tire sales, import third party.

Abstrakt Kolník, T. Návrh a realizace vylepšení objednávkového systému pro prodej pneumatik. Bakalářská práce. Brno. Mendelova univerzita v Brně, 2015. Bakalářská práce se zabývá problematikou prodeje pneumatik závozem třetí stranou za použití informačního systému SAP. V dané práci dochází k analýze řešení obchodního procesu v dané firmě a návrhu vylepšení. Na základě této analýzy je vytvořen nový obchodní proces a implementován do systému SAP ERP a SAP PI. Klíčová slova SAP, ABAP, ERP, prodej pneumatik, závoz třetí stranou.

Obsah

9

Obsah 1

2

3

Úvod a cíl práce 1.1

Úvod....................................................................................................................................... 15

1.2

Cíl práce................................................................................................................................ 15

Metodika

16

2.1

Vytvoření komunikace na straně SAP ...................................................................... 16

2.2

Vytvoření komunikace na straně dodavatele ........................................................ 17

2.3

Testování funkčnosti ....................................................................................................... 17

2.4

Zhodnocení ......................................................................................................................... 17

Teoretická východiska práce

18

3.1

Postup analýzy .................................................................................................................. 18

3.2

Informační systémy (obecně)...................................................................................... 18

3.3

Druhy informačních systémů ...................................................................................... 20

3.4

SAP ......................................................................................................................................... 21

3.4.1

Firma SAP AG ........................................................................................................... 21

3.4.2

Přehled verzí ............................................................................................................ 21

3.4.3

Další produkty SAP ................................................................................................ 22

3.5

4

15

Analýza současného stavu ............................................................................................ 26

3.5.1

Rozdíl mezi retail a etail kanály ........................................................................ 26

3.5.2

Rozdíl mezi standardním prodejem a prodejem třetí stranou............. 26

3.5.3

Proces prodeje pneumatik .................................................................................. 29

3.5.4

Nevýhody stávajícího řešení .............................................................................. 46

Návrh

48

4.1

Návrh řešení ....................................................................................................................... 48

4.2

Data flow diagram – návrh ........................................................................................... 49

4.3

Testovací scénáře ............................................................................................................. 51

4.3.1

Testování obecné funkčnosti ............................................................................. 51

4.3.2

Storno objednávky ze strany SAP .................................................................... 51

10

5

Obsah

4.3.3

Vyčíslení doplatku .................................................................................................. 52

4.3.4

Formát dat od dodavatele ................................................................................... 53

4.3.5

Monitoring zpráv .................................................................................................... 53

Implementace

54

5.1

Použité technologie ......................................................................................................... 54

5.2

Dodavatelský portál......................................................................................................... 54

5.2.1

MySQL databáze ...................................................................................................... 54

5.2.2

Funkce dodavatelského portálu ....................................................................... 55

5.2.3

Webové služby......................................................................................................... 55

5.3

SAP PI .................................................................................................................................... 57

5.3.1

Založení komunikačního uživatele .................................................................. 57

5.3.2

System Landscape Directory.............................................................................. 57

5.3.3

Integrační scénáře – Integration Repository ............................................... 59

5.3.4

Integrační scénáře – Integration Directory .................................................. 61

5.4

SAP ERP ................................................................................................................................ 63

5.4.1

Vytvoření dodavatele ............................................................................................ 63

5.4.2

Vytvoření partnerské dohody ........................................................................... 64

5.4.3

Vytvoření operace ZME11................................................................................... 67

5.4.4

Nastavení dodavatelské fakturace ................................................................... 68

5.4.5

Zapnutí logiky závozu třetí stranou ................................................................ 68

5.4.6

Algoritmus vyčíslení celkového doplatku za objednávku ...................... 68

5.5

Testování ............................................................................................................................. 71

6

Závěr

74

7

Literatura

75

Přílohy

77

A

Zdrojový kód vyčíslení doplatku

78

B

XSLT – OrderData

82

C

ERD – Dodavatelský portál

85

D

Ukázka dodavatelského portálu

86

Seznam obrázků

11

Seznam obrázků Obr. 1

ERP systém

19

Obr. 2

Architektura SAP NetWeaver

24

Obr. 3

Kontextový diagram – původní řešení

29

Obr. 4

DFD – Proces Firemní IS

30

Obr. 5

DFD – SAP ERP

32

Obr. 6

DFD – SAP PI

33

Obr. 7

SD Zakázka

35

Obr. 8

Rozvržení nad zakázkou

36

Obr. 9

Přiřazení zdroje odběru

37

Obr. 10

Nastavení pořadače

37

Obr. 11

Zpráva objednávky

39

Obr. 12

Soubor seznam_zasilek.xml

40

Obr. 13

Předběžně pořízená faktura – připravena k likvidaci

42

Obr. 14

Účetní doklad zaúčtované MM faktury

42

Obr. 15

Účetní doklad zaúčtované SD faktury

43

Obr. 16

Výtisk SD faktury

45

Obr. 17

DFD – Firemní IS – nové řešení

49

Obr. 18

DFD – SAP PI – nové řešení

50

Obr. 19

Struktura výstupní zprávy OrderData

60

Obr. 20

Operation Mapping – OrderData

61

Obr. 21

Configuration scenario – CS_IOBP001_CreateOrder

63

Obr. 22

Založení dodavatel – Nákupní data

64

12

Seznam obrázků

Obr. 23

Partnerská dohoda BP_TEST

65

Obr. 24

Podmínkový záznam zprávy NEU

67

Seznam tabulek

13

Seznam tabulek Tab. 1

Výhody a nevýhody etail prodeje

26

Tab. 2

Odbytové IDocs

34

Tab. 3

Účetní osnova MM faktury (Dvořáková, 2010)

43

Tab. 4

Účetní osnova SD faktury (Dvořáková, 2010)

44

Tab. 5

Výsledek testování doplatku

72

Úvod a cíl práce

15

1 Úvod a cíl práce 1.1

Úvod

Informační systémy jsou obrovskou výhodou moderní doby. Definicí IS je účelová množina prvků a vazeb mezi nimi, ve kterém prvky představují místa transformace vstupních informací na výstupní a vazby – informační toky. Mezi prvky IS nepatří jen hardware nebo software, ale zahrnuje také datové zdroje – lidi, technologie i procesy, současně může existovat i bez počítače. I v malém podniku je mnoho procesů a operací, které je nutné každodenně provádět. Za tímto účelem je rozumným krokem implementace informačního systému, který by měl (při správném výběru systému a nastavení) zautomatizovat většinu procesů a eliminovat množství ručních zásahů. Je velice jednoduché představit si, jakých obrovských chyb se může dopustit zaměstnanec, který je schopen udělat cokoli a systém ho nijak neomezuje. Informačním systémem se může rozumět i primitivní program, který slouží pouze k uchování dat nebo evidenci. Většina firem však využívá rozsáhlejší řešení podnikových procesů zaštiťující minimálně finanční a materiálové části podniku. Správné nastavení systému je základem pro jeho efektivní využití, proto je potřeba myslet dopředu a pokusit se zmapovat a ošetřit všechny možné varianty co mohou nastat společně s posouzením, jaké úrovně uživatelů budou danou komponentou disponovat. Správným nastavením systému se také může minimalizovat množství chyb (pokud ne, je něco špatně) a zredukovat obsluha, která byla bezpodmínečně nutná pro chod i těch nejelementárnějších částí podniků. Automatizování stereotypních operací mnohonásobně zvýší efektivitu pracovníka při minimálních periodických nákladech.

1.2 Cíl práce Cílem bakalářské práce je návrh a realizace řešení prodeje pneumatik se závozem třetí stranou, za použití informačního systému SAP a propojení prodejního procesu s několika dodavateli obchodovaného zboží (pneumatik). Řešení, které bude navrženo v této práci, by mělo později sloužit jako šablona pro napojení dalších dodavatelů nebo reparatura stávajících řešení. Výsledkem bude komunikační interface za účelem automatizovaného prodeje pneumatik bez potřeby skladování zboží v interním skladu. V práci bude představeno nynější řešení i s nevýhodami. Na základě nedostatků bude navrženo vylepšení a poté dojde k implementaci samotného procesu. Na základě výsledků bude řešení použito u nového datového napojení.

16

Metodika

2 Metodika Práce bude řešena dle následujících kroků společně s technologiemi níže popsanými. Nejprve bude představen systém SAP ERP a dále některé další produkty SAP, které jsou nezbytnou součástí řešení. Důvodem použití systému SAP je skutečnost, že celé téma je reálně použito ve společnosti, ve které autor práce momentálně působí a byla mu poskytnuta možnost optimalizace a standardizace procesu skrze bakalářskou práci. Firma nechce být jmenována. Práce má poukázat na chyby v řešení a nastínit možnosti lepšího řešení. Představeny budou také technologie, které nejsou produkty SAP, ale jsou nedílnou součástí práce. Po vytyčení technologických mezí bude představen proces prodeje a jeho výhody i nevýhody. Následně se stanoví zásadní chyby a navrhne se řešení problému, podle kterého se naimplementuje nová komunikace s dodavateli. V posledním bodu bude zhodnoceno celé řešení, které buď bude vyhovovat a bude použito s dalšími dodavateli nebo bude námětem k vylepšení stávajícího procesu. • Vytvoření komunikace na straně SAP o Vytvoření integračních scénářů o Vystavení webových služeb o Nastavení partnerských dohod a kmenových dat o Příprava testovacích dat • Vytvoření komunikace na straně dodavatele o Vytvoření databáze o Vytvoření dodavatelského portálu o Vystavení webových služeb • Testování funkčnosti • Zhodnocení

2.1 Vytvoření komunikace na straně SAP Nejprve budou vytvořeny integrační scénáře. K tomu bude použito systému SAP PI (bude popsán níže). Komunikační kanály budou řešeny pomocí webových služeb, respektive protokolu SOAP. S tím souvisí i forma transformace dat ze SAP ERP do struktur webových služeb. Webové služby pracují s formátem XML, proto budou struktury modelovány v jazyku WSDL (Web Service Description Language). SAP PI poskytuje několik metod mapování vstupních struktur do výstupních struktur. Tato práce představí tu nejelegantnější mapovací metodu a to jazyk XSLT (Extensible Stylesheet Language Transformation), který je opět postaven na XML. SAP ERP vyžaduje speciální a poměrně rozsáhlou customizaci pro nového dodavatele, který má komunikovat tímto způsobem. Dojde tedy k založení nového logického systému v systému ERP (reprezentuje systém dodavatele), skrze kterého

Metodika

17

bude procházet celá komunikace. K této rozsáhlé customizaci jsou využity jak standardní customizační nástroje, jakými jsou například IMG (transakce SPRO), tak také ABAP programovací jazyk SAP a to vše poskytnuté skrze platformu NetWeaver. Jednotlivým technologiím a celkové customizaci budou věnovány samostatné kapitoly.

2.2 Vytvoření komunikace na straně dodavatele Vytvoření vlastního dodavatelského portálu je jediná možnost simulování strany dodavatele. Není možné očekávat, že kterýkoli dodavatel bude měnit svoje komunikace na základě požadavků této práce. Z toho důvodu bude naprogramován dodavatelský portál. Portál bude webovou aplikací, vystavenou na serveru firmy S2EP, která server propůjčila. Portál bude naprogramován v jazyku PHP, za využití HTML a CSS. Jazyk PHP byl zvolen z důvodu jeho popularity mezi webovými vývojáři a jako nejvěrnější simulace portálu dodavatele, se kterým firma spolupracuje. Portál bude využívat webové služby, respektive protokol SOAP, které jsou vystaveny na serveru. Každá služba má definovanou strukturu a bude se používat na přesně stanovené operace. Jednotlivé služby přistupují do MySQL databáze pomocí jazyku PHP, respektive jazyku SQL.

2.3 Testování funkčnosti Na základě chyb současného řešení bude testována funkčnost nové implementace vůči požadavkům na opravu. Testy funkčnosti budou provedeny v celém rozsahu přímo na produkčních datech společnosti (v rámci soukromí budou zákazníci potlačeni). Testovací scénáře budou specifikovány níže v kapitole 4. Návrh.

2.4 Zhodnocení V této části bude vyhodnocena funkčnost nové implementace vůči současnému stavu, naplnění požadavků a zároveň omezení, respektive povinné požadavky k funkčnosti. Také bude ustanoveno, zda komunikační inovace lze nasadit do reálného provozu ve firmě. Kapitola zhodnocení bude obsahem závěru.

18


3 Teoretická východiska práce 3.1 Postup analýzy Než dojde k představení stávajícího procesu řízení prodeje a nákupu pneumatik, je potřeba představit systém SAP a všechny použité komponenty, které v práci budou využity (SAP i NonSAP systémy).

3.2 Informační systémy (obecně) Jak bylo zmíněno výše, informační systémy (také často nazývané ERP systémy – Enterprise Resource Planning) slouží k zefektivnění práce v podniku. Většinou se jedná o nasazení informačního systému do podniku, který disponuje více odděleními navzájem spolu synergicky komunikujících. Základem takového systému je jedna společná databáze, díky níž jsou jednotlivé procesy v systému schopny spolu komunikovat a spolupracovat. Typickým příkladem může být účetní složka a kontrolingová složka nad materiálovým managementem, kdy je potřeba nejen mít kontrolu nad sklady, ale také je nezbytně nutné mít tyto pohyby řádně zaúčtované a připravené pro oddělení kontroly/interního auditu (Maassen, 2007).


Obr. 1

19

ERP systém1

Dalším charakteristickým rysem a přínosem ERP je standardizace procesů. To znamená, že se při implementaci každému řadovému zaměstnanci, manažerovi, pobočce, atd. nastaví přesné oprávnění, co může v systému zadávat spolu s pracovním postupem k co nejefektivnější práci. Takto naimplementované procesy jsou většinou nastaveny napříč celou firmou nebo alespoň po logicky oddělených skupinách. Pokud se proces ukáže jako neefektivní, je velmi jednoduché (z pohledu návazností na daný proces) změnit ho dle požadavků vedení. Příkladem můžeme uvést proces příjmu materiálu na sklad pobočky. Při analýze a implementaci procesu bude řečeno, že přijímat zboží může pouze logistik, který je vždy jediným logistikem na prodejně. Předpokládejme, že si tohoto nepříliš prozíravého zadání nikdo z konzultantů nevšiml a systém se takto nastavil. Firma po několika letech vzrostla a začala budovat mnohem větší prodejny s větším sortimentem. Tato skutečnost měla za následek rozšíření personálu a také se na prodejně zaměstnalo více logistiků. S tím přišel problém, jak tedy budou tito logistici přijímat materiál. Předpokládejme, že ke své práci používají čtečku, která nedovolí, aby v aplikaci bylo více uživatelů, než jeden. Pravděpodobně se bude muset udělat programová úprava na softwaru čtečky, nebo pokud se na toto myslelo s předstihem, bude možné software customizovat. Změna se promítne na všech ostatních pobočkách v systému/skupině. Po změně bude odpovědný za ztráty či

1

Zdroj: http://www.vaclavkeil.cz/wp-content/uploads/2011/11/ERP-tvori.jpg

20


špatné příjmy pouze ten, kdo zboží špatně přijme na sklad, například díky logovaným jménům přihlášení do čtečky nebo uživatele, který vytvoří materiálový doklad příjmu. Takto pevně nastavené procesy eliminují nestandardní řešení problémů. Pokud jsou jasně nastavené operace, co člověk může provádět, bude pro něj velice obtížné, ba dokonce nemožné, zamaskovat úniky a drobné podvody. Systém má sám v sobě kontrolní mechanizmy, které uživatelům nedovolí měnit již zaúčtovaná data. Pokud se nechá uživatelům moc velká volnost operací, co mohou používat, podaří se data zamaskovat, nebo násilně změnit. Většinou se po implementaci může zdát pokles produktivity nebo další propady na klíčových ukazatelích výkonu, hodnoty však budou mít reálný základ a je pravděpodobné, že se časem zvýší produktivita celého podniku (Zikmund, 2010). Dalším přínosem informačního systému do podniku je zrychlení procesů. Příčny jsou minimálně dvě. • Přesné vymezení pracovní osnovy pro jednotlivé zaměstnance – to znamená, že každý by měl přesně vědět, co v daný okamžik procesu udělat a systém pohlídá, že to udělá správně (Zikmund, 2010). • Nemožnost odkládání práce – po novu již není možné nechat svoji práci na někdy později nebo předpokládat, že ji udělá někdo jiný. Veškeré operace jsou dokladovány a systém obsahuje reporty (popřípadě jsou reporty vytvořeny), které kontrolují výkonnosti. Z tohoto pohledu je velice rychle odhalena skutečnost, že pracovník A zpracuje výrazně rychleji svoji práci než jeho kolega pracovník B, který na obrobení materiálu potřebuje den navíc (Zikmund, 2010).

3.3 Druhy informačních systémů Na trhu je mnoho architektur informačních systémů s různou formou záštity procesů. Máme informační systémy úzce zaměřené nebo i celopodnikové kolosy, které slouží ke kompletnímu zabezpečení chodu společnosti. Systémy jsou členěny dle velikosti zákazníka, tedy společnosti (Sodomka, 2010). Následující měřítko je kombinací Evropského a Amerického způsobu (Sodomka, 2010). Evropský způsob řadí IS dle počtu zaměstnanců a Americký dle obratu firmy (Sodomka, 2010). • Velké systémy o pro zákazníky s více než 500 zaměstnanců obratem nad 800 mil. Kč o ERP systémy: SAP, Helios, Microsoft Dynamics • Střední systémy o pro zákazníky s 25 až 500 zaměstnanci a obratem mezi 100 mil. do 800 mil. Kč o ERP systémy: Helios, SAP, QI


21

• Malé systémy o pro zákazníky do 25 zaměstnanců a obratem do 100 mil. Kč o ERP systémy: Helios, Money, Pohoda, QI

3.4 SAP 3.4.1

Firma SAP AG

Informační systém vyvinula stejnojmenná firma SAP (Software2, Anwendungen und Produkte in der Datenverarbeitung, anglicky nazývaná System Analysis and Program Development (SAP History, 2014)), založena roku 1972 pěti zaměstnanci IBM. Na konci prvního roku společnosti čítá celkový počet zaměstnanců devět lidí, a celkový příjem společnosti je okolo 620 000 německých marek. V dalších letech společnost nabrala raketový vzestup a to dokazuje i zvýšení příjmu. Již po třech letech společnost vydělává bezmála 4 miliony německých marek (SAP History, 2014). 3.4.2

Přehled verzí

Informační systém SAP má mnoho verzí a patchů. Představeny budou pouze velké balíky nejrevolučnějších z nich. SAP R/1 Rok po založení společnosti byl dokončen vývoj prvního standardního softwaru pro oblast finančního účetnictví s názvem RF, tento systém byl základem pro vývoj dalších modulů systému R/1 (Real Time–Datenverarneitung), (SAP History, 2014). Systém R/1 využíval jednovrstvou architekturu. Prezentační, aplikační a databázová vrstva se nacházely na jednom serveru/systému (Rathore, 2011). Tato architektura se později ukázala jako neefektivní a v dalších systémech se přecházelo na více vrstev. Systém pracoval s operačním systémem DOS a byl nainstalovaný na serverech IBM (SAP History, 2014). SAP R/2 Následovníkem se stal systém R/2, který byl značně rozšířen oproti jeho předchůdci, nicméně pro provoz stále vyžadoval sálových počítačů. Tento systém kraloval až do roku 1992, kdy jej nahradil systém R/3 (SAP History, 2014).

2

Někde je písmenem „S“ v akronymu SAP míněno slovo Systeme (systémy), (Maassen, 2007).

22


SAP R/3 SAP R/3 byl ve srovnání s předchůdci kompletně jiný systém, který využíval pokročilé architektury client/server a již zmiňované centralizované relační databáze spolu s aplikačními i prezentačními servery. Jednotlivé elementy architektury spolu komunikují prostřednictvím LAN nebo WAN sítí. Vrstvy poskytují služby: • Prezentační vrstva – Poskytuje GUI, dále jsou plně integrovány aplikace jako MS Excel, MS Word, SAP Screen Personas, a další • Aplikační vrstva – Poskytuje aplikační funkce a programy • Databázová vrstva – Je vrstvou databázových služeb Pevný základ v systému R/3 je dodnes stavebním pilířem na nejnovějších verzích. Systém je logicky členěn do několika funkčních oblastí (modulů) – logistika, finanční moduly, řízení lidských zdrojů a odvětvová řešení (zde jsou obsaženy funkce pro potřeby modulů), (Dohnal, 1997). Jednotlivé moduly jsou substitucí dalších členění daných odvětví. Následující výčet představuje hlavní moduly ze systému R/3 (Dohnal, 1997). • FI – Finanční účetnictví • CO – Controlling • AM – Správa investičního majetku • SD – Odbyt • MM – Materiálové hospodářství • PP – Plánování a řízení výroby • QR – Řízení kvality • PM – Údržba • HR – Personalistika a mzdy • PS – Řízení projektů • WF – Automatizace kanceláře (Workflow) • IS – Odvětvová řešení Některé moduly nejsou ve firmě implementovány. V práci bude operováno s verzí SAP R/3 release 701 a pro práci budou stěžejní moduly FI/CO, SD, MM. 3.4.3

Další produkty SAP

SAP neposkytuje pouze informační systémy ERP, které jsou srdcem celého řešení, ale poskytuje i další produkty, které jsou většinou nástavbou ERP. V dalších kapitolách bude představeno několik stěžejních produktů a technologií.


23

ABAP ABAP je programovací jazyk, který vyvinula společnost SAP jakožto zapouzdření databázových příkazů a práce s dialogy. Obrovskou výhodou ABAPu je jeho nezávislost jak na hardwaru, operačním systému, databázovém systému, tak na okolních programovacích jazycích. Tato vlastnost je v informačních systémech obrovským plus, jelikož legislativa často nutí data archivovat roky i desetiletí. I dodnes je možné první programy napsané v jazyku ABAP upravovat, kompilovat i spouštět. V SAP jsou zavedeny ochranné entity, které zajišťují bezpečnost a konzistenci aplikačních dat. Takovouto funkcionalitu můžeme nazvat architektura organizace řízení (Kühnhauser, 2009). • Systém pro testování a vývoj – Používá se pro systémová nastavení, programování a testování na testovacích datech. Obvykle jsou tyto systémy otevřené pro vývoj a obsahují velké množství uživatelů (vývojářů, konzultantů), kteří zde vyvíjí, testují a simulují podnikové procesy. Z hlediska ochrany dat je tento systém velmi špatný a proto se po ukončení vývoje a iniciálním otestováním funkcionality přesouvá vývoj na konsolidační systém. • Konsolidační systém – Tento systém převážně slouží k akceptačním testům. Za tímto účelem jsou z produkčního systému kopírována „ostrá“ data na konsolidační systém a tudíž je možné veškerý vývoj bezvadně otestovat na datech, která jsou shodná s daty na produkčním systému. Na přístup, autorizaci a zabezpečení dat se zde kladou přísnější požadavky. • Produkční systém – Představuje pro společnost největší riziko, jelikož obsahuje data z reálného provozu a tudíž má nejvyšší ochranu. Pravidlem je, že se zde nikdy neprovádí vývoj a nemění parametry systému (customizing). Otestované vývojové pakety se do produkčního systému transportují pomocí jednotlivých transportních požadavků. Přenosy mezi jednotlivými systémy jsou zabezpečšny tzv. transportním systémem. Veškerý vývoj se ukládá do transportních požadavků, které mohou být strukturované. Hlavní transport je vždy jeden a musí mít unikátní číslo (označení). Takovýto požadavek je po ukončení vývoje uvolněn a připraven k transportu v transportní frontě cílového systému, kam má být přenesen. Přenos mezi samotnými systémy by nikdy neměl provádět samotný programátor, ale správce daného systému, který dostane číslo požadavku a schválení k transportu od konzultanta, který úpravu navrhl (Kühnhauser, 2009).

24


SAP NetWeaver SAP NetWeaver je aplikační a integrační platforma pro produkty SAP. Obsahuje standardizované integrační komponenty pro integraci rozhraní, integraci informací, integraci aplikací. Platforma poskytuje API s množstvím technologií, nástrojů a komponent, které umožňují integraci jak s podnikovými aplikacemi, tak i mimo ně (Mangesh, 2012).

Obr. 2

Architektura SAP NetWeaver3

SAP NetWeaver jakožto kolekce aplikací, utilit a nástrojů je rozdělena do 6 oblastí (Anderson, 2012). • Řízení základu – zahrnuje SAP NetWeaver Application Server (základní platforma pro SAP Business Suite), SAP Solution manager (správa jednotlivých systémů SAP a monitoring provozu). • Middleware – sestává ze SAP Process Integration (tato aplikace slouží k integraci aplikací SAP s okolními systémy a jejich daty. Okolními systémy můžou být chápány systémy třetích stran i produkty SAP), partnerských adaptérů a podpory různých standardizovaných protokolů. 3Zdroj:

png

http://www.eridea.de/cms/sites/default/files/images/03kompetenzen/00sap/netweaver.


25

• Řízení informací – její součástí je mimo jiné SAP Business Warehouse a Warehouse Accelerator, což jsou objekty datových skladů a reportingovací nástroje. • Produktivita systému – obsahuje produkty usnadňující práci se systémem jako například SAP Screen Personas, SAP NetWeaver Portal a další. • Kompozice – zahrnuje nástroje pro vývoj, monitorování podnikových procesů. • Řízení podnikových procesů. Mnohé z těchto produktů a aplikací jsou pro tento projekt nepodstatné, bude představen zejména produkt SAP PI. SAP PI Produkt SAP Process Integration je společně se SAP ERP klíčovým prvkem v této práci. Ačkoli je SAP ERP rozsáhlý systém spravující velké množství firemních procesů, nedokáže pojmout všechny požadavky a obsáhnout všechny nástroje pro jednotlivé podniky a odvětví, ve kterých působí. Každá organizace proto využívá i jiné programy a systémy k různým operacím ve firmě. Ačkoli tyto systémy fungují paralelně k systému SAP ERP, i tak potřebují produktivní data ke svému chodu, ať synchronně, či asynchronně. Mimo jiné i za tímto účelem se využívá modul SAP PI, který slouží k integraci. SAP PI se dělí na několik součástí, které spolu pružně spolupracují skrze jednotlivé integrační scénáře. Architektura obsahuje komponenty pro návrh, konfiguraci, spuštění a také monitoring. SAP PI můžeme rozdělit na několik celků: • Integration Server • Integration Builder • System Landscape • Configuration and Monitoring Systém poskytuje mnoho standardizovaných protokolů pro komunikaci s okolními systémy: • IDoc – standardní formát pro výměnu dokumentů • RFC – vzdálená volání funkcí SAP • File/FTP – práce se soubory a souborovými systémy včetně FTP • SOAP – Webové služby • a další

26


3.5 Analýza současného stavu Tato práce je situovaná na klasický princip e-shopového prodeje zboží (dále etail) s využitím dodání třetí stranou. Nejdříve je potřeba definovat, co znamená etail prodej, jaké jsou jeho výhody a nevýhody oproti kamennému prodeji (dále retail) a co přináší za plusy závoz zboží třetí stranou. Procesy již budou směřovány na případ dané firmy, je tedy možné, že se budou mírně lišit od standardních procesů v jiných společnostech. 3.5.1

Rozdíl mezi retail a etail kanály

V dnešní době je retail prodej (v české terminologii SAP, maloobchod) na ústupu. Rozmohl se trend etail prodeje, který sebou přináší mnoho výhod, ale i nevýhod, některé z nich jsou představeny v následující tabulce: Tab. 1

Výhody a nevýhody etail prodeje

Výhody Nižší ceny než na kamenných prodejnách Srovnávače oblíbenosti, ceny, dostupnosti, možnost porovnání technických parametrů zboží, reference přímo na internetu Filtry dle vlastních požadavků

Nevýhody Není možné si zboží zkusit, prohlédnout Nikdo zákazníkovi neporadí Nedůvěra starších lidí Velký počet neseriózních e-shopů

Z tabulky Tab. 1 lze odvodit, že prodej na kamenných prodejnách vyhovuje spíše lidem, kteří potřebují poradit s výběrem nebo si zboží potřebují zkusit, prohlédnout, změřit, atd. V některých případech mohou tyto dva kanály spolupracovat. Většinou je to formou výdejních míst, které zajišťují kamenné prodejny pro internetové obchody. 3.5.2

Rozdíl mezi standardním prodejem a prodejem třetí stranou

Standardní prodej Standardním prodejem je myšlen prodej zboží, který si zákazník objedná a následně je mu blokováno a odebráno z určitého skladu společnosti. Toto zboží musí být na skladě dostupné nebo se na základě potřeby vygenerované zákaznickou poptávkou doobjedná na daný sklad. Poté je zákazníkovi opět dodáno z daného skladu. Cyklus obchodního případu. 1. Objednávka zboží zákazníkem 2.

Rezervace zboží 2.1. Pokud je zboží skladem – zarezervuje se na skladu


3.

27

2.2. Pokud zboží skladem není – zboží se objednává na sklad Expedice 3.1. Zboží je odebráno ze skladu a expedováno na dodací místo, skladová zásoba byla ponížena o daný počet kusů

4.

Fakturace 4.1. Zboží je dodáno zákazníkovi a následně se vystavuje faktura

Závoz třetí stranou Závoz nebo také prodej třetí stranou má oproti standardnímu prodeji několik výhod. První část procesu, tedy vytvoření poptávky, probíhá totožně jako u standardního prodeje. Zákazník si objednává zboží například na webové stránce, ta objednávku přijme a odešle do informačního systému, který ji zpracuje. Rozdílná část nastává při určení zdroje odběru zboží. Závoz třetí stranou znamená, že zboží není blokováno a odebráno ze skladu společnosti, ale potřeba je přesunuta na určitého dodavatele, který závoz zajistí. Tento koncept má několik výhod. V následujícím výčtu budou některé vyzdvihnuty a popsány. • Skladová nezávislost – tímto bodem je myšleno oproštění se od nutnosti skladovat zboží na svých skladech. Tento bod sebou nese velkou finanční úsporu a je jedním z hlavních faktorů, proč přejít na závoz třetí stranou. • Separace od logistických operací – firma je oddělena od samotného závozu a sjednávání logistických transakcí. Závoz přenechá na dodavateli, který má často dodavatelské bonusy a expedice je pro něj výhodnější, než kdyby ji zajišťovala firma sama. Na straně firmy zůstává pouze příjem objednávek, jejich zpracování a přeposlání dodavateli a po doručení zboží, tisk faktur. To přináší značné zjednodušení procesu. • Netřeba předzásobovat sklady – značnou výhodou může být i eliminace plánování a objednávání zboží na sklad firmy. Dodavatel zpravidla neobchoduje pouze s jednou firmou, proto má na skladech obrovské zásoby nejrůznějších artiklů. Pokud se tedy firma napojí na skladové zásoby daného dodavatele a zobrazuje, že je schopna dodat takové množství pneumatik, jako má dodavatel na skladě, je to zajisté velká výhoda. Pravděpodobně by nebylo možné při normálním prodeji objednat takové množství a počty kusů jednotlivých artiklů na sklad společnosti. Velký počet kusů několika artiklů nebo malé počty kusů mnoha artiklů nejsou tou správnou cestou a nemohou mít takový výsledek, jako skladové zásoby velkých dodavatelů.

28


Zjednodušením fyzického procesu se přímou úměrou zkomplikoval proces, který musí proběhnout v systému. 1.

Objednávka zboží – založení zakázky zákazníka v systému

2.

Přiřazení zdroje odběru 2.1. Systém vyhodnotí možný zdroj odběru a k tomuto dodavateli vytváří nákupní objednávku

3.

Nákupní objednávka 3.1. Objednávka obsahuje veškeré potřebné údaje pro její vyřízení. 3.1.1. Kontaktní a dodací údaje 3.1.2. Zboží spolu s počtem kusů

4.

3.1.3. Informace o dobírce (doplatek) Informace o expedici zboží 4.1. Dodavatel vrací informaci o příjmu objednávky a zboží expeduje na dodací místo

5.

Fakturace 5.1. Dodavatel posílá fakturu na stranu naší firmy a po její likvidaci se vytváří faktura zákazníkovi.

Důvodem, proč byl využit v dané společnosti závoz třetí stranou, je zrušení skladu s pneumatikami. Jelikož firma obchoduje i s jiným sortimentem (konkrétně elektronické zboží a nábytek) a ten je skladován v samostatném skladu, bylo finančně i logisticky náročné udržovat dva sklady. Sloučení skladů bylo v tomto případě nemožné, jelikož skladování pneumatik podléhá legislativě. Dle § 4 odst. 2 písm. e) zákona č. 133/1985 Sb. „Za provozované činnosti se zvýšením požárním nebezpečím se považují činnosti v prostorách, ve kterých se vyskytuje nahodilé požární zatížení 120 kg/m2 a vyšší“ (Šubrt, 2001). Pro příklad, dle přílohy č. 2 k vyhlášce č. 246/2001 Sb. pneumatiky požárně zatěžují 150 kg/m2 (Vyhláška č. 246/2001 Sb. o stanovení podmínek požární bezpečnosti a výkonu státního požárního dozoru (vyhláška o požární prevenci), 2001). Pneumatiky, jakožto silně hořlavý materiál, nesmějí být skladovány s elektronikou a musí být speciálně uloženy. Z finančních důvodů byl tedy zrušen sklad pneumatik a implementován závoz třetí stranou. Veškeré pneumatiky jsou odebírány od dodavatelů, kteří své pneumatiky mají bezvadně uloženy s náležitou ochranou.


3.5.3

29

Proces prodeje pneumatik

Cílem této kapitoly je představení nynějšího procesu prodeje pneumatik. V jednotlivých částech budou představeny kroky, které jsou v systému i mimo něj podniknuty. Kontextový diagram Kontextový digram slouží k zmapování systému a jeho okolí. Je substitucí všech procesů interního systému.

Obr. 3

Kontextový diagram – původní řešení

Diagram obsahuje terminátory Zákazník a Dodavatel, kteří jsou pro Firemní informační systém (dále jen IS) externí entitou. Zákazník komunikuje s IS pomocí datového toku Obchodní případ, který symbolizuje požadavek zákazníka na zboží či službu. Zpětný tok Potvrzení obchodního případu předává zákazníkovi informaci o přijetí požadavku na obchodní případ. Dodavatel komunikuje s IS dvěma výstupními datovými toky (XML potvrzení expedice, XML faktura) a samostatným vstupním datovým tokem (XML objednávka). Proces Firemní IS bude popsán v DFD 1. úrovně.

30


DFD 1. úrovně Data flow diagram 1. úrovně slouží k dekompozici hlavního procesu kontextového diagramu a zároveň představuje celý vnitřek systému.

Obr. 4

DFD – Proces Firemní IS

Obr. 4 zobrazuje diagram datových toků 1. úrovně, který představuje dekompozici procesu Firemní IS z kontextového diagramu. Systém je rozdělen do dvou hlavních procesů SAP ERP a SAP PI. Proces SAP ERP komunikuje čtyřmi datovými toky. • Webová objednávka o iniciátorem je terminátor Eshop o předává obchodní případ v podobě webové objednávky


31

• Nákupní objednávka o iniciátorem je proces SAP ERP o přenáší nákupní objednávku • Předběžně pořízená faktura o iniciátorem je proces SAP PI o předává fakturu od dodavatele • Přijímaná dodávka o iniciátorem je proces SAP PI o předává informaci o expedici zboží Vnitřní procesy SAP ERP a SAP PI budou popsány v druhé úrovni DFD. Proces SAP PI mimo komunikace s procesem SAP ERP, také komunikuje s datovým skladem, který reprezentuje FTP server, který uchovává soubory ke zpracování.

32


DFD 2. úrovně Data flow diagram 2. úrovně dekomponuje vnitřní procesy systému.

Obr. 5

DFD – SAP ERP

Dekompozice procesu SAP ERP obsahuje tři procesy zpracovávající data směrem k SAP PI (dodavateli). Proces Založení zakázky překlápí webovou objednávku do zakázky, která představuje v SAP doklad obchodního případu zákazníka. Založená zakázka dle volby úhrady může požadovat vyrovnání plateb a poté vytváří Požadavek na objednávku, který vstupuje do procesu Vytvoření nákupní objednávky. Vytvořením objednávky je automaticky vygenerována zpráva, která vytváří IDoc odcházející do SAP PI. Zpětným tokem ze SAP PI jsou zprávy IDoc, které vstupují do procesů Zpracování IDoc. Zpracování vyseparuje z IDoc data a vytvoří SAP objekty Přijímaná dodávka a Předběžně pořízená faktura.


Obr. 6

33

DFD – SAP PI

Proces SAP PI představuje propojení mezi dvěma systémy. Slouží k transformaci zpráv do různých formátů. SAP ERP předává datový tok Nákupní objednávka (formát IDoc), SAP PI dle integračního scénáře určí cílový systém a formát, do kterého má být zpráva transformována a spustí mapovací funkci, která transformaci zajistí. Proces Přenos do vzdáleného systému zprávu přenese do úložiště, odkud ji zpracuje dodavatel. Datový sklad předává dva datové toky směrem od dodavatele do systému SAP ERP. Oba soubory jsou převzaty z datového skladu a jako zprávy zpracovány obdobným způsobem, jako při zpracování nákupní objednávky.

34


Vytvoření objednávky na webu Pro pochopení procesu není tento bod klíčový, a nebudou zde prováděny žádné změny v rámci vylepšení, které řeší tento projekt. Objednávky jsou sjednávány na webovém obchodě firmy. Zákazník vloží zboží do košíku, vybere si druh platby a dopravy a zadá své nacionále pro doručení objednávky. Objednávka je pořízena a zákazník obdrží kupní smlouvu. Zbytek procesu se děje na pozadí. Web je nastaven na automatické vytvoření XML souborů a jejich uložení na FTP pro zpracování objednávky v SAP. Založení zakázky v SAP Založení standardního odbytového dokumentu je provedeno skrze několik dokumentu tzv. IDoc (Intermediate Document). Tab. 2

Odbytové IDocs

IDoc – Typ zprávy SALESORDER_CREATEFROMDAT2 DEBMAS

Popis Založení zakázky odběratele Distribuce kmenových dat odběratele

Jak bylo řečeno v kapitole výše, firemní e-shop vytvoří z webové objednávky několik XML souborů se strukturou IDoc. Zpravidla je vytvořen jeden soubor typu SALESORDER a dále jeden až dva soubory typu DEBMAS. Počet souborů DEBMAS souvisí s počtem odběratelů. Může být chápáno jako počet entit (partnerů), které souvisejí se zakázkou. Typickým příkladem dvou odběratelů je zákazník, který zadává objednávku a zákazník, který přijímá zboží. Současně není nezbytné, aby to byli různí lidé, mohou se lišit pouze adresou. SAP jednotlivé soubory stáhne na lokální disk a pomocí standardního funkčního modulu jsou jednotlivé XML soubory překlopeny do IDoc. Zde je potřeba oddělit dvě navzájem zaměnitelné slova – zakázka a objednávka. Zakázka je unikátní odbytový doklad SAP, nýbrž objednávka je v odbytovém kontextu brána jako číslo objednávky zákazníka, respektive číslo webové objednávky. Při založení zakázky je potřeba dodržet hierarchii, jak jsou k sobě doklady připojeny. Nejdříve je tedy potřeba založit jednotlivé odběratele a poté až zakázku.


Obr. 7

35

SD Zakázka

Jak lze vidět na Obr. 7 zakázka obsahuje hlavičkové údaje, tedy samotné číslo zakázky a číslo webové objednávky, dále také jednotlivé odběratele a další hlavičkové údaje skryté pod tlačítkem s lupou vedle data objednávky. Ve spodní části obrazovky jsou jednotlivé položky. Platba zálohy Platba zálohy je krok, který je nutný u zakázek placené bankovním převodem, částečnou zálohou nebo nějakou další zálohou platbou. Samotná záloha je vykryta pomocí výpisu z banky, který je několikadenně stahován z hlavní banky. Systém pomocí variabilního symbolu platby napáruje na jednotlivé požadavky na zálohu. Po vyrovnání účetních položek je záloha vyrovnána a zakázka je odblokována (zrušení blokace expedice) a uvolněna k dalším krokům. Platba zálohy není vždy povinným krokem v životním cyklu zakázky. Typickým příkladem může být platba dobírkou nebo při osobním převzetí. V těchto případech zakázka není blokovaná a je možné vytvořit tzv. rozvržení potřeby. Přiřazení zdroje odběru Rozvrhování zakázek je akce nad zakázkou, kdy systém vypočítává termíny zakázek a potřeby kapacit (Maassen, 2007). SAP nad zakázkou zjistí, že na skladu se nenachází žádné zboží a že je potřeba jej objednat. Spolu s vygenerovanou potřebou se stanoví předpokládaný datum závozu, který je definován na úrovni materiálu nebo na kartě dodavatele (Maassen, 2007).

36

Obr. 8


Rozvržení nad zakázkou

Na obrázku Obr. 8 je vidět automatické rozvržení, které bylo provedeno nad zakázkou 7000323423. První řádek značí datum, ke kterému má být rozvržení provedeno. Sloupec potvrzené množství, který je nulový značí, že v danou chvíli nebylo možné vykrýt potřebu a požadované množství bude objednáno u dodavatele. Druhý řádek značí, kdy bude množství dostupné. Poslední dva sloupce představují jednoznačný identifikátor mezi požadavkem na objednávku a zakázkou. Požadavek na objednávku dále jen POBJ je dokladem, popisující určitou vypočítanou potřebu a samotným iniciátorem celého procesu pořízení (Maassen, 2007). Na rozdíl od objednávky není POBJ vázán na určitého dodavatele (Maassen, 2007). Od jakého dodavatele má být zboží odebráno, je definováno zdrojem odběru viz Obr. 9. Přiřazení zdroje odběru je velmi důležitou částí POBJ a pro tuto práci klíčový. Část obecných dat, např. textový popis, druh zboží, lze získat z karty materiálu. Podrobnější nákupní data jsou přístupná až po přiřazení zdroje odběru a provázání položky POBJ s dodavatelem (Maassen, 2007). Nosičem specifických nákupních dat je nákupní informační záznam (Maassen, 2007). Lze říci, že informační záznam je základním zdrojem pro nákup, neboť obsahuje specifická data týkající se nákupu určitého materiálu od určitého dodavatele (Maassen, 2007). Za tato data je například považována oceněná cena, plánované datum dodání, název materiálu, jak ho nazývá dodavatel a další. Řádně vyplněný POBJ slouží jako předloha pro vytvoření nákupní objednávky.


Obr. 9

37

Přiřazení zdroje odběru

Posouzení, u jakého dodavatele má být zboží objednáno (může být chápáno jako jakýkoli skladovací objekt – centrální sklad, pobočka, výrobce, a další), je řízeno takzvaným pořadačem na kartě materiálu. Pořadač je identifikátor zdroje odběru mezi materiálem, dodavatelem a cílovým místem dodání. Vždy by měl být aktivní právě jeden dodavatel, v opačném případě systém není schopen automaticky přiřadit zdroj odběru a musí být ručně přiřazen obsluhou.

Obr. 10

Nastavení pořadače

Na obrázku výše jsou nastaveni možní dodavatelé pro pobočku W001, označení dodavatele za aktuálního umožňuje sloupec Fi (Pevné zásobování) a Dis (Použití pořadače v dispozici). Vytvoření nákupní objednávky Nákupní objednávka je z velké části tvořena z POBJ. Dodatečné informace, jako například nákupní cena, jsou dohledány v systému při zakládání objednávky. Problematickou částí objednávky je vyčíslení doplatku, který má dodavatel, respektive přepravní společnost vybrat. V ideálním případě by jednotlivé položky objednávky

38


obsahovaly částku, která má být vybrána. Pro dodavatele by tato skutečnost znamenala vyčíslit sumu celkového doplatku za expedované zboží a sdělení částky přepravní společnosti. Při založení je k objednávce přiřazená výstupní zpráva NEU, která slouží k přemapování objednávky do IDoc ORDER05. Zpráva NEU má pro jednotlivé dodavatele v customizaci nastaven logický systém, ke kterému se má přiřadit. Zpráva tedy v tomto případě spadá pod logický systém BP_TEST, který má nastaven port XI_BRIDGE. Toto nastavení zajistí přenos ven ze systému SAP ERP do systému SAP PI, kde je řízeno kam a jak se zpráva pošle. Přenos objednávky dodavateli Objednávka je v systému SAP PI interpretována jako zpráva, která je odeslána od odesílatele (sender) a směřuje k příjemci (receiver). Jak bude zpráva odeslána, je definované v jednotlivých integračních scénářích. Daná zpráva (v tomto případě objednávka) je odeslaná ze sender interface BP_TEST, pro každý typ zprávy je stanoven takzvaný receiver determination, který definuje, jakým komunikačním kanálem bude odeslána. V tomto případě je zpráva odeslána jako soubor na vzdálené FTP skrze protokol File/FTP. Jelikož zprávy nejsou ve stejném formátu (sender odesílá typ IDoc a receiver očekává typ File) integrační scénář vyvolá mapovací proceduru, která zprávu konvertuje do požadovaného formátu. SAP PI pracuje se zprávami jako s XML a je několik možností, jak zprávy zpracovat. Mapování může být provedeno pomocí interních operací systému, takzvaného (Message Mapping) nebo může být využit jazyk XSLT, který primárně slouží k transformaci XML souborů. V netriviálních případech je k mapování efektivnější použít jazyk XSLT, proto je i zde využit. Jakmile je zpráva ve výstupní struktuře, stačí ji přenést do cílového systému, který je popsán v komunikačním kanálu.


Obr. 11

39

Zpráva objednávky

Na obrázku výše je vidět zprávu objednávky. V horním okně je vstupní zpráva ve formátu IDoc tak, jak odešla ze systému SAP ERP a v dolním okně je vidět již přemapovaná zpráva ve formátu XML, která byla odeslána na vzdálený FTP server. Potvrzení expedice dodavatelem Po přijetí objednávky dodavatelem je objednávka ve stavu odeslaná a čeká na zpracování a bude provedena expedice zákazníkovi nebo prodejně. Dodavatelovy interní operace nejsou známy a nejsou v tuto chvíli ani potřebné, SAP očekává pouze potvrzení expedice. K potvrzení expedice slouží takzvaná přijímaná dodávka, která nese informace o dodávce zboží (může být chápána jako kamion, paleta nebo například balík). Dodavatel k signalizaci expedice periodicky vytváří XML soubor s názvem seznam_zasilek.xml. Tento soubor obsahuje seznam všech objednávek, které byly

40


zpracovány systémem, a u jednotlivých položek seznamu jsou signalizovány stavy objednávky.

Obr. 12

Soubor seznam_zasilek.xml

Z obrázku Obr. 12 je patrné, že XML není stavěno nejlepším způsobem a obsahuje zbytečně mnoho čistého textu. Formát byl stanoven dodavatelem jako již zavedený způsob propojení s prodejci. Zpracování souboru je nastaveno v systému PI, integrační scénář má nastaven interní časovač, který odpočítává 3600 sekund a po uplynutí časového intervalu se pokusí stáhnout soubor z FTP. Pokud není soubor dostupný, PI ukončí přenos a znovu odpočítává daný časový interval, v opačném případě je soubor stažen, zarchivován a uložen do interní paměti pro zpracování. Následně je spuštěn Adapter engine, který se stará o mapování a zajistí korektní zpracování typově rozdílných zpráv. XSLT procesor prochází celý soubor a zpracovává elementy , které jsou relevantní. To, jestli jsou relevantní, je řízeno elementem <stateCode>. Pro každou jednu objednávku (element ) je vytvořen jeden IDoc typu DESADV, který je odeslán do ERP, kde je zpracován a vytváří přijímanou dodávku. Nevýhodou tohoto řešení je, že dodavatel vytváří seznam s periodicitou hodina a časový interval, kterým jsou objednávky selektovány je v jednotkách dnů (reálně jsou vybírány objednávky až 14 dnů staré). Tím pádem jsou duplicitně zpracovávány a přenášeny data, PI nemá žádné informace ze SAP ERP, proto nedokáže eliminovat již zpracované zásilky. Jakmile je přijímaná dodávka vytvořena, slouží jako identifikátor dávky pro příjem zboží. Čas vytvoření přijímané dodávky koresponduje s časem expedice zboží dodavatelem. V první řadě je potřeba rozdělit zboží expedované na prodejnu a zákazníkovi přímo na adresu. Pokud je zboží expedované na prodejnu, musí dojít k takzvanému naskladnění zboží na sklad prodejny. Je zde více možností, jak pří-


41

jem zboží udělat. Prodejny využívají nestandardní způsob a vytváří samostatný materiálový doklad, tím zůstává přijímaná dodávka nezaúčtovaná (zaúčtováním dokladu se doklad uzavírá – standardní postup v systému SAP). Zaúčtováním materiálového dokladu se zboží naskladní na sklad prodejny a je připraveno k prodeji. Pokud je zboží expedované přímo zákazníkovi na danou adresu, příjem zboží se neprovádí. Prodej / výdej zboží Prodejem zboží jako takovým je primárně myšleno prodej skrze prodejnu, respektive kasu prodejny (výdej v případě, kdy zákazník zaplatil zboží předem). Prodavač namarkuje zboží a po zaplacení a vytištění účtenky je odeslán IDoc SHP_OBDLV_CREATE_SLS01, který zajistí vytvoření odesílané dodávky. Odesílaná dodávka slouží k vyskladnění zboží ze skladu prodejny. Z kasy jsou odeslány ještě další IDocs, které zaúčtují peníze, odešlou pokladní bloky spolu s účtenkou a naplní kasové tabulky v systému SAP ERP. Tímto je prodej uzavřen a je potřeba vytvořit fakturu. Za prodej zakázky expedované přímo zákazníkovi na adresu je považována materiálová fakturace viz kapitola níže. Příjem faktury od dodavatele S dodavatelem bylo sjednáno, že bude vystavovat faktury, jakmile dojde k předání zboží prodejně nebo zákazníkovi. Důvodem pro tento požadavek byl fakt, že jakmile je materiálová faktura přijata a účtárnou zaúčtována, je možné zakázku fakturovat takzvanou SD fakturou, která je odesílána zákazníkovi. Dohodou s dodavatelem se zajistí, že zákazník nedostane fakturu, aniž by zboží převzal. Při prodeji skrze prodejnu tento problém nehrozí, jelikož jsou položky zakázky nastaveny pro fakturaci z dodávky. To znamená, že zakázka nemůže být vyfakturována, dokud není vytvořena odesílaná dodávka z kasy, viz kapitola výše. Komunikační scénář je řešen podobně jako potvrzení expedice. Jakmile je objednávka dodána (prodejně nebo zákazníkovi), dodavatel vytváří fakturu. Současně je naplněn soubor seznam_faktur.xml, který je periodicky nahráván na FTP, kde ho stahuje s periodicitou 3600 sekund SAP PI. Pokud dotaz na soubor proběhne úspěšně, soubor je zarchivován a zpracován. Mapovací program prochází XML soubor a všechny nestornované faktury přemapuje do výstupního formátu IDoc INVOIC01. Každý IDoc v systému SAP ERP vytvoří takzvanou předběžně pořízenou fakturu (MM fakturu). Materiálové faktury slouží k platbě dodavateli za dodaný materiál k objednávce nebo objednávkám. Každá z těchto faktur jsou k ničemu, dokud je manuálně někdo nezaúčtuje. Tyto operace provádí účtárna a pouze pokud má ke každé faktuře i originál v papírové podobě se stejnými daty.

42

Obr. 13


Předběžně pořízená faktura – připravena k likvidaci

Po likvidaci faktury (jejím zaúčtování) jsou vytvořeny účetní doklady, které proúčtují platbu skrze finanční účetnictví.

Obr. 14

Účetní doklad zaúčtované MM faktury


43

Z obrázku Obr. 14 je vidět, jak byl doklad zaúčtován. Jedná se o standardní nákup zboží a účty jsou synteticky očíslovány dle legislativy. Tab. 3

Účetní osnova MM faktury (Dvořáková, 2010)

Učet (Syntetická část) 321 504

Definice Dodavatelé – závazky z obchodních vztahů Prodané zboží – náklady

Analýza účetního dokladu z Obr. 14: • Účet 321100 – zde je naúčtován předpis na účet dodavatele (1004269). • Účet 504109 – zde jsou náklady naúčtovány na středisko W001. Tvorba zákaznické faktury Zákaznická faktura, nebo také SD faktura, je odbytový doklad, který slouží jako daňový doklad pro zákazníka a který si může zanést do svého účetnictví. Fakturace probíhá pomocí workflow, jakmile je zakázka relevantní pro fakturaci workflow automaticky vytvoří SD fakturu. Zároveň se vznikem SD faktury vzniká i FI faktura (interní účetní doklad systému), která odráží pohyby na účtech. Materiálové pohyby při fakturaci nevznikají.

Obr. 15

Účetní doklad zaúčtované SD faktury

Pro bližší pochopení účetního dokladu, je potřeba představit syntetickou část jednotlivých účtů.

44


Tab. 4

Účetní osnova SD faktury (Dvořáková, 2010)

Učet (Syntetická část) 311 343 602 604

Definice Pohledávky z obchodních vztahů – odběratelé (zákazníci) Daň z přidané hodnoty Tržby z prodeje služeb – výnosy Tržby za zboží–výnosy

Analýza účetního dokladu z Obr. 15: • Účet 311600 – tento učet je navýšen o platbu za zboží zákazníkem. • Účet 60427721 – je účtem odběratele, tedy zákazníka. Je ponížen o částku, kterou zákazník zaplatil. • Účet 343030 – na tento účet je zaúčtovaná daň. • Účet 604109 – na tento účet jsou naúčtovány výnosy za pneumatiky. • Účet 602114 – na tento účet jsou naúčtovány výnosy za službu (doprava). • Účet 602103 – na tento účet jsou naúčtovány výnosy za službu (dobírka). Samotné účtování faktur je nastaveno dle legislativy a modifikováno v rámci mezí (analytickou částí učtu) účtárnou firmy. Výnosové účty jsou odděleny úmyslně, za účelem zjednodušení reportingu zůstatků na účtech. Po založení faktury jsou k dokladu také přiřazeny takzvané zprávy, které slouží k řízení následného zpracování. V případě SD faktury jsou zprávy využity k tisku faktury a odeslání emailu zákazníkovi. Na obrázku níže je k vidění část výtisku faktury k zakázce 7000323423.


Obr. 16

45

Výtisk SD faktury

Jakmile je odeslaná faktura a zaúčtované peníze na příslušných účtech, je zakázka ohodnocena statusem C (Kompletně zpracováno), tím je celý obchodní případ považován za ukončený. Případ je možné otevřít případnou reklamací nebo odstoupením od kupní smlouvy. Toto není tématem bakalářské práce, z důvodu přílišné podrobnosti a překročení maximálního rozsahu práce, bude toto téma vynecháno.

46

3.5.4


Nevýhody stávajícího řešení

Kapitola popisuje nevýhody stávajícího procesu. Nevýhody vyplynuly z reálného provozu v dané firmě. Absence systémového propojení při stornování objednávky Jakmile je objednávka v systému SAP vytvořena, odchází automatická zpráva dodavateli, který má zboží dodat. Tato automatická komunikace však není funkční při stornování objednávky. V reálném provozu to přináší mnoho operativního řešení formou mailů či telefonátů dodavateli, za účelem stornování objednávek. Chybné vyčíslení celkového doplatku za objednávku Jelikož je dodavatel sám jednotkou, která se stará o dodání zboží zákazníkovi (sjednává dopravu či sám zboží dováží), potřebuje znát částku, kterou musí za objednávku vybrat. Vyčíslení částky za objednávku však není triviální záležitost, jak by se mohlo zdát. Standardním postupem je odeslání částek pro jednotlivé položky za jeden díl měrné jednotky. Tyto jednotkové částky umožní zpracovávat objednávky po částech. Na požadavek dodavatele muselo být od tohoto řešení upuštěno a jsou přenášeny částky za celou objednávku. Důvodem, proč nejsou přenášeny i položkové údaje je ten, že dodavatel požaduje striktně jen zbožové položky, tedy pneumatiky. Nikoli však artikly, které představují služby (dobírka, doprava, likvidace starých pneumatik, apod.). Z výše uvedeného důvodu byl implementován algoritmus, který při vytvoření zprávy IDoc vyčíslí platbu za artikly služeb. Algoritmus je s počtem obchodovaného sortimentu a druhů artiklů služeb složitý a s příchodem druhého dodavatele stejného typu přestal fungovat. V provozu to znamenalo ztrátu peněz ze služeb, pokud si zákazník objednal pneumatiky od více dodavatelů. Finanční ztráta v tomto případě není malá, jelikož doprava za pneumatiky je násobena počtem kusů a pohybuje se v řádech stovek CZK. Formát zpracování dat od dodavatele Dodavatel poskytuje hromadné soubory s daty k potvrzení expedice a fakturaci. Je tedy nutné periodicky procházet jednotlivé soubory a odesílat data do SAP. Ve výsledku to znamená redundantní zpracování stejné informace a zbytečné zvětšování datového toku. Ignorování dat ze SAP Dodavatel přejímá data ze SAP v nejmenší možné míře, reálně to znamená, že není schopen poskytnout téměř žádné informace, které by byly provázané s objednávkou, tím pádem je velmi obtížné zpracování dat na straně SAP ERP.


47

Problematický monitoring zpracování datových vět Při odesílání objednávek je potřeba kontrolovat, zda dorazily do cílového systému, ale ve stávajícím řešení není možné kontrolovat, zda byla zpracována dodavatelem. Jediné, co bylo možné zjistit z monitoringu je, jestli objednávka dorazila na FTP.

48

Návrh

4 Návrh Tato kapitola se zabývá návrhem nového procesu prodeje pneumatik. Nový proces bude vycházet z nedostatků stávajícího řešení – viz kapitola 3.5.4. Nevýhody stávajícího řešení. Požadavkem je vytvořit proces, který bude eliminovat nedostatky stávajícího řešení, dále bude univerzální a splní integrační konvence.

4.1 Návrh řešení Návrh řešení absence systémového propojení při stornování objednávky Při stornování objednávky odběratelem (SAP) bude vytvořena nová zpráva, která dodavatele informuje o stornování jednotlivých položek objednávky. Struktura zprávy o stornování bude totožná jako při přenosu nákupní objednávky dodavateli. Dodavatel stornování objednávky identifikuje dle příznaku smazání položky. Stav, v jakém se objednávka nachází, nemění požadavky na komunikaci. SAP informuje dodavatele o stornu objednávky a dodavatel musí zajistit, že objednávku opravdu stornuje. SAP nebude zajímat, zda je objednávka vykryta částečně nebo již kompletně zabalena a připravena k expedici. Storno objednávky v systému musí zajistit dodavatel sám. Pokud už bude objednávka expedovaná, dodaná nebo v jakékoli další fázi životního cyklu objednávky, musí se storno provést manuálně s dohledem odpovědné osoby. Automatické zpracování stornování objednávky ze strany dodavatele není možné, jelikož nemůže být dovoleno, aby dodavatel zasahoval do nákupních dat v SAP. Návrh řešení chybného vyčíslení celkového doplatku za objednávku Bude upraven výpočet doplatků a zobecnění případů, jak má být částka za služby vyčíslena. Návrh řešení formátu zpracování dat od dodavatele Jednotlivé procesní entity (integrační scénáře) využijí technologie webových služeb respektive protokolu SOAP. Upustí se od hromadných souborů a každá jedna objednávka, faktura a expediční potvrzení budou zpracovány samostatně. Návrh řešení ignorování dat ze SAP Řešením pro nekompletní data od dodavatele budou právě webové služby. Jednotlivé datové věty korespondující mezi dodavatelem a firmou budou rozšířeny. Dodavatel tak získá větší informovanost o objednávkách. Webové služby volané s těmito daty značně zjednoduší a unifikují zpracování dat v SAP.

Návrh

49

Návrh řešení problematického monitoringu zpracování datových vět S implementací webových služeb bude v monitoringu na systému SAP PI viditelné, zda systém zprávu přijal a zpracoval, či nikoli.

4.2 Data flow diagram – návrh Následující diagramy popisují stav po implementaci, tak jak jej definuje kapitola 4.1. Návrh řešení.

Obr. 17

DFD – Firemní IS – nové řešení

Obrázek výše znázorňuje proces Firemní IS dle nového řešení. Byl vynechán externí sklad dat (FTP) a systém PI komunikuje přímo s dodavatelem formou webových služeb.

50

Obr. 18

Návrh

DFD – SAP PI – nové řešení

Obrázek výše zobrazuje proces SAP PI. Bylo upuštěno od externího úložiště dat (FTP), místo něj jsou zprávy přenášeny přímo skrze systém dodavatele. Každá jedna zpráva reprezentuje jeden doklad v systému ERP. Tímto bude výrazně snížen datový tok, který je nutné zpracovávat, zejména díky absenci periodického nahrávání souborů na externí úložiště s duplicitními daty.

Návrh

51

4.3 Testovací scénáře Tato kapitola definuje testovací scénáře pro komplexní otestování nové funkcionality. Důraz bude kladen na požadavky z kapitoly 3.5.4. Nevýhody stávajícího řešení. Testováno bude dynamickým postupem bílé skříňky (Patton, 2002), jelikož testovat bude samotný autor práce a tedy i programátor řešení. Sestavením testovacích scénářů před samotnou implementací je eliminováno riziko, že budou testy uzpůsobeny řešení tak, aby skončily kladně. 4.3.1

Testování obecné funkčnosti

Nejprve je nutné otestovat elementární funkčnost interface. Musí být zajištěny bezchybné přenosy jednotlivých zpráv (objednávky, expedice, fakturace). K otestování, že nebyla narušena původní funkčnost, budou využity produkční objednávky, vytvořené ze zakázek zákazníků. 1. Odeslání objednávek – u každé jedné objednávky bude zkopírována původní zpráva, která přenesla data k dodavateli. Tato zpráva obsahuje kompletní informace o objednávce (formát IDoc). Potřebná data k naplnění dodavatelského portálu jsou k dispozici a mapování na straně PI zajistí přenos dat v definovaných strukturách webové služby. Musí dojít ke kompletnímu přenosu dat a založení objednávek u dodavatele. 2. Příjem potvrzení expedice – u každé objednávky v dodavatelském portálu bude spuštěna funkcionalita zajišťující přenos informace o potvrzení expedice. Na straně dodavatelského portálu bude naplněna struktura webové služby a odeslána na port systému PI. PI musí tyto zprávy korektně přemapovat a sestavit z nich zprávy ve formátu IDoc. Jednotlivé zprávy budou následně odeslány do ERP ke zpracování. Všechny zprávy IDoc musí skončit statusem 53 (Aplikační doklad zaúčtován). 3. Příjem dodavatelských faktur – obdobně jako u funkcionality potvrzení expedice, musí být zprávy k objednávkám z dodavatelského portálu korektně sestaveny a přeneseny do systému PI. SAP PI zprávy opět mapuje do formátu IDoc. Zprávy IDoc musí mít v systému SAP ERP status 53. 4.3.2

Storno objednávky ze strany SAP

Storno v SAP je provedeno znakem výmazu na jednotlivých položkách nákupní objednávky. Jakmile budou takovéto změny provedeny, SAP automaticky vytvoří novou zprávu, která odešle dodavateli informace o objednávce. Testováno bude na objednávkách použitých při testování obecné funkčnosti komunikace. V rámci testu budou stornovány objednávky s jednou a více položkami. Systém musí automaticky vygenerovat novou zprávu a odeslat do systému PI, který následně odešle XML zprávu do webové služby dodavatele. Dodavatel informaci

52

Návrh

o stornování musí převzít a naložit s ní dle interních procesů dané firmy (pravděpodobně rozeslání informace správcům objednávek). 4.3.3

Vyčíslení doplatku

Vyčíslení doplatku není možné korektně otestovat pouze na objednávkách s pneumatikami. Algoritmus vyčíslující doplatek vždy zahrne cenu za zbožové položky, nicméně službové položky musí být započteny pouze jednou a to dle priorit, jaký sortiment je objednán v zakázce. V rámci korektního otestování budou vytvořeny zakázky, které kombinují obchodovaný sortiment. Integrační scénáře budou obsahovat zakázky: 1. Pneumatiky od jednoho dodavatele 1.1. Platba dobírkou – doplatek by měl být vyčíslen na plnou částku zakázky. 1.2. Platba při převzetí na prodejně – doplatek by měl být nulový, zboží bude uhrazeno při převzetí zboží na prodejně. 2.

Pneumatiky od více dodavatelů 2.1. Platba dobírkou – tento scénář je nejexponovanějším, jelikož právě zde je problém v původním řešení. Cena za službové artikly, tedy musí být za celou zakázku započtena právě jednou. Nehraje roli, od jakého dodavatele (resp. dopravce sjednaného dodavatelem) bude vybrána.

3.

Pneumatiky + nábytek 3.1. Platba dobírkou – doplatek za zbožové artikly musí být započten na obou objednávkách a tím pádem bude vybrán oběma dopravci sjednanými dodavatelem. Cena službových artiklů bude vybrána dopravcem, který doručí pneumatiky. Dopravné za pneumatiky má vyšší prioritu (je to dáno cenou, která je počítána jako suma za každý kus pneumatik) nad dopravným za nábytek.

4.

Pneumatiky + elektronika 4.1. Platba dobírkou – dopravce doručující pneumatiky by měl vybrat cenu za zbožové položky a zároveň i cenu za službové artikly. Dopravce doručující elektroniku vybere pouze cenu zbožových artiklů.

5.

4.2. Platba při vyzvednutí na prodejně – ani jeden dopravce nesmí vybrat žádnou částku, zakázka bude uhrazena na prodejně. Pneumatiky + nábytek + elektronika 5.1. Platba dobírkou – dopravce doručující pneumatiky by měl vybrat cenu za zbožové položky a zároveň i cenu za službové artikly. Dopravce doručující elektroniku a nábytek vybere pouze cenu zbožových artiklů. 5.2. Platba při převzetí na prodejně – žádný z dopravců nesmí být informován o vybrání dobírky, zakázka bude uhrazena na prodejně.

Doplatek je přenášen do externího systému, kde neexistuje žádná zpětná kontrola, zda je cena správná. Z tohoto důvodu musí být výpočet bezchybný. Hlavní důraz je

Návrh

53

kladen na otestování částky doplatku, pokud by byl doplatek za službové artikly vybrán jiným expedičním kanálem (dopravcem), nebude tato nuance brána za hrubou chybu. 4.3.4

Formát dat od dodavatele

V tomto testovacím scénáři bude zhodnocena kvalita dat. Datové věty musí být úplné a zároveň neredundantní. Zprávy musí být odděleny a zpracovány jako jednotlivé požadavky, nesmí být zachováno původní řešení, tzn. hromadné zprávy zapříčiňující redundantní zpracování již vyřízených požadavků. 4.3.5

Monitoring zpráv

SAP PI obsahuje poměrně rozsáhlý systém monitoringu zpráv, který je rozdělen mezi část ABAP i část JAVA. V monitoringu musí být viditelné stavy přenosů jednotlivých zpráv. To znamená, že jakmile bude jakýkoli problém v přenosu a zpracování, musí být chyba vidět v některém z monitorovacích nástrojů podle případu a integračního scénáře. Testovány budou následující varianty. 1.

Nedostupnost dodavatelského portálu – test ke zjištění, jakým statusem bude ohodnocena zpráva, pokud je příjemce, tedy dodavatelský portál nedostupný. V monitoringu musí být viditelné, že se interface nedokázal spojit se vzdáleným serverem.

2.

Nedostupnost systému SAP ERP – test tohoto bodu není možné provést v plné výši, autor práce není oprávněný k vypnutí celého systému. K simulaci chybového stavu bude zpráva odeslána do systému ERP jako zpráva od neexistujícího dodavatele (logického systému).

3.

Nedostupnost systému SAP PI – na straně ERP je tento stav symbolizován chybovým statusem zprávy IDoc.

4.

Chybná struktura zprávy – jakmile bude neočekávaně sestavena XML struktura a mapovací program nebude schopen interpretovat data k transformaci do cílové struktury, musí být možnost nalézt nezpracované zprávy a analyzovat chybu. Tento stav bude simulován ručním upravením datové věty tak, aby nesplňovala definici v dokumentu WSDL nebo syntaxi IDoc.

54

Implementace

5 Implementace Kapitola se zabývá implementací komunikace a celého procesu na základě návrhu, který byl popsán v předchozích kapitolách.

5.1

Použité technologie

Jádro celé komunikace je postaveno na protokolu SOAP, který tvoří základní stavební kámen komunikace pomocí webových služeb. Pro implementaci celého procesu byly použity následující jazyky. • • • • • •

ABAP PHP HTML CSS XSLT SQL

Jednotlivé jazyky spolu spolupracují a byly zvoleny na základě analýzy a konvencí SAP. Dále byly využity následující databázové systémy. • Oracle – využita v systému SAP ERP • MySQL – využita v dodavatelském portálu (databáze bude popsána v dalších kapitolách)

5.2 Dodavatelský portál Není možné požadovat po dodavatelích úpravu jejich systému. Z toho důvodu byl implementován zjednodušený dodavatelský portál, který supluje dodavatelskou část. Portál je spuštěn na vzdáleném serveru. Dodavatelský portál byl vytvořen v jazyce PHP společně s HTML a CSS. Poskytuje pouze omezené množství funkcí. • Vytvoření objednávky • Zobrazení objednávek v systému • Expedici zboží z objednávky • Fakturace objednávky Data dodavatelského portálu jsou uložena v databázovém systému. 5.2.1

MySQL databáze

Jednotlivé operace v systému (zákazníci, objednávky, dodávky, faktury, artikly a uživatelé), jsou udržovány v databázi. Tabulky funkčních celků (objednávek, dodávek, faktur) jsou rozděleny na hlavičkové a položkové tabulky, které jsou mezi

Implementace

55

sebou provázány cizími klíči. Struktura databáze je popsána ERD diagramem, který je přiložen v příloze C. ERD – Dodavatelský portál. 5.2.2

Funkce dodavatelského portálu

Dodavatelský portál (dále jen DP) sdružuje objednávky ze systému SAP a umožňuje s nimi provádět určité operace. Objednávky jsou do dodavatelského portálu přenášeny ze systému SAP ERP skrze systém SAP PI. DP implementuje webovou službu createOrder (bude popsána níže), která slouží k založení objednávky do systému. Tento krok se děje bez vědomí uživatele a je prováděn na pozadí. Pro přístup do funkčních částí DP je nutná autentizace. Uživatel má své přihlašovací jméno a heslo, bez kterého nemůžu využívat žádných funkcí. Uživatelé jsou udržováni v databázi v tabulce users. Hesla jsou šifrována funkcí MD5 a i takto jsou uložena v databázi. Po přihlášení, jsou uživateli zobrazeny objednávky v systému. Ukázka UI je přiložena v příloze D Ukázka dodavatelského portálu. U každé objednávky je zobrazen status, ve kterém se objednávky nachází. Systém nedovolí provádět operace, které jsou nestandardní k danému stavu. Například nedovolí vyfakturovat stornovanou objednávku. Tlačítka, která jsou dostupná u každé objednávky, slouží k iniciaci dané operace. Po zmáčknutí tlačítka je spuštěn PHP skript, který metodou GET přebírá informaci o objednávce, jež má zpracovat. Z důvodu bezpečnosti, byla do skriptů implementována kontrola na přihlášení uživatele. Důvodem této kontroly je nebezpečí, zjištění URL adresy skriptu a následně jeho zneužití. Pokud skript spustí nepřihlášený uživatel, je explicitně přesměrován na skript autentizace. Další bezpečností opatření, které je implementováno ve skriptech, je kontrola stavu objednávky. Metoda GET není nejbezpečnější formou předávání dat mezi skripty, nicméně za předpokladu, že skript může využívat pouze přihlášený uživatel, je možné tuto metodu využít, pouze s mírným zabezpečením. Kontrola slouží ke zjištění, zda je objednávka relevantní k operaci, kterou daný skript provádí. V opačném případě je uživatel přesměrován na úvodní obrazovku s chybovou hláškou, že operace nemůže být provedena. 5.2.3

Webové služby

WS – createOrder Tato služba slouží k založení objednávky na straně dodavatele, na základě objednávky ze systému SAP. Služba je vystavena na serveru firmy S2EP, jako služba typu server. Vstupním parametrem je element order, který obsahuje informace o objednávce, je datového typu OrderType – struktura bude k nalezení níže, v kapitole zabývající se integračním scénářem v systému SAP PI. Webová služba obsahuje funkci createOrder, která zajistí zpracování dat. Na začátku je struktura rozparsována na dílčí části tj. odběratel, hlavička objednávky

56

Implementace

a položky objednávky. Následně funkce analyzuje, zda již objednávka neexistuje a nejedná se o její storno. Pokud ano, funkce do databáze aktualizuje znaky storna na jednotlivých položkách objednávky (pokud jsou stornovány všechny položky, nastaví se také znak storna na hlavičce objednávky) a zpracování úspěšně ukončí. V případě nové objednávky jsou jednotlivé dílčí části zpracovány a uloženy do databáze v pořadí odběratel (tabulka customer) – hlavička objednávky (tabulka order) – položky objednávky (tabulka orderItems). Pokud se nějaká operace neprovede, jsou všechny záznamy k dané objednávce smazány a zpracování je ukončeno s chybou. WS – StockOutInfo Služba StockOutInfo je webová služba typu client, která přenáší data o expedici objednávky z DP do systému SAP PI a následně do SAP ERP. Systém SAP PI se nachází v zabezpečené firemní síti, která má definované IP adresy, jež mají přístup. Pro přístup k webové službě, která je dostupná na veřejné ip adrese serveru SAP PI bylo nutné zřídit prostupy do firemní sítě. Zde nastal značný implementační problém, jelikož server na, kterém je spuštěn DP má dvě ip adresy (vstupní a výstupní) a bez povolení obou se do firemní sítě nebylo možné připojit. Tato skutečnost nebyla patrná na první pohled a hledání chyby zabralo mnoho času. Webová služba StockOutInfo je spouštěna ze skriptu stock_out_info.php a předchází ji několik operací. Skript má na vstupu číslo objednávky, a po bezpečnostních kontrolách načte data o objednávce z databáze. Následně jsou data zpracována a překlopena do dodávky, která je uložena do databáze (tabulky delivery, deliveryItems). Z dodávky je poté vytvořena XML struktura popsaná ve WSDL a odeslána webovou službou do systému SAP PI, kde je zpracována do IDoc a přenesena do systému SAP ERP, kde je interpretována jako přijímaná dodávka. WS – InvoiceData Služba InvoiceData je webová služba typu client. Slouží k přenosu faktury za objednávku od dodavatele, respektive z DP do systému SAP ERP přes systém SAP PI. Webová služba je iniciována ze skriptu invoice.php, který je spuštěn po kliknutí na tlačítko fakturace v úvodní části DP. Po spuštění skriptu jsou provedeny bezpečnostní funkce a následně jsou načtena data z databáze. Logika skriptu je totožná jako v případě služby StockOutInfo, nicméně struktura faktury je složitější a její zpracování náročnější. Faktura je uložena do databázových tabulek invoice a invoiceItems. Zpracování pokračuje tvorbou XML struktury, která je opět popsaná v souboru WSDL uloženém na serveru. Po odeslání zprávy do systému SAP PI, je zpráva přemapována do struktury IDoc a odeslána do systému ERP, kde vytváří objekt předběžně pořízená faktura.

Implementace

57

5.3 SAP PI Integrační scénáře budou popsány ze strany firmy, tedy SAP. Veškeré scénáře využívají modul SAP PI. Komunikace s dodavatelským portálem využívá technologií webových služeb, respektive protokolu SOAP. SAP ERP komunikuje pomocí technologie IDoc, tzn. veškeré zprávy jsou v systému SAP ERP interpretovány jako IDoc. Z důvodu přesažení maximálního rozsahu práce a přílišné podrobnosti bude popsán pouze jeden integrační scénář. 5.3.1

Založení komunikačního uživatele

Komunikační uživatel je nutný pro přístup do systému cizím systémem. Přístup ze systému SAP ERP je již zajištěn, skrze uživatele ERP_USER. V tomto projektu je však nutné přistupovat do systému SAP PI i z externího systému (Dodavatelský portál). Za tímto účelem byl založen uživatel BP_TEST, který je typu communication data. Tento typ je určen pouze pro komunikační kanály a z bezpečnostních důvodů se přes něj do systému nelze přihlásit. Uživatel obsahuje pouze jedno oprávnění, respektive roli – SAP_XI_APPL_SERV_USER. 5.3.2

System Landscape Directory

System Landscape Directory (dále jen SLD) je vývojovou komponentou, která je nedílnou součástí před tvorbou integračních scénářů s novými systémy. SLD spravuje informace o všech systémech a produktech jednotlivých systémů. U nových implementací, respektive nových systémů, je nutné tyto komponenty tzv. registrovat. Nastavení SLD je provedeno na webovém portálu SAP PI, skrze který je přistupováno do JAVA části systému. Spuštění webové aplikace je prováděno přímo z ABAP části PI skrze transakci SXMB_IFR. Základní funkcionalita je rozdělena do tří samostatných aplikací, které spolu spolupracují. Technical Systems Prvním krokem v nastavení SLD je definice technického systému. Technický systém reprezentuje samotný systém nebo server. Obsahuje obchodní systémy a softwarové komponenty. Založení technického systému je provedeno pomocí webového průvodce. Na první obrazovce je nutné vybrat typ systému, který má být založen. Dodavatelský portál je cizím systémem (ne SAP systém), proto je technický systém založen jako systém třetí strany. Další obrazovkou je vynuceno pojmenování technického systému, systém byl založen pod názvem BP_TEST bez přiřazených business systému a produktů.

58

Implementace

Business Systems Založením Obchodního systému pokračuje proces nastavení SLD. Obchodní systémy jsou reprezentovány jako vysílače a přijímače a jsou přiřazeny vazbou 1:1 k technickému systému. Založení je opět provedeno ve webovém průvodci. Obchodní systém použitý v této práci je založen jako systém třetí strany, přiřazený pod technický systém BP_TEST. Důležité je přiřazení systému pod skupinu. Skupina se využívá k oddělení testovacího systému od produkčního systému a umožňuje přednastavit transport. Jakmile je scénář dokončen a transportován z vývojového systému do testovacího nebo produkčního systému, je vhodné automaticky změnit názvy systému na produkční. Změnu zajistí nastavení skupiny a obchodního systému, do kterého se má testovací systém překlopit. Nastavení business systému obsahuje specifikaci logického systému, který bude příjemcem a odesílatelem zpráv v systému ERP, tento údaj byl vyplněn logickým systémem BP_TEST, který bude popsán níže. Název systému byl zvolen BP_TEST a do produkce bude překlopen pod názvem BP_PROD. Nastavení obchodního systému je automaticky importováno do aplikace Integration Builder, která bude popsána v kapitole 5.3.4. Integrační scénáře – Integration Directory, kde jsou modelovány komunikační kanály integračních scénářů. Software Components Softwarové produkty jsou posledním krokem v registraci systému v SLD. Jednotlivé produkty reprezentují aplikace v systému (může být na systém nahlíženo jako na jedinou aplikaci). Založit produkt je možné jako novou verzi nějakého stávajícího produktu nebo nový produkt. Aplikace prodeje pneumatik je novým produktem a je tedy založena jako nová softwarová komponenta technického systému BP_TEST. Komponenta byla založena pod názvem BP_IPNEU verze 1.0.

Implementace

5.3.3

59

Integrační scénáře – Integration Repository

Implementace integračního scénáře dále pokračuje v JAVA aplikaci Enterprise Service Builder (dále jen ESB), která je součástí JAVA PI Tools. Aplikace je samostatnou komponentou PI, ale přistupuje přímo do systému PI. Aplikace ESB slouží k definování transformace dat mezi jednotlivými technickými systémy a jejich softwarovými komponentami. V této části systém ani implementátora nezajímá, jakou metodou či protokolem bude integrační scénář komunikovat. Obecně je řešena struktura vstupní zprávy a výstupní zprávy a operace při transformaci. Kam a jakým způsobem mají být data přenesena, je řešeno v kapitole 5.3.4. Integrační scénáře – Integration Directory. Použitými objekty ESB jsou: • External Definitions – slouží k definování struktury zprávy externím dokumentem (WSDL, XSD). • Message Mappings – využívá se k mapování jednodušších zpráv. • Imported Archives – slouží k importu archivu mapovacích skriptů v jazyce XSLT. • Operation Mapping – definuje, jaká zpráva má být mapována, do které a jakým mapovacím programem. • Service Interfaces – vytváří interface, který spojuje jednotlivé komponenty. OrderData Integrační scénář OrderData slouží k přenosu dat objednávky ze systému SAP ERP do systému dodavatele. Dodavatel nepotřebuje a ani nevyžaduje všechna data ze vstupní zprávy, současně je vstupní zpráva formátu IDoc, ale dodavatel očekává zprávu ve formátu XML. Je nutné definovat struktury jednotlivých zpráv a následně vytvořit mapovací program, který transformuje vstupní zprávu do výstupní. Vstupní zpráva je ve formátu IDoc, proto ji není potřeba definovat, systém již tuto definici obsahuje. Definice je nutná u výstupní zprávy, která byla definována autorem práce. Zpráva je popsána standardním souborem WSDL, který slouží k definici webové služby. Popis byl vygenerován webovou službou typu server na straně dodavatele. Struktura je popsána obrázkem níže.

60

Obr. 19

Implementace

Struktura výstupní zprávy OrderData

Po definování struktury systém vyžaduje určit transformaci dat. V tomto případě bude využito importu archivu XSLT transformace. Integrovaný mapovací systém Message Mapping je nepříliš pružný a takováto transformace by byla velice složitá. Skript je přiložen v příloze B. XSLT – OrderData. Nyní jsou známy obě struktury zpráv a je vytvořen mapovací program, který zprávy transformuje. Toto nastavení je nutné definovat v objektu Operation Mapping.

Implementace

Obr. 20

61

Operation Mapping – OrderData

Operation Mapping na obrázku Obr. 20 zobrazuje postup mapování zdrojové zprávy ORDERS.ORDERS05 do cílové zprávy createOrderRequest za použití mapovacího programu typu XSL. Posledním krokem v ESB je vytvoření objektu Service Interface, který zjednodušeně slouží k definování směru přenosu a určení, zda bude interface synchronní či asynchronní. Rozhraní SI_OrderData je nastaveno jako asynchronní interface typu inbound. Tímto je integrační scénář v ESB dokončen a je nutná aktivace změn. Zbylé nastavení je provedeno v aplikaci Integration Builder. 5.3.4

Integrační scénáře – Integration Directory

Integration Directory je komponentou PI, která slouží ke konfiguraci obchodních procesů specifikovaných v ESB. Konfigurace je prováděna v JAVA aplikaci Integration Buider (dále jen IB). Aplikace slouží k nastavení směrování zpráv, přenosových technologií a také definici výběru mapovacích metod. Pro potřeby této práce byly využity následující objekty: • Configuration Scenario – slouží k seskupení objektu jednotlivých integračních scénářů • Communication Channel – definuje typ adaptéru pro přenos (FILE, SOAP, JDBC,…)

62

Implementace

• Receiver Determination – slouží k routování – určení jednoho nebo více příjemců (receiver) pro konkrétní kombinaci odesílatele (sender) a rozhraní (Service Interface) • Interface Determination – určuje, která rozhraní by měla být použita pro příchozí zprávy a jak mají být mapovány. • Receiver Agreement – definuje vazbu mezi přijímacím komunikačním kanálem a příchozím rozhraním s vazbou na odesílatele. • Sender Agreement – definuje vazbu mezi komunikačním kanálem odesílatele a odchozím rozhraním. IS2SOAP_IOBP001_CreateOrder Samotnou tvorbu routování integračního scénáře předchází přiřazení nového business systému. Systém je přiřazen z SLD, kde musí být definován. Vhodným postupem pro tvorbu integračního scénáře v IB je vytvoření objektu Configuration scenario, který slouží k seskupení všech objektů daného scénáře. V opačném případě se i při malém množství scénářů stává prostředí IB nepřehledné a analýza scénářů se stává nekonečná. Prvním objektem, který je nutné vytvořit a přiřadit do konfiguračního scénáře je objekt Communication channel. Komunikační kanál je specifický pro business systém. Komunikační kanál bude nést název IS2SOAP_IOBP001_CreateOrder pro naprostou specifikaci již z textu. Komunikační kanál je nastaven jako kanál protokolu SOAP client, tedy webová služba, která volá SOAP action http://okay.s2ep.cz/create_order.php/createOrder vystavené služby SOAP server na adrese http://okay.s2ep.cz/create_order.php. Dalším nutným objektem je Receiver determination, kde je definováno, jaký odesílatel je za jakých podmínek směrován na jakého příjemce. Odesílatelem je nastaven business systém C15CLNT300, který prezentuje testovací systém ERP. Příjemce je nahrazen zástupným znakem *, který nespecifikuje přesného příjemce a umožní využít dynamického přiřazení příjemce dle logického výrazu. Receiver determination již byl stávající funkcionalitou systému PI pro ostatní přenosy objednávek z firemního testovacího systému. Byla přidána podmínka, která přebírá nastavení ze vstupní zprávy IDoc, která sebou nese informace o logickém systému, kam má být zpráva přenesena tzn., že každá zpráva bude předána business systému BP_PNEU, který je také nastaven v IDoc. V aplikaci ESB byla definována operace mapování pro převod zpráv z formátu IDoc do XML (SOAP). Pro určení, jaká operace má být pro který systém využita, slouží objekt Interface determination. Interface determination určuje vazbu rozhraní odesílatele k příjemci a dle logické podmínky určuje operaci mapování. Zde nebyla využita žádná podmínka, tzn. mapování bude probíhat pokaždé stejně. Posledním nutným objektem je Receiver agreement, který je nastaven mezi odesílatelem C15CLNT300 a rozhraním SI_OrderData příjemce BP_TEST za použití komunikačního kanálu IS2SOAP_IOBP001_CreateOrder.

Implementace

Obr. 21

63

Configuration scenario – CS_IOBP001_CreateOrder

Na obrázku výše je kompletní nastavení integračního scénáře v konfiguračním scénáři. Aktivací vytvořených objektů je scénář v rámci PI kompletní a funkční. Aby byly objednávky směrovány do systému SAP PI, je nutné nastavit systém SAP ERP. Nastavení bude popsáno v kapitole 5.4. SAP ERP.

5.4 SAP ERP Tato kapitola pojednává o nastavení, které je potřeba implementovat v systému ERP. Nastavení jednotlivých operací jsou natolik obsáhlá, že v rámci této práce budou omezena na minimum potřebné k pochopení operací samotných. Z důvodu přesažení maximálního rozsahu práce a přílišné podrobnosti budou některé hluboké detaily vynechány. 5.4.1

Vytvoření dodavatele

Pro simulování obchodního procesu je nutné v systému vytvořit dodavatele. Dodavatel slouží jako entita, od které se objednává zboží, vytváří finanční účet, na který se účtují platby, a mnoho dalšího. Dodavatel se zakládá v transakci XK01 a nastavení je závislé na účetním okruhu a nákupní organizaci. Samotná transakce a proces skrývající se za ní, obsahuje mnoho pohledů a nastavení, které je nutno vyplnit. Pro tuto práci je stěžení nastavení pohledu Nákupních dat, kde jsou obsaženy informace, jak se má systém chovat při příjmu zboží, jaké jsou plánované dodací lhůty dodavatele, dále také, zda je k objednávce plánována likvidace faktur a další.

64

Obr. 22

Implementace

Založení dodavatel – Nákupní data

Nastavení zbylých pohledů – adresa, řízení, platební styk, kontaktní osoba, vedení účtu, korespondence a partnerské role byly převzaty a pozměněny z již funkčního dodavatele dodávající zboží na produkčním systému. Dodavatel byl založen pod číslem 10004269 a názvem BP Vendor s.r.o. 5.4.2

Vytvoření partnerské dohody

Partnerská dohoda je nastavení ALE/EDI komunikace pro určité partnery. Partnerem nemusí být pouze dodavatel ale také například banka, logický systém a další. Partnerská dohoda definuje, jaké zprávy mohou s partnerem komunikovat. Nastavení je oddělené pro vstupní a výstupní zprávy. Pro údržbu partnerských dohod slouží transakce WE20. Partnerská dohoda reprezentující dodavatele 10004269 musí být založena jako logický systém. Logické systémy jsou spravovány v transakci BD54 a právě tento krok musí předcházet samotné založení partnerské dohody.

Implementace

Obr. 23

65

Partnerská dohoda BP_TEST

Obrázek výše zobrazuje nastavení partnerské dohody BP_TEST. Název BP_TEST byl zvolen dle konvence _. Pokud by byl vývoj transportován do produkčního systému, pak by se partnerská dohoda jmenovala BP_PROD.

66

Implementace

Partnerská dohoda definuje vstupní i výstupní zprávy. • Výstupní zprávy o ORDERS je zprávou objednávky. Reprezentuje data objednávky, která mají být přenesena do logického systému (dodavateli). důležitým nastavením zprávy je kód operace, který má zpráva plnit. Zpráva byla nastavena pro dvě operace: ME10 (založení objednávky) a ZME11 (změna objednávky). Právě operace ZME11 zajistí, že při stornování objednávky se vygeneruje nový (změnový) IDoc, který informuje dodavatele o stornu. Operace ZME11 bude popsána níže. typ IDoc – ORDERS05 • Vstupní zprávy o DESADV je zpráva, která avizuje expedici a umožní příjem zboží. Nese informace o zboží a jeho množství, které bude/bylo expedováno dodavatelem. zakládá objekt Přijímaná dodávka (zobrazitelný v transakci VL33N) kód operace – DELS o INVOIC nese informace o faktuře, kterou odesílá dodavatel k proplacení. zakládá objekt Předběžně pořízená faktura (zobrazitelný v transakci MIR6) kód operace – ZINVL Pro každou zprávu je nutné nastavit, kam má být předána nebo jak má být zpracována. • Výstupní zprávy o jsou směřovány na port XI_BRIDGE, který zajistí přenos do systému SAP PI (dříve nazývaný XI). o musí být nastaveno jakým typem IDoc budou data předána. • Vstupní zprávy o definují, jakou operací bude zpráva zpracována. Operace v sobě nese informaci o funkčním modulu, který převezme data z IDoc a provede požadované kroky v systému (založení přijímané dodávky, založení předběžně pořízené faktury). Po vytvoření partnerské dohody zbývá propojit dodavatele s partnerskou dohodou. Tento krok je nezbytný zejména pro výstupní zprávy a slouží k němu transakce NACE. Transakce NACE slouží k řízení zpráv. Zprávy mohou být generovány aplikacemi na základě definovaných parametrů. Aplikacemi jsou myšleny skupiny objek-

Implementace

67

tů například prodej, expedice, fakturace dále také nákupní objednávka a další. Pro každou zprávu pak jsou nastaveny operace, které je schopna plnit (tisk, odeslání emailu, odeslání faxu, ALE, EDI a další). Pro zajištění přenosu zprávy objednávky do vzdáleného systému je nutné nastavit aplikaci EF (Nákup – objednávka). Aplikace obsahuje množství standardních i nestandardních zpráv, které jsou generovány právě objednávkami. SAP standard obsahuje zprávu NEU, která slouží k přenosu objednávek. Aby systém automaticky přiřadil zprávy k objednávce, je nutné použít takzvané podmínkové záznamy. Podmínkové záznamy jsou dále rozděleny takzvaným pořadím přístupu, kde jsou definované pole pro třídící kritéria objednávek. Pro korektní nastavení zprávy NEU je nutné pro nákupní organizaci 1000 přiřadit dodavatele 10004269, komunikujícího skrze logický systému BP_TEST. Odesílací médium musí být EDI (Electronic data interchange).

Obr. 24

Podmínkový záznam zprávy NEU

Takto nastavená partnerská dohoda spolu s nastavením řízení zpráv zajistí korektní přenosy z ERP do PI. 5.4.3

Vytvoření operace ZME11

Operace slouží k určení, za jakých podmínek a jakým funkčním modulem bude IDoc vytvořen. Standardní operace ME11 (ORDCHG: Změna objednávky) nesplňuje požadavky určené v kapitole 4.1. Návrh řešení o stornování objednávky. Operace ME11 nevytvoří změnový IDoc v případě stornování položek, a právě tato funkcionalita je žádaná. Pro implementaci funkcionality byl v transakci SE37 vytvořen funkční modul ZPC01_IDOC_OUTPUT_ORDCHG, který je kopií standardního funkčního modulu. Ke každému funkčnímu modulu musí být přiřazena tzv. Skupina funkcí. Pro kopii funkčního modulu není možné využít standardní skupinu funkcí, proto byla vytvořena nová skupina funkcí ZPC01ITCZ_EINM, která obsahuje podprogramy standardní skupiny funkcí s přidaným podprogramem ZBELEG_LESEN. Podprogram ZBELEG_LESEN je modifikací podprogramu BELEG_LESEN, který byl využit v původním funkčním modulu a obsahuje přidanou funkcionalitu pro tvorbu IDoc se stornovanými položkami. Vytvořený funkční modul, je nutné přiřadit pod kód operace. K vytvoření operace slouží transakce WE41, ve které byla vytvořena již zmíněná operace ZME11.

68

5.4.4

Implementace

Nastavení dodavatelské fakturace

Nastavením partnerské dohody se zajistí přenosy zpráv do systému ERP, nicméně zpracování samotného IDoc INVOIC je podmíněno customizací EDI fakturace. Vstupy do systému jsou vždy rizikem, zejména pokud se jedná o finance. Z toho důvodu v SAP existuje funkcionalita, která definuje, jaká data partner může odeslat do systému ERP. Hlavní nastavení je provedeno v transakci OBCE, kde je definováno, jaký partner může zasahovat do kterého účetního okruhu. Pro každý tento záznam jsou specifikována přenosová data a data pro účtování. Nastavení obsahuje přesné účty a účtové klíče, které jsou přeneseny do předběžně pořízených faktur. Partner BP_TEST tedy bude používat účetní doklad DA pro fakturu a DG pro dobropis. Druhy dokladů jsou dány účtárnou. Další nastavení je provedeno v transakci OBCD, která slouží k překladu sazby daně do interního znaku daně. Pro partnera BP_TEST bylo přidáno nastavení umožňující zakládat faktury se sazbou daně 21%, která je interně vedena jako znak daně H9. Nastavení v transakci OBCA zajišťuje překlad názvu účetního okruhu ve faktuře (odesílané dodavatelem) do interního účetního okruhu. Všechna nastavení spojená s dodavatelskou fakturací jsou nutností a bez nich dodavatel není schopen faktury založit. Takto založené faktury se nazývají předběžně pořízené faktury a jsou připraveny v transakci MIR6 k jejich manuálnímu zpracování a zaúčtování likvidátorem faktur. 5.4.5

Zapnutí logiky závozu třetí stranou

Závoz třetí stranou není standardní funkcionalitou systému SAP, proces byl vytvořen tzv. zákaznickým vývojem. Zda bude zboží zavezenou třetí stranou, je definováno na kartě materiálu pomocí pořadače. Pro danou pobočku odběru musí být nastaven dodavatel jako hlavní – aktuální. Současně je nutné vložit dodavatele do customizační tabulky ZWS_LIFNR_ETTYP, která je použita v programu SAPFV45E pro řízení výběru druhu rozvržení. Samotná funkcionalita má hlubší základ i v nastavení standardu, nicméně z pohledu aktivace funkce pro nového dodavatele stačí pouze nastavení dodavatele do zákaznické customizační tabulky. 5.4.6

Algoritmus vyčíslení celkového doplatku za objednávku

Doplatek je částka, kterou musí dodavatel (dopravní společnost) od zákazníka vybrat. Chyba ve vyčíslení byla popsána v kapitole 3.5.4. Nevýhody stávajícího řešení. Logika výpočtu je umístěna v systému SAP ERP. Vyčíslení doplatku je umístěno do procesu vytvoření nákupního IDoc (ORDERS05). SAP standard obsahuje body rozšíření, do kterých lze uzavírat části zákaznického vývoje. ABAP kód vyčíslující doplatek je umístěn v includu ZXM06U02, který je součástí rozšíření MM06E001 pod exitem EXIT_SAPLEINM_002 v programu SAPLEINM. Exit slouží k modifikaci dat v segmentech IDoc.

Implementace

69

Níže je uvedena ukázka ABAP kódu, který korektní výpočet provede. Ukázka byla vybrána z části kódu, který byl v rámci této práce měněn. Pro zmenšení obsahu ukázky byly vynechány deklarace proměnných. Kompletní zdrojový kód je přiložen v příloze – viz kapitola A Zdrojový kód vyčíslení doplatku. * Načtení kategorií zboží pneumatik. Kategorie jsou udržovány v * customizační tabulce ZWS_PNEU_MATKL. V cyklu jsou procházeny všechny * položky zakázky s typem položky HAWA za účelem zjištění počtu kusů * pneumatik a v případě že se na zakázce nachází i jiná položka než * pneumatika logika vyčíslení se chová jinak. Proměnná lv_menge_zak * bude obsahovat počet kusů pneumatik na zakázce SELECT * FROM zws_pneu_matkl INTO TABLE lt_pneu_matkl. SORT lt_pneu_matkl. LOOP AT lt_info INTO ls_info WHERE mtart EQ 'HAWA'. READ TABLE lt_pneu_matkl WITH KEY matkl = ls_info-matkl TRANSPORTING NO FIELDS BINARY SEARCH. IF sy-subrc EQ 0. ADD ls_info-kwmeng TO lv_menge_zak. ELSE. lv_njn3s = 'X'. ENDIF. ENDLOOP. * Pokud je podmínka vyhodnocena jako true zákazník si objednává pouze * pneumatiky. Proměnná lv_menge_obj bude obsahovat počet kusů * pneumatik na objednávce. IF lv_njn3s IS INITIAL. LOOP AT xekpo. ADD xekpo-menge TO lv_menge_obj. ENDLOOP. * Z customizační tabulky ZR025 jsou selektovány artikly, jejichž cena * je kusově závislá a má být rozdělena do jednotlivých objednávek. * Artikly jsou příkazem SPLIT uloženy do záznamů interní tabulky, * ze které je posléze vytvořena proměnná typu RANGES pro elegantní * vyhledávání SELECT SINGLE value FROM zr025 INTO lv_value2 WHERE area = 'ZSLUZ_PNEU' AND name = 'MATNR'. IF sy-subrc EQ 0 AND NOT lv_value2 IS INITIAL. SPLIT lv_value2 AT ';' INTO TABLE lt_matnr. r_matnr-sign = 'I'. r_matnr-option = 'EQ'. LOOP AT lt_matnr. r_matnr-low = lt_matnr-matnr. APPEND r_matnr. ENDLOOP.

70

Implementace

* * * * *

Pro všechny položky zakázky druhu položky DIEN (služba) je z tabulky podmínek (KONV) načtena částka doplatku. Ceny jsou posleze rozděleny do proměnné lv_kbetr_s (cena, která bude rozpočítána dle kusů objednávky) a proměnné lv_kbetr_se (cena za zbylé službové artikly na zakázce). LOOP AT lt_info INTO ls_info WHERE mtart EQ 'DIEN'. lv_sluzby = 'X'. SELECT SINGLE kbetr INTO ls_info-kbetr FROM konv WHERE knumv EQ dvbak-knumv AND kposn EQ ls_info-posnr AND kschl EQ 'ZDPL'. IF ls_info-matnr IN r_matnr. lv_kbetr_s = lv_kbetr_s + ls_info-kbetr. ELSE. lv_kbetr_se = lv_kbetr_se + ls_info-kbetr. ENDIF. ENDLOOP. IF NOT lv_menge_zak IS INITIAL. lv_pom = lv_kbetr_s / lv_menge_zak. lv_kbetr_s = lv_pom * lv_menge_obj. ENDIF. ENDIF. * Z tabulky VBFA (tok dokladu) jsou načteny všechny objednávky * pro zakázku zákazníka. Následně je smazána objednávka, kterou právě * program zpracovává, a také jsou odmazány objednávky, které mají pole * RFMNG (Referenční množství v základní měrné jednotce) iniciální (značí, že objednávka byla stornovaná) SELECT vbelv vbeln posnn rfmng FROM vbfa INTO TABLE lt_vbfa2 WHERE vbelv EQ dvbak-vbeln AND vbtyp_n EQ 'V'. “ objednávka DELETE lt_vbfa2 WHERE rfmng IS INITIAL OR vbeln EQ xekko-ebeln. IF lt_vbfa2[] IS INITIAL. lv_kbetr_s = lv_kbetr_s + lv_kbetr_se. ENDIF.

Jazyk ABAP je na první pohled poměrně čitelný jazyk, nicméně z důvodu dodržování SAP konvence o pojmenování proměnných může být algoritmus nečitelný. Jednotlivé části kódu jsou popsány v komentářích, které jsou k nalezení nad danou funkcionalitou. Jazyk ABAP má definovány komentáře znakem * na začátku řádku.

Implementace

71

5.5 Testování Testování obecné funkčnosti V rámci iniciálního plnění dodavatelského portálu daty, bylo využito produkčních objednávek. Z těchto objednávek byly zkopírovány IDocy a změnou cílového logického systému byl zajištěn přenos do dodavatelského portálu. Objednávky byly zvoleny tak, aby pokryly všechny varianty. • Jednopoložková objednávka o Závoz na prodejnu o Závoz zákazníkovi na adresu • Vícepoložková objednávka o Závoz na prodejnu o Závoz zákazníkovi na adresu Všechny objednávky byly bez problému přeneseny a na straně dodavatelského portálu zpracovány. Následným krokem je expedice objednávek dodavatelem. Zprávy byly úspěšně sestaveny a odeslány do systému PI, kde byly přemapovány do struktury IDoc a odeslány do ERP. Pro objednávky expedované na prodejnu byly vytvořeny přijímané dodávky, které budou čekat na příjem zboží. Přijímané dodávky pro objednávky expedované na adresu zákazníka jsou automaticky zaúčtovány. Po expedici lze objednávku fakturovat. Faktury byly úspěšně přeneseny a zobrazily se v transakci MIR6. Ceny byly shodné s objednávkou a daň byla vyčíslena správně. Storno objednávky ze strany SAP Pro otestování funkčnosti byla vytvořena nová zákaznická zakázka 7000323792 respektive nákupní objednávka 4504978897. Po přenesení objednávky do portálu byla objednávka v ERP stornována. Systém automaticky vytvořil změnovou zprávu NEU, která vytvořila IDoc. Zpráva byla přenesena do dodavatelského portálu, kde byla objednávka stornována a zablokována pro expedici i fakturaci. Po obnovení objednávky v ERP (zrušení příkazu storna), byla vytvořena nová zpráva. Zpráva zajistila odblokování objednávky v dodavatelském portálu. Vyčíslení doplatku V rámci tohoto testu byly vytvořeny zakázky, které popisují případy z testovacích scénářů. Bližší popis a cíle jednotlivých testů jsou v kapitole 4.3. Testovací scénáře. Výsledky testů jsou popsány v tabulce Tab. 5 Výsledek testování doplatku.

72

Implementace Výsledek testování doplatku

Tab. 5

Případ 1.

Zakázka 7000323793

2.

7000323794

3.

7000323795

4.

7000323796

5.

7000323797

6.

7000323798

7.

7000323799

8.

7000323800

Popis 1 dodavatel, dobírka 1 dodavatel, platba na prodejně Více dodavatelů, dobírka Pneumatiky + nábytek, dobírka Pneumatiky + elektronika, dobírka Pneumatiky + elektronika, platba na prodejně Pneumatiky + elektronika + nábytek, dobírka Pneumatiky + elektronika + nábytek, platba na prodejně

Stav Vyhovuje Vyhovuje Částečně vyhovuje Částečně vyhovuje Částečně vyhovuje Vyhovuje Částečně vyhovuje Vyhovuje

Všechny případy, jež jsou označeny stavem Vyhovuje, proběhly přesně podle požadavků definovaných v příslušném testovacím scénáři. Stav Částečně vyhovuje, indikuje, že došlo k mírnému, nekritickému rozdílu mezi požadavkem a funkcionalitou. Stav Nevyhovuje je považován za vážnou chybu. V následujícím výčtu budou popsány případy, které nejsou ohodnoceny stavem Vyhovuje. • Případ 3. – doplatek není vyčíslen hromadně, tak aby byl vybrán pouze jedním z dodavatelů, ale je poměrově rozdělen do obou objednávek. Celková částka za zakázku je rovna sumě obou vybraných částek. Z pohledu firmy je toto lepší řešení. • Případ 4. – jak bylo popsáno v testovacím scénáři, dopravné pneumatik má vyšší prioritu než dopravné nábytku. Zakázka neobsahuje žádné dopravné za nábytek, tudíž je nesmyslné rozpočítávat dopravné za pneumatiky do objednávky nábytku. Celá částka za dopravu bude vybrána dopravcem, který doručí pneumatiky. Dopravce doručující nábytek vybere peníze pouze za zboží, které přepravuje. Zde se jedná o logičtější řešení. • Případ 5. – cena dopravného pneumatik bude vybrána dopravcem, jež dodá elektroniku. Dopravce dodávající pneumatiky vybere cenu pouze za zboží, jež dodává. Celková cena je rovna oběma dobírkám, ale může být matoucí, že platba za dopravu pneumatik je vybrána u elektroniky. Je však nutné dodat, že zákazník netuší, k čemu je dopravné počítáno, pro něj je to pouze částka za zakázku. • Případ 7. – obdobný případ jako případ č. 5. Částku za dopravu vybere dopravce dodávající elektroniku a ostatní dopravci vyberou pouze cenu za zboží.

Implementace

73

Formát dat od dodavatele Tento bod byl splněn v plném rozsahu. Zprávy, jež jsou předávány pomocí webových služeb, jsou odděleny a nenesou žádné redundantní data jako při zpracování souborů v původním řešení. Monitoring zpráv Bod tohoto testování proběhl úspěšně, nicméně s mírnými výhradami. Stavy přenosů jsou viditelné jak v ABAP části PI, konkrétně v transakci SXMB_MONI, tak i v JAVA části, konkrétně v aplikaci Message Monitor nebo Communication channel monitor Adapter enginu. V jednotlivých nástrojích jsou vidět chyby v komunikaci nebo struktuře dat, bohužel nejsou vidět chyby, které produkuje dodavatelský portál. Pokud by například uložení objednávky neproběhlo úspěšně, systém PI zobrazí chybu, nicméně bez bližšího popisu.

74

Závěr

6 Závěr Cílem této práce byl návrh a optimalizace stávající procesu prodeje pneumatik s dodáním třetí stranou za využití informačního systému SAP. Nejprve byl představen informační systém SAP s jeho komponenty a technologiemi. Poté byl představen proces prodeje dle původního řešení a nastíněny jeho nevýhody. Na základě nevýhod původního řešení byl navržen systém, který tyto chyby eliminuje a následně bylo řešení implementováno. V rámci implementace byly představeny systémy SAP ERP a SAP PI spolu s kroky, jež byly v systémech provedeny. Dále byl naimplementován dodavatelský portál, který supluje dodavatele. Výsledkem je propojení jednotlivých systémů. Cíl práce byl naplněn a vzniklo řešení, které je univerzální, přenositelné a ctí standardy na komunikaci. Přenosové zprávy jsou logované v systému PI, již se nestane, že dodavatel zprávu nezpracuje a firma se o tom nedozví jinak, než od rozhořčených zákazníků. Řešení zabraní hromadění zpráv IDoc v systému ERP, tento problém nastával při několikanásobném čtení souboru s již zpracovanými daty. Proces popsaný v této práci by měl sloužit jako šablona, která může být použita jak pro optimalizaci stávajícího propojení s dodavateli pneumatik, tak pro další dodavatele (nejen pneumatik), se kterými bude firma obchodovat. Dle autora práce je možné řešení, jež bylo vypracováno v této práci nasadit do produktivního provozu. Z důvodu urgentní opravy výpočtu doplatku byla funkcionalita řešící výpočet doplatku nasazena do produktivního provozu hned po otestování. Řešení jako celek bude představeno vedení firmy a dle uvážení použito pro optimalizaci stávajícího řešení nebo až při tvorbě nového napojení. Problematika propojení dvou systémů mezi sebou přináší mnoho možností rozšíření. Vývoj by mohl pokračovat implementací funkcionality, která by přebírala chybové hlášky z dodavatelského portálu do systému PI. Jistě by bylo výhodné zjistit, co za chybu portál vyvolal, zda je chyba v datech či ve zpracování. Dále je možné přebírat nákupní ceny přímo od dodavatele, jakmile by dodavatel změnil cenu zboží (například nějaká akce). Tato cena by mohla být automaticky přenesena do SAP a informovat příslušného nákupčího, že daný produkt je ve slevě. Také by mohla být implementována funkcionalita rezervací. V produktivním provozu se stává, že zboží, které má dodavatel v malém množství, se tzv. vykrade. Důvodem tohoto problému je fakt, že dodavatel se nedozví o potřebě naší firmy dříve, než z nákupní objednávky. Pokud však zákazník plánuje vykrýt zakázku platbou bankovním převodem, objednávka se vytvoří až po zaplacení. Proces závozu třetí stranou a propojení firmy s dodavatelem je obsáhlá tématika. Podmínky na propojení jsou častokrát pevně specifikovány firmou a mohou se lišit od procesů jiných. Dle autora práce je proces navrhnutý v této práci jádrem a lze na něm stavět.

Literatura

75

7 Literatura ANDERSON, GEORGE W. Naučte se SAP za 24 hodin. 1. vyd. Brno: Computer Press, 2012, 432 s. ISBN 978-80-251-3685-0. ARLOW, JIM A ILA NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. 2., aktualiz. a dopl. vyd. Brno: Computer Press, 2007, 567 s. ISBN 978-80-251-1503-9. DOHNAL, JAN A JAN POUR. Architektury informačních systémů: v průmyslových a obchodních podnicích. Vyd. 1. Praha: Ekopress, 1997, 301 s. ISBN 80-8611902-5. DVOŘÁKOVÁ, DANA. Základy účetnictví. Vyd. 1. Praha: Wolters Kluwer Česká republika, 2010, 307 s. ISBN 978-80-7357-544-1. KOFLER, MICHAEL A BERND ÖGGL. PHP 5 a MySQL 5: průvodce webového programátora. Vyd. 1. Brno: Computer Press, 2007, 607 s. ISBN 978-80-251-1813-9. KÜHNHAUSER, KARL-HEINZ. ABAP: výukový kurz. Vyd. 1. Brno: Computer Press, 2009, 365 s. ISBN 978-80-251-2117-7. MAASSEN, ANDRÉ, ANDREAS GADATSCH, DETLEV FRICK A MARKUS SCHOENEN. SAP R/3: Kompletní průvodce. Brno: COMPUTER PRESS, 2007. ISBN 978-80-2511750-7. MANGESH, PISE. What is SAP Netweaver? | SCN. In: SCN Community Network [online]. 2012 [cit. 2015-01-03]. Dostupné z: http://scn.sap.com/community/netweaveradministrator/blog/2012/11/19/what-is-sap-netweaver PATTON, RON. Testování softwaru: automatické i ruční testování, testování použitelnosti, lokalizace i kompatibility produktů nejen pro manažery softwarových projektů a testery, praktická cvičení na konci kapitol. 1. vyd. Praha: Computer Press, c2002, xiv, 313 s. Programování. ISBN 80-722-6636-5. PHP5, MySQL, Apache: vytváříme webové aplikace. Vyd. 1. Brno: Computer Press, 2006, 813 s. ISBN 80-251-1073-7. RATHORE, MANOJ KANWAR. What is difference between SAP R/1, R/2 and R/3 ?. SAP Peers [online]. January 7, 2011 [cit. 2014-12-01]. Dostupné z: http://sappeers.wordpress.com/2011/01/07/what-is-difference-betweensap-r1-r2-and-r3/ SAP History: 1972-1981: the early years. 1972-1981 | History | Company Information | About SAP | SAP [online]. [cit. 2014-11-30]. Dostupné z: http://www.sap.com/corporate-en/about/our-company/history/19721981.html SODOMKA, PETR A HANA KLČOVÁ. Informační systémy v podnikové praxi. 2. aktualiz. a rozš. vyd. Brno: Computer Press, 2010, 501 s. ISBN 978-80-251-2878-7.

76

Literatura

ŠUBRT, VÁCLAV. Zákon o požární ochraně s komentářem: zákon č. 133/1985 Sb., o požární ochraně, jak vyplývá z úplného znění vyhlášeného pod č. 67/2001 Sb. 1. vyd. Praha: Rego, 2002, 110 s. ISBN 80-86648-03-6. VRÁNA, JAKUB. 1001 tipů a triků pro PHP. Vyd. 1. Brno: Computer Press, 2010, 456 s. ISBN 978-80-251-2940-1. Vyhláška č. 246/2001 Sb. o stanovení podmínek požární bezpečnosti a výkonu státního požárního dozoru (vyhláška o požární prevenci). Vyhláška č. 246/2001 Sb. o stanovení podmínek požární bezpečnosti a výkonu státního požárního dozoru (vyhláška o požární prevenci) - TZB-info [online]. 2001 [cit. 2015-03-09]. Dostupné z: http://www.tzb-info.cz/pravni-predpisy/vyhlaskac-246-2001-sb-o-stanoveni-podminek-pozarni-bezpecnosti-a-vykonustatniho-pozarniho-dozoru-vyhlaska-o-pozarni-prevenci WEMPEN, FAITHE. HTML a CSS: krok za krokem. Vyd. 1. Překlad Josef Bábík. Brno: Computer Press, 2007, 324 s. ISBN 978-80-251-1505-3. ZIKMUND, MARTIN. K čemu jsou podnikové informační systémy. K čemu jsou podnikové informační systémy - BusinessVize.cz [online]. 2010, 2010-06-07 [cit. 2014-11-29]. Dostupné z: http://www.businessvize.cz/informacnisystemy/k-cemu-jsou-podnikove-informacni-systemy

77

Přílohy

78


A Zdrojový kód vyčíslení doplatku TYPES: BEGIN OF ty_matnr, matnr TYPE matnr, END OF ty_matnr, BEGIN OF ty_vbfa, vbelv LIKE vbfa-vbelv, vbeln LIKE vbfa-vbeln, posnn LIKE vbfa-posnn, rfmng LIKE vbfa-rfmng, END OF ty_vbfa. TYPES: BEGIN OF l_info, vbeln LIKE vbap-vbeln, posnr LIKE vbap-posnr, matnr LIKE vbap-matnr, kwmeng LIKE vbap-kwmeng, mtart LIKE mara-mtart, matkl LIKE mara-matkl, kbetr LIKE konv-kbetr, END OF l_info. TYPES: BEGIN OF l_tirob, kbetr LIKE konv-kbetr, END OF l_tirob. DATA: lv_partner TYPE edipparnum, ls_e1edp05 LIKE e1edp05, ls_e1edk05 LIKE e1edk05, ls_edidd_1 LIKE edidd, lv_exist TYPE c, lv_index LIKE sy-index, lv_kbetr LIKE konv-kbetr, lv_kbetr_s LIKE konv-kbetr, lv_betrg LIKE e1edk05-betrg, lv_sluzby TYPE c, ls_info TYPE l_info, lt_info TYPE TABLE OF l_info WITH HEADER LINE, ls_tirob TYPE l_tirob, lt_tirob TYPE TABLE OF l_tirob WITH HEADER LINE, lt_vbfa TYPE TABLE OF vbfa WITH HEADER LINE, ls_vbfa TYPE vbfa, lv_polzak TYPE c LENGTH 2, lv_polobj TYPE c LENGTH 2. DATA: lv_menge_obj LIKE ekpo-menge, lv_menge_zak LIKE vbap-kwmeng, lv_kbetr_se LIKE konv-kbetr, lv_njn3s TYPE c, lv_pom TYPE kbetr, lv_value2 LIKE zr025-value, lv_lines TYPE i, lt_matnr TYPE STANDARD TABLE OF ty_matnr WITH HEADER LINE, lt_pneu_matkl TYPE STANDARD TABLE OF zws_pneu_matkl, lt_vbfa2 TYPE STANDARD TABLE OF ty_vbfa. RANGES r_matnr FOR mara-matnr.


79

IF control_record_out-idoctp = 'ORDERS05'."Pouze ORDERS05 SELECT SINGLE value INTO lv_partner FROM zr025 WHERE area IN ('ZWS_IDOC_P', 'ZWS_IDOC_B') AND name = sy-sysid AND value = control_record_out-rcvprn. IF sy-subrc EQ 0 AND control_record_out-rcvprn = lv_partner. LOOP AT int_edidd INTO ls_edidd WHERE segnam = 'E1EDP05'. ls_e1edp05 = ls_edidd-sdata. IF ls_e1edp05-kschl = 'ZDPL'."při existenci ZDPL na položce CLEAR: lv_exist. LOOP AT int_edidd INTO ls_edidd_1 WHERE segnam = 'E1EDK05'. ls_e1edk05 = ls_edidd_1-sdata. IF ls_e1edk05-kschl = 'ZDPT'. lv_exist = 'X'."nezaložil jsem už náhodou ZDPT? ENDIF. ENDLOOP. IF lv_exist IS INITIAL."zakládám, jen když ještě neexistuje CLEAR: ls_edidd_1, ls_e1edk05, ls_info, ls_tirob, lv_kbetr. REFRESH:lt_info, lt_tirob. SELECT kbetr"Načtu nejdřív ZDPL z položek Objednávky INTO CORRESPONDING FIELDS OF TABLE lt_tirob FROM konv WHERE knumv EQ xekko-knumv AND kschl EQ 'ZDPL'. LOOP AT lt_tirob INTO ls_tirob. lv_kbetr = lv_kbetr + ls_tirob-kbetr. ENDLOOP. SELECT a~vbeln a~matnr a~posnr a~kwmeng c~mtart c~matkl INTO CORRESPONDING FIELDS OF TABLE lt_info FROM vbap AS a INNER JOIN vbak AS b ON a~vbeln EQ b~vbeln INNER JOIN mara AS c ON a~matnr EQ c~matnr WHERE b~vbeln EQ dvbak-vbeln. CLEAR: lv_kbetr_s, lv_sluzby, lv_polzak, lv_polobj, lv_menge_obj, lv_menge_zak, lv_pom, lv_kbetr_se, lv_n jn3s, lv_lines. * Načtení kategorií zboží pneumatik. Kategorie jsou udržovány v * customizační tabulce ZWS_PNEU_MATKL. V cyklu jsou procházeny všechny * položky zakázky s typem položky HAWA za účelem zjištění počtu kusů * pneumatik a v případě že se na zakázce nachází i jiná položka než * pneumatika logika vyčíslení se chová jinak. Proměnná lv_menge_zak * bude obsahovat počet kusů pneumatik na zakázce SELECT * FROM zws_pneu_matkl INTO TABLE lt_pneu_matkl. SORT lt_pneu_matkl. LOOP AT lt_info INTO ls_info WHERE mtart EQ 'HAWA'. READ TABLE lt_pneu_matkl WITH KEY matkl = ls_info-matkl TRANSPORTING NO FIELDS BINARY SEARCH. IF sy-subrc EQ 0. ADD ls_info-kwmeng TO lv_menge_zak. ELSE. lv_njn3s = 'X'. ENDIF. ENDLOOP.

80


* Pokud je podmínka vyhodnocena jako true zákazník si objednává pouze * pneumatiky. Proměnná lv_menge_obj bude obsahovat počet kusů * pneumatik na objednávce. IF lv_njn3s IS INITIAL. LOOP AT xekpo. ADD xekpo-menge TO lv_menge_obj. ENDLOOP. * * * * *

Z customizační tabulky ZR025 jsou selektovány artikly, jejichž cena je kusově závislá a má být rozdělena do jednotlivých objednávek. Artikly jsou příkazem SPLIT uloženy do záznamů interní tabulky, ze které je posléze vytvořena proměnná typu RANGES pro elegantní vyhledávání SELECT SINGLE value FROM zr025 INTO lv_value2 WHERE area = 'ZSLUZ_PNEU' AND name = 'MATNR'. IF sy-subrc EQ 0 AND NOT lv_value2 IS INITIAL. SPLIT lv_value2 AT ';' INTO TABLE lt_matnr. r_matnr-sign = 'I'. r_matnr-option = 'EQ'. LOOP AT lt_matnr. r_matnr-low = lt_matnr-matnr. APPEND r_matnr. ENDLOOP.

* * * * *

Pro všechny položky zakázky druhu položky DIEN (služba) je z tabulky podmínek (KONV) načtena částka doplatku. Ceny jsou posleze rozděleny do proměnné lv_kbetr_s (cena, která bude rozpočítána dle kusů objednávky) a proměnné lv_kbetr_se (cena za zbylé službové artikly na zakázce). LOOP AT lt_info INTO ls_info WHERE mtart EQ 'DIEN'. lv_sluzby = 'X'. SELECT SINGLE kbetr INTO ls_info-kbetr FROM konv WHERE knumv EQ dvbak-knumv AND kposn EQ ls_info-posnr AND kschl EQ 'ZDPL'. IF ls_info-matnr IN r_matnr. lv_kbetr_s = lv_kbetr_s + ls_info-kbetr. ELSE. lv_kbetr_se = lv_kbetr_se + ls_info-kbetr. ENDIF. ENDLOOP. IF NOT lv_menge_zak IS INITIAL. lv_pom = lv_kbetr_s / lv_menge_zak. lv_kbetr_s = lv_pom * lv_menge_obj. ENDIF. ENDIF.

* Z tabulky VBFA (tok dokladu) jsou načteny všechny objednávky * pro zakázku zákazníka. Následně je smazána objednávka, kterou právě * program zpracovává, a také jsou odmazány objednávky, které mají pole * RFMNG (Referenční množství v základní měrné jednotce) iniciální (značí, že objednávka byla stornovaná) SELECT vbelv vbeln posnn rfmng FROM vbfa INTO TABLE lt_vbfa2 WHERE vbelv EQ dvbak-vbeln


81

AND vbtyp_n EQ 'V'. “ objednávka DELETE lt_vbfa2 WHERE rfmng IS INITIAL OR vbeln EQ xekko-ebeln. IF lt_vbfa2[] IS INITIAL. lv_kbetr_s = lv_kbetr_s + lv_kbetr_se. ENDIF. MOVE lv_kbetr TO lv_betrg. CONDENSE lv_betrg. ls_edidd_1-segnam ls_e1edk05-alckz ls_e1edk05-kschl ls_e1edk05-kotxt ls_e1edk05-betrg ls_edidd_1-sdata

= = = = = =

'E1EDK05'. '+'. 'ZDPT'. 'Součet relevantních ZDPL'. lv_betrg. ls_e1edk05.

*Kvůli syntaxi idocu musím řádek vložit na správné místo-před E1EDKA1 READ TABLE int_edidd INTO ls_edidd WITH KEY segnam = 'E1EDKA1'. lv_index = sy-tabix. INSERT ls_edidd_1 INTO int_edidd INDEX lv_index. ENDIF. ENDIF. ENDLOOP. ENDIF. ENDIF.

82

XSLT – OrderData

B XSLT – OrderData <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:n0="http://bp_ipneu/ipneu" xmlns:map="java:java.util.Map" xmlns:dyn="java:com.sap.aii.mapping.api.DynamicConfiguration" xmlns:key="java:com.sap.aii.mapping.api.DynamicConfigurationKey" xmlns:xsltc="http://xml.apache.org/xalan/xsltc"> <xsl:template match="/ORDERS05/IDOC"> <xsl:element name="createOrderRequest"> <xsl:call-template name="Order"/> <xsl:template name="Order"> <xsl:element name="order"> <xsl:element name="OrderId"><xsl:value-of select="E1EDK01/BELNR"/> <xsl:element name="CustOrder"><xsl:for-each select="E1EDK02[QUALF='007']"><xsl:value-of select="BELNR"/> <xsl:element name="OrganizationID"><xsl:for-each select="E1EDK14[QUALF='011']"><xsl:value-of select="ORGID"/> <xsl:element name="ShipmentMethodID"><xsl:for-each select="E1EDKA1[PARVW='LF']"><xsl:value-of select="IHREZ"/> <xsl:element name="Currency"><xsl:value-of select="E1EDK01/CURCY"/> <xsl:variable name="werks"><xsl:for-each select="E1EDP01"><xsl:value-of select="WERKS"/> <xsl:variable name="traffic"> <xsl:choose> <xsl:when test="$werks = 'W001'"><xsl:value-of select="'B2C'"/> <xsl:otherwise><xsl:value-of select="'B2B'"/> <xsl:element name="Note"><xsl:value-of select="$traffic"/> <xsl:for-each select="E1EDKA1[PARVW='WE']"> <xsl:element name="Recipient"><xsl:applytemplates select="." mode="Recipient"> <xsl:for-each select="E1EDP01"> <xsl:element name="Item"> <xsl:element name="Number"><xsl:value-of select="POSEX"/>

XSLT – OrderData

83

<xsl:element name="Goods"><xsl:value-of select="MATNR"/> <xsl:variable name="articleCode"><xsl:for-each select="E1EDP19[QUALF='002']"><xsl:value-of select="IDTNR"/> <xsl:element name="VendorGoods"><xsl:value-of select="translate($articleCode, ' ', '')"/> <xsl:element name="Quantity"><xsl:value-of select="MENGE"/> <xsl:element name="PriceNetto"><xsl:value-of select="VPREI"/> <xsl:element name="ValueNetto"><xsl:value-of select="NETWR"/> <xsl:element name="MeasurementUnit"><xsl:calltemplate name="ConvertMU"><xsl:with-param name="sourceMU"><xsl:valueof select="PMENE"/> <xsl:element name="DeliveryDate"><xsl:calltemplate name="ConvertDate"><xsl:with-param name="sourceDate"><xsl:value-of select="E1EDP20[1]/EDATU"/> <xsl:variable name="additionalPayment"><xsl:foreach select="E1EDP05[KSCHL='ZDPL']"><xsl:value-of select="BETRG"/> <xsl:if test="$additionalPayment!=''"> <xsl:element name="AdditionalPayment"><xsl:value-of select="$additionalPayment"/> <xsl:element name="Cod"><xsl:for-each select="E1EDK05[KSCHL='ZDPT']"><xsl:value-of select="BETRG"/> <xsl:template match="*" mode="Recipient"> <xsl:element name="Number"><xsl:value-of select="LIFNR"/> <xsl:element name="Name"><xsl:value-of select="NAME1"/> <xsl:if test="STRAS and STRAS!=''"><xsl:element name="Street"><xsl:value-of select="STRAS"/> <xsl:element name="City"><xsl:value-of select="ORT01"/> <xsl:element name="PostalCode"><xsl:value-of select="PSTLZ"/> <xsl:element name="State"><xsl:value-of select="LAND1"/> <xsl:if test="TELF1 and TELF1!=''"><xsl:element name="Phone"><xsl:value-of select="TELF1"/> <xsl:if test="ILNNR and ILNNR!=''"><xsl:element name="Email"><xsl:value-of select="ILNNR"/>

84

XSLT – OrderData

<xsl:template name="ConvertMU"> <xsl:param name="sourceMU"/> <xsl:choose> <xsl:when test="$sourceMU = 'PCE'">ks <xsl:when test="$sourceMU = 'MTR'">m <xsl:when test="$sourceMU = 'MTK'">m2 <xsl:otherwise><xsl:value-of select="$sourceMU"/> <xsl:template name="ConvertDate"> <xsl:param name="sourceDate"/> <xsl:value-of select="substring($sourceDate,1,4)"/><xsl:value-of select="substring($sourceDate,5,2)"/>-<xsl:value-of select="substring($sourceDate,7,2)"/>

ERD – Dodavatelský portál

C ERD – Dodavatelský portál

85

86

Ukázka dodavatelského portálu

D Ukázka dodavatelského portálu

Návrh a realizace vylepšení objednávkového systému pro prodej pneumatik

Recommend Documents