Výstupní zprávy informačního systému SAP

Výstupní zprávy informačního systému SAP

Bakalářská práce

Studijní program: B6209 – Systémové inženýrství a informatika Studijní obor: 6209R021 – Manažerská informatika

Autor práce: Vítězslav Vejnar

Vedoucí práce: doc. Ing. Klára Antlová, Ph.D.

Prohlášení

Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vzta- huje zákon č. 121/2000 Sb., o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé bakalářské práce pro vnitřní potřebu TUL.

Užiji-li bakalářskou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tomto pří- padě má TUL právo ode mne požadovat úhradu nákladů, které vyna- ložila na vytvoření díla, až do jejich skutečné výše.

Bakalářskou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím mé bakalářské práce a konzultantem.

Současně čestně prohlašuji, že texty tištěné verze práce a elektronické verze práce vložené do IS STAG se shodují.

7. 4. 2019 Vítězslav Vejnar

Poděkování

Velké díky patří vedoucí mé práce doc. Ing. Kláře Antlové, Ph.D., která mi svými konstruktivními poznámkami pomohla nalézt při psaní ten správný směr. Dále bych rád poděkoval firmě Pregis, a.s., ve které jsem vykonával svou řízenou praxi, za zapůjčení služebního notebooku pro účely výzkumu v rámci informačního systému SAP. Za uvedení do problematiky výstupních zpráv děkuji také svým kolegům z konzultantského týmu PRO.

Anotace

Tato bakalářská práce se věnuje tématům týkajícím se informačního systému SAP a jeho tiskových výstupů. V teoretické části se zaměřuje nejprve na téma ERP, jeho přínosu pro podnik a významu tiskových výstupů. Dále obecně rozebírá také informační systém SAP.

V následujících kapitolách pak rozebírá jednotlivé technologie pro tvorbu dynamických tiskových výstupů v rámci v současnosti nejrozšířenějších verzích informačního systému SAP, dokumentuje proces řízení tiskových výstupů a přizpůsobení fungování tohoto nástroje. Teoretickou část práce uzavírá porovnání technologií řízení tiskových výstupů přístupných v rámci dvou rozdílných verzí informačního systému SAP.

V rámci praktické části se práce věnuje shrnutí a porovnání důležitých charakteristik jednotlivých popsaných technologií tvoření výstupních zpráv a jejich tiskové determinace a zhodnocení jejich využitelnosti.

Hlavním cílem této bakalářské práce je popsat technologii tvoření a řízení tiskových výstupů informačního systému SAP ve verzích SAP R/3 a SAP S/4 HANA a popsat rozdíly mezi řešením dané problematiky v rámci jednotlivých verzí.

Klíčová slova

informační systém SAP, SAP ERP, výstupní zprávy, řízení výstupních zpráv, SAPscript, Smartforms, PDF formuláře, předlohy formulářů SAP, SAP R/3, SAP S/4 HANA, BRF+, dynamicky generované formuláře

Abstract

This bachelor thesis covers the topic of the SAP information system and the output messages of the said system. The theoretical part is focused on the ERP systems, the benefits they bring to the enterprise and the significance of the output messages.

Afterwards, the thesis also briefly introduces the SAP information system.

In forthcoming chapters, the main focus of the thesis is on the technologies that are used for generating output messages throughout the widespread versions of the SAP information system, later explaining the output determination process and the customization of this tool. The theoretical part of the thesis is concluded with a comparison of the technologies used for output message determination throughout two different versions of the SAP information system.

The empirical part of the thesis is focused around summarizing and comparing the important characteristics of the described technologies for creating and determination of the output message.

The main goal of this bachelor thesis is to describe the technology used for creation and determination of the output messages of the SAP information system versions SAP R/3 and SAP S/4 HANA analyzing the differences between the execution of this process in the given versions.

Keywords

SAP information system, SAP ERP, output documents, output messages determination, SAPscript, Smartforms, PDF forms, SAP form templates, SAP R/3, SAP S/4 HANA, BRF+, dynamically generated forms

Obsah

Úvod...11

1 Enterprise resource planning...12

1.1 ERP systémy...12

1.2 Přínosy a úskalí ERP systémů...13

1.3 Výstupní zprávy ERP systémů...15

2 Systém SAP...17

2.1 Obecné informace...17

2.2 Verze IS SAP...19

3 Dynamické tiskové formuláře...22

3.1 Proces vytvoření výstupního dokumentu...22

3.2 SAPscript...23

3.2.1 Volání formuláře SAPscript...24

3.3 Smart Forms...25

3.3.1 Volání Smart Forms...28

3.4 PDF formuláře Adobe...29

3.5 PDF formuláře s fragmenty (SAP S/4 HANA)...32

4 Řízení zpráv...38

4.1 Determinace druhu výstupu v SAP R/3...38

4.2 Proces uvolnění tiskové zprávy...40

4.3 Determinace druhu výstupu v SAP S/4 Hana...41

5 Srovnání popsaných technologií...45

5.1 Technologie pro vytváření výstupních zpráv...45

5.2 Řízení výstupních zpráv...48

Závěr...50

Seznam obrázků

Obrázek 1: Funkční oddělení firmy a jejich propojení...17

Obrázek 2: SAP Fiori Launchpad...20

Obrázek 3: Kód SAPScript formuláře...24

Obrázek 4: Transakce SMARTFORMS...25

Obrázek 5: Transakce SMARTSTYLES...27

Obrázek 6: Adobe LiveCycle Designer...33

Obrázek 7: Schéma fragmentu hlavní předlohy formuláře...35

Obrázek 8: Objekty proměnných v BRF+...37

Obrázek 9: Změna výstupních podmínek v transakci NACE...38

Obrázek 10: Schéma nalezení výstupního média...39

Obrázek 11: Rozhraní pro stanovení parametrů tiskových výstupů...42

Seznam tabulek

Seznam použitých zkratek

ADS Adobe document services ALD Adobe Livecycle designer

BRF+ business rule framework + (nástroj v rámci IS SAP S/4 HANA) EDI electronic data interchange (elektronická výměna dat)

ERP enterprise resource planning (plánování využití firemních zdrojů) FPF forms processing framework (rozhraní zpracování formulářů) GUI graphical user interface (grafické uživatelské rozhraní) IS informační systém

MM materials management (materiálové hospodářství) PDF portable document format (přenosný formát dokumentu) RFC remote function call (vzdálené volání funkcí)

bgRFC background remote function call (vzdálené volání funkcí na pozadí) SaaS software as a service (software poskytovaný jako služba)

Úvod

V rámci současné podnikové praxe hrají nezanedbatelnou roli informační systémy, těchto aplikací je dnes na trhu již nepřeberné množství. Speciální kategorií mezi nimi jsou ERP systémy, které se vyznačují vysokou integrovaností jednotlivých procesů v rámci všech částí podniku, umožňují tak nahlížet data komplikovaných obchodních případů v kontextu jejich celkového průběhu. Takovým informačním systémem je i IS SAP, který je postupně vyvíjen již od sedmdesátých let minulého století a patří mezi špičku na trhu.

Součástí činností v rámci chodu podniku jsou často i situace, kdy potřebujeme umožnit náhled k datům informačního systému i mimo jeho prostředí, například chceme-li komunikovat tato data jiným podnikatelským subjektům anebo potřebujeme-li, aby i zaměstnanci bez přístupu k IS mohli přispět k analýze či jednotlivých podnikových procesů. Pro tyto účely slouží v rámci informačních systémů výstupní zprávy, data, která potřebujeme předat, jsou uspořádána a odeslána či vytisknuta ve zvolené formě na místo určení.

Za fungováním výstupních zpráv se i oproti zdánlivé jednoduchosti skrývá systém sofistikovaných předloh a nastavení, jejichž nastavení ve většině případů přísluší expertům na daný informační systém a vývojářům. Každá výstupní zpráva musí být nejprve vygenerována do své finální podoby, načež musí být systémem odeslána na místo určení.

Cílem této práce je v následujících kapitolách popsat technologie užívané k tvorbě výstupních zpráv, řízení jejích výstupů v rámci IS SAP a zanalyzovat rozdíly mezi fungováním výstupních zpráv ve dvou verzích tohoto informačního systému – SAP R/3 a SAP S/4 HANA.

1 Enterprise resource planning

Tato kapitola se věnuje vymezení pojmu enterprise resource planning (ERP) a jeho uvedení do kontextu současné podnikové praxe. Dále se pokusí popsat i přínosy využívání ERP pro podnik, jeho výhody a nevýhody.

1.1 ERP systémy

Koncept enterprise resource planning systémů je postaven na myšlence počítačového softwaru, který může sloužit pro plánování, vykonávání činností spojených s chodem firmy a zobrazování výsledků těchto činností (tzv. reporting). Tyto všechny uvedené činnosti by mělo být možné řídit i v rámci propojených částí podniku - neizolovaně, pro ERP je tak důležité propojení všech složek, které fungují dohromady.

V začátcích byly ERP systémy i samotný pojem enterprise resource planning používány výhradně k rozdělování (alokaci) zejména lidských zdrojů a materiálu ve větších firmách.

Současnost ale tomuto pojmu přidala na důležitosti a s ERP se tak můžeme setkat v rámci podniků všech velikostí. Z původních systémů pro plánování zdrojů se staly velice pokročilé aplikace, které dovolují nejen přerozdělovat zdroje, ale zároveň zajistit plánování téměř veškerých aktivit ve firmě. Dnešní informační systémy zajišťují široké spektrum aktivit napříč všemi oblastmi podniků, těmito oblastmi jsou kromě již zmíněných lidských zdrojů a materiálového hospodářství například řízení odbytu, plánování výrobních postupů, kontrola kvality či účetnictví (Agrawal, 2010).

Systémy ERP tedy zastřešují mnohé funkce pro různá oddělení integrované do jediného programu běžícího nad jedinou databází a umožňují tak jednoduchou spolupráci a sdílení informaci mezi všemi úseky (Wailgum, 2017).

Úspěch zavedení ERP systémů v jednotlivých podnicích závisí hned na několika faktorech.

Nejde pouze o zvolení vhodné aplikace, je nutné nejprve pochopit, jaké podnikové procesy můžeme nalézt ve firmě. Informační systémy nejsou v základu poskytovatelem přizpůsobeny na specifické podmínky dané firmy, v rámci které jsou zaváděny.

Při implementaci a provozu firemního informačního systému se tak nepostradatelnou součástí procesu stává i tzv. kustomizace, tou se rozumí postupné adaptování systému na požadavky jednotlivých podnikových aktivit. Zmiňovaný proces je značně obtížný

a zahrnuje velice komplexní úpravy. Provedení kustomizace tak není téměř možné bez konzultace expertů na daný ERP systém. Za účelem přizpůsobení existuje možnost vytváření (programování) nových funkcí, také je možné i upravovat standardní funkce daného ERP systému a tím zlepšit jejich využitelnost v rámci konkrétního podniku (Al-Mashari, Al-Mosheleh, 2015).

1.2 Přínosy a úskalí ERP systémů

Ačkoliv je zavedení ERP systému jako jednoho zastřešujícího pro veškeré provozní aktivity firmy obtížné, může při správné implementaci přinést velice dobré výsledky.

Vezmeme-li v úvahu i jednoduché procesy jako je například vyřízení zákazníkovy objednávky, můžeme rychle vidět přínosy integrace všech procesů v rámci jednoho programu.

Ve firmě bez ERP systému může být objednávka několikrát evidována na různých pracovištích v různých systémech, což ale vede ke zkreslení dat a zbytečným prostojům.

Následkem nepropojených systému je také absence možnosti vyhledávat data ze všech pracovišť centrálně, při dohledávání informací je pak vždy potřeba zapojit několik osob.

Ve firmě se zavedeným ERP systémem při vyřízení objednávky dochází k tomu, že jsou data o zákazníkově objednávce zadána pouze jednou a následně jsou přístupna všem oddělením alespoň v míře ohraničené uživatelskými oprávněními a potřebami daného úseku. Hned první pracovník zadávající data objednávky má také již k dispozici informace z jiných oddělení související s nastalým případem, například všechny předchozí objednávky zákazníka, jeho fakturační údaje nebo třeba stav objednaného zboží na skladě.

V průběhu vyřizování objednávky je také možné sledovat její průběh a rychle zjistit, že zboží například již bylo přijato od dodavatele, aby mohlo být posláno zákazníkovi.

Pokud je tedy integrace ERP systému provedena dobře a uživatelé jsou náležitě proškoleni ohledně jeho užívání, můžou jednotlivé podnikové procesy plynule procházet skrze všechna oddělení, která je vyřizují.

ERP může tedy být činitelem velkého nárůstu efektivity práce a tím pádem i snížení nákladů na jednotlivé procesy. Implementace a provoz nového systému však mohou s sebou přinést i četná úskalí. Prvním problémem při přechodu firmy na nový systém může být změna role pracovníků. Z původně oddělených procesů najednou mizí hranice a už sám

obchodník při zadávání objednávky je schopen vidět například informace z účetnictví, které říkají, jak dobře zákazník platí za zboží, které obdržel. Na obchodníka tak najednou kromě zadání údajů objednávky a jednání se zákazníkem doléhá i nutnost rozhodnout, je-li například zákazníkovi s pěti nezaplacenými fakturami vhodné zasílat další zboží. Podobné rozšíření odpovědnosti vzniká na všech možných stanovištích na cestě určitého podnikového procesu, ERP tak vytváří velké požadavky na vhodné zaškolení, schopnosti uživatelů a komunikaci v rámci podniku.

Při instalaci ERP je nutné revidovat i způsob, jakým probíhají jednotlivé procesy ve firmě, přínosy nového systému přicházejí jedině tehdy, když se jednotlivé procesy sladí s nově implementovaným programem. Pokud bychom ERP systém pouze slepě nainstalovali jako náhradu za starý systém, došlo by ke znatelnému zpomalení všech procesů a možná i protestům ze strany zaměstnanců, kteří byli zvyklí využívat starý nahrazený systém, při zavádění je tak nutné počítat s tím, že s informačním systémem měníme i fungování všech dotčených oddělení napříč firmou, která se nyní stávají více propojenými.

Díky komplexnosti a rozsáhlosti ERP systémů je jejich zavádění ve firmách dlouhodobou záležitostí, která trvá většinou jeden až tři roky, což může být demotivujícím faktorem při rozhodování se o tom, zda systém ve firmě implementovat nebo nikoliv. Je nutné si uvědomit, že kromě instalace programového vybavení a migrace dat musí dojít také ke dříve zmiňovaným změnám v podnikových procesech a práci zaměstnanců, pokud jsou ovšem všechny tyto aspekty vyřešeny, může podnik čerpat z výhod, které ERP nabízí.

Implementace ERP je značně nákladnou záležitostí, která kromě samotné instalace a migrace vytváří náklady i v jiných oblastech, jakými jsou například školení zaměstnanců či kustomizace systému, chcete-li úpravy systému, aby lépe vyhovoval specifickým potřebám podniku. Z dlouhodobého hlediska však může užívání takto integrovaného informačního systému znamenat velkou úsporu nákladů, ty jsou eliminovány díky zrychlení jednotlivých podnikových procesů a větší dostupnosti dat a tím i zvýšenou schopností plánovat chod firmy z hlediska celku.

V posledních letech se jako možné řešení vysokých nákladů a dlouhé doby implementace ERP systémů objevují řešení nazývaná on-demand (na vyžádání) nebo SaaS (Software as a service – software poskytovaný jako služba), jednotlivé aplikace jsou v těchto řešeních

provozovány třetí stranou a uživatelé se na ně připojují skrze webový prohlížeč, díky tomu, že není potřeba instalace přímo na zařízení ve firmě, je proces implementace takového ERP značně kratší.

Pokud firma nepotřebuje všechny součásti, které ERP systémy nabízí, má u některých z nich možnost vybrat si pouze ty části, které potřebuje. Modulárně dodávané ERP systémy tak dovolují, aby jejich součásti byly implementovány samostatně, když firma v praxi například podniká ve službách a neskladuje žádný materiál, může si pořídit například pouze moduly pro finanční účetnictví a prodej a nemusí pořizovat modul systému pro skladové nebo materiálové hospodářství, čímž uspoří náklady na pořízení i omezenou kapacitu hardwaru (Wailgum, 2017).

1.3 Výstupní zprávy ERP systémů

Důležitou součástí činnosti ERP systému je i vytváření výstupních zpráv, chcete-li tiskových výstupů, které obsahují údaje o činnostech probíhajících v rámci podniku, zároveň mohou sloužit i jako podklady pro různé obchodní akce nebo mít pouze čistě informativní charakter. Součástí výstupních zpráv mohou být kromě textu i grafika nebo čárové kódy.

Důležitým aspektem výstupních zpráv je proces jejich vytvoření a vytisknutí. Vytvořením rozumíme proces sestavení finální podoby zprávy podle určité předlohy za využití dat získaných z databáze informačního systému. Vzhled předlohy pro vytváření dané tiskové zprávy může být často v rámci ERP systémů modifikován, a tak je možné jej využít i jako součást firemní identity (například použitím loga či hlavičkového papíru).

Rozhodnutí, jakou formu při svém uvolnění (chcete-li vytisknutí) výstupní zpráva dostane, záleží na rozhodnutí podniku v návaznosti na daný proces, při kterém výstup vzniká.

Uvolnění zprávy nemusí nutně znamenat použití tiskárny pro přenesení daného dokumentu do papírové formy, jelikož mnohé výstupní zprávy je možné a často dokonce vhodné rovnou odeslat formou e-mailu nebo jako například soubor určený pro komunikaci v rámci standardu EDI (Electronic Data Interchange) (Output Processing, 2016). Často je možné i uvolnění dané zprávy několika způsoby najednou, obchodník tak například rovnou může odeslat fakturu formou věty EDI odběrateli a zároveň automaticky vytisknout daný dokument na své tiskárně (Maasen, 2007).

Výstupní zprávy vznikají v rámci většiny podnikových procesů – například při prodeji (faktury, dodací listy, potvrzení zakázek...), nákupu (objednávky, plány dodávek…), při výrobě (štítky s čárovými kódy…), při činnostech v rámci materiálového hospodářství (příjemky, výdejky…) nebo v rámci řízení skladů (skladové příkazy…). Tiskové výstupy z informačního systému tedy slouží jako průvodní činitel mnoha činností generujících zisk a jejich řízení a srozumitelnost jsou pro firmu velice důležité.

2 Systém SAP

Následující kapitola se věnuje představení informačního systému SAP, zejména pak jeho vlastnostem a dvoum v současnosti nejrozšířenějším verzím. Informace v této kapitole by měly sloužit jako uvedení do problematiky systému SAP i pro ty, kteří nejsou jeho uživateli.

2.1 Obecné informace

Jakožto informační systém, který je vyvíjený již od roku 1972, SAP představuje jeden z nejrozšířenějších systémů svého druhu na trhu. Vyvíjí ho firma SAP SE sídlící v Německém Walldorfu, samotná zkratka SAP pochází z Němčiny, konkrétně ze slov

“Systeme, Anwendungen, Produkte in der Datenverarbeitung.” Volně přeloženo “Systémy, aplikace a produkty pro zpracování dat.” SAP patří mezi ERP systémy, což znamená, že jeho prostřednictvím lze sdílet všechna data v rámci celého podniku mezi různými odděleními (Agrawal, 2010). Na obrázku 1 můžeme vidět příklady různých oddělené firmy a naznačení propojení skrze data sdílená v IS mezi nimi.

Obrázek 1: Funkční oddělení firmy a jejich propojení

(Agrawal, 2010, s. 22, překresleno prostřednictvím draw.io)

Systém SAP je dodávaný modulárně, to znamená, že se skládá z jednotlivých komponent nabízejících rozličné funkce, tento způsob dodávky pak menším podnikům zpřístupňuje nákup informačního systému, můžou si totiž nakoupit pouze specifické části systému a v závislosti na růstu firmy pak dokupovat další potřebné části (Mohapatra, Lopez, 2016).

Tabulka 1 ukazuje rozdělení aplikací systému SAP na tři hlavní skupiny.

Tabulka 1: Části systému SAP (Mohapatra, Lopez, 2016, s. 22) SAP ERP ekonomické

nástroje SAP ERP logistické nástroje SAP ERP řízení lidských zdrojů

• Finanční účetnictví

• Controlling

• Řízení zdrojů

• Účetnictví majetku

• Materiálové hospodářství

• Prodej a distribuce

• Řízení skladů

• Řízení kvality

• Plánování výroby

• Údržba

• Personální management

• Výplatní systém

• Talent management

Kromě ERP systému společnost SAP vyvíjí i jiné nástroje pro uspokojení širších potřeb zákazníků. Takové produkty pak mohou být zaváděny samostatně, ale také integrovaně se základním systémem SAP. Příkladem tohoto druhu softwaru z nabídky SAP jsou následující (Agrawal, 2010):

• SAP SRM: Supplier Relationship Management – systém zefektivňující interakce s dodavateli a zásobování (Sethi, 2010)

• SAP SCM: Supply Chain Management – pokročilý systém pro plánování zásobování, zahrnuje lepší analytické nástroje a nástroje automatického rozhodování (Snapp, 2010)

• SAP CRM: Customer Relationship Management – systém pro řízení vztahu se zákazníkem a aktivit orientovaných směrem k zákazníkovi (Katta, 2008)

• SAP BW: Business Warehouse – software pro analýzu dat, která jsou následně využita jako podpora rozhodování v rámci strategie podniku (Fu, Fu, 2003)

Pro systém SAP ERP je typická vysoká kustomizovatelnost, změnit jej je možné tak, že dokáže uspokojit téměř jakékoli potřeby společnosti. K jeho vývoji je používán programovací jazyk ABAP (Advanced business application programming language).

Pro běžné užívání systému SAP není znalost jazyka ABAP potřeba, jako součást systému jsou nicméně poskytovány i vývojářské nástroje umožňující vytváření nových funkcí pro informační systém i úpravy standardních součástí (Agrawal, 2010).

Informační systém SAP je systémem transakčním, to znamená, že většinu operací v něm provádíme skrze takzvané transakce, ty představují malé dílčí aplikace, které jsou pro uživatele systému dostupné buď skrze menu nebo skrze technické názvy, některé z těchto názvů budou v textu práce zmíněny.

2.2 Verze IS SAP

V této práci se věnuji dvou v současnoti široce rozšířeným verzím informačního systému SAP, starší verzi SAP R/3, která byla vydána v roce 1998 a za dobu své existence prošla několika významnými updaty a rozšířeními (v roce 2004 byla přejmenována na SAP ERP) a verzí, která by měla sloužit jako její nástupce - SAP S/4 HANA, která poprvé vyšla roku 2015, nejprve pouze finanční modul v březnu zmíněného roku, posléze kompletní nová verze celého IS na podzim téhož roku (Denecken, 2015).

Verze R/3 byla představena zevrubně v předchozí podkapitole, v následujících odstavcích se tak věnuji hlavním charakteristikám SAP S/4 HANA.

SAP S/4 HANA je nabízen ve dvou verzích, on-premise a cloudové (SaaS - software as a service) verzi, verze on-premise je nainstalovaná přímo na serverech daného klienta, klient tedy musí sám udržovat programové vybavení i databázi a hardware, na kterém celý operační systém funguje, je ovšem zajištěna větší kontrola nad omezením přístupu k datům a tak zajištěna i větší ochrana obchodního tajemství. Cloud verze informačního systému umožňuje snížení nákladů na implementaci o potřebné hardwarové vybavení, avšak často je k ní přistupováno s nedůvěrou kvůli zajištění bezpečnosti dat, jelikož uživatel ukládá firemní data na servery poskytovatele, zákazník přistupuje k informačnímu systému na dálku, vše má na starosti poskytovatel IS (Transitioning to SAP S/4 HANA- Choosing a deployment Option, 2016). V dalších částech této práce se věnuji výhradně on-premise verzi.

On-premise verze SAP S/4 HANA je každoročně vydávána v nové edici, v současnosti nejaktuálnější edicí je 1809 ze září 2018. Cloudová verze velký update provádí kvartálně, a tak její v současnoti nejaktuálnější edicí je 1902 z února 2019.

Ohledně funkcionalit a uživatelského rozhraní SAP S/4 HANA staví výrazně na SAP R/3, hlavní změnou je databáze, na které celý informační systém funguje, zatímco ve verzi R/3 fungoval SAP nad řádkovou databází Oracle, verze S/4 HANA běží nad vlastní databází od firmy SAP SE, která nese název HANA a je sloupcová, což slibuje rychlejší analýzu dat, a tak i rychlejší běh operačního systému (How do SAP R/3, SAP ECC and SAP S/4 HANA differ?, 2018).

Kromě standardního uživatelského GUI SAP lze některé běžné aplikace systému spouštět a ovládat skrze uživatelské rozhraní aplikací SAP Fiori, jehož běh se odehrává kompletně v internetovém prohlížeči a je tak platformově nezávislé, dovoluje tak ovládat systém SAP i prostřednictvím jiných zařízení, nežli klasického počítače či notebooku (SAP Fiori Introduction, 2019). Pro některé činnosti v rámci SAP S/4 HANA jsou Fiori aplikace již nutností, například pro údržbu předloh pro generování tiskových výstupů (Maintaining Customized Master Forms, 2018).

Obrázek 2: SAP Fiori Launchpad (výstřižek z prostředí SAP Fiori)

Firma SAP SE urguje uživatele, aby upgradovali na novou verzi S/4 HANA co nejdříve, nejpozději do roku 2025, kdy se předpokládá ukončení podpory předchozí verze (How do SAP R/3, SAP ECC and SAP S/4 HANA differ?, 2018).

3 Dynamické tiskové formuláře

V této kapitole se věnuji jednotlivým technologiím užívaným pro tvorbu dynamicky generovaných tiskových výstupů v rámci IS SAP, u každé z technologií také nastíním postup návrhu předlohy daného formuláře.

V informačním systému SAP R/3 jsou k dispozici tři různé technologie pro tvorbu dynamicky generovaných formulářů, které byly postupem času vyvíjeny a výrazně se liší v postupu návrhu a generování tiskového výstupu. Těmito technologiemi jsou SAPscript, Smartforms a PDF formuláře Adobe. SAP S/4 HANA ke třem předchozím technologiím přidává i jakousi nadstavbu v podobě PDF formulářů s fragmenty.

Ačkoliv se může zdát, že pouze u PDF formulářů jsou výstupem doklady ve formátu pdf (portable document format), není tomu tak, přestože jednotlivé technologie využívají různé prostředky k tvorbě výstupu, je výsledný dokument vždy převeditelný do formy pdf dokumentu (SAP S/4 HANA Output Control, 2018).

3.1 Proces vytvoření výstupního dokumentu

Jedním z aspektů, kterým se výrazně liší technologie využívané k návrhu předloh pro dynamické generování výstupních dokumentů systému SAP, je samotný proces vytvoření finálního výstupu. Ačkoli probíhá sestavení výstupu u každé technologie na jiném principu, lze shrnout jeho průběh do několika fází – těmi jsou spuštění programu pro sběr dat, předání dat formuláři programem a vytvoření formuláře.

Při tvoření každého tiskového výstupu je spuštěn jeho volací program, uživatel jej spustí buď přímo, například uložením objednávky, anebo může jeho spuštění proběhnout pomocí jiného programu, který například spouští tisky v daný předem určený čas. Volací program sbírá data z databáze IS SAP, která posléze předá při volání formuláře a vytiskne je, proces předání dat se liší u každé z technologií a bude popsán v následujících kapitolách popisujících dané technologie jednotlivě. Předaná data jsou následně zpracována logikou formuláře do podoby finálního výstupu. Jakmile je sestavení konečného dokumentu hotové, je buď okamžitě vytisknut, anebo zařazen do tiskové fronty, jejíž fungování bude podrobněji vysvětleno v kapitole o determinaci tiskových výstupů.

3.2 SAPscript

Technologie SAPscript nabízí již v základu IS SAP několik předloh, které mohou být modifikovány nebo z nich můžeme vycházet při tvorbě nových tiskových formulářů, což výrazně ulehčuje proces vytváření nových tiskových výstupů pro použití v praxi, těmi jsou například následující:

• RVORDER01 – formulář tiskového výstupu zakázky

• RVDELNOTE – formulář pro dodací listy

• RVINVOICE01 – formulář tiskového výstupu faktury

• MEDRUCK – formulář sloužící pro nákupní dokumenty (objednávky, rámcové smlouvy, odvolávky)

Při zkoumání struktury formulářů SAPscript můžeme naleznout dvě hlavní části, těmi jsou obsah (Content), ten může být zastoupený buď jednotlivými obchodními daty, kterými je formulář dynamicky plněn nebo grafickými prvky (například logo společnosti) a rozložení stránky (Layout), to se skládá z několika samostatných oken, ve kterých můžeme později nalézt prvky obsahu formuláře.

Pro návrh formulářů vytvářených technologií SAPscript využíváme v informačním systému SAP vestavěný nástroj form painter, přístupný skrze transakci SE71 (ABAP SAPscripts, 2019).

Nástroj form painter (možno volně přeložit jako sada pro návrh formulářů) umožňuje uživateli upravovat jak grafickou, tak i obsahovou část tiskových výstupů, běžnou praxí je, spíše než vytváření vlastních formulářů, využití standardních vestavěných formulářů pro tvorbu nových. Formuláře dodávané spolu s IS SAP mohou být pro tvorbu nových použity tak, že původní formulář je překopírován s novým jménem a nadále upravován podle požadavků koncových uživatelů.

Při úpravě SAPscriptů, jak už bylo zmíněno, je možné měnit jak rozložení stránek formuláře, tak i jeho obsah. Ten kromě dat z databáze nebo grafiky mohou představovat také standardizované texty, které připravuje uživatel prostřednictvím transakce SO10 (SAP Scripts in Detail, 2013).

Výsledný formulář je možné udržovat v mnoha jazykových mutacích, které jsou posléze využívány dle potřeby (například pro zákazníky z Itálie může být tisknut vždy pouze formulář v italštině, existuje-li), pro tyto účely využíváme výstupních zpráv (viz kapitola 4).

3.2.1 Volání formuláře SAPscript

Předání dat do logiky formuláře probíhá u technologie SAPscript způsobem, při němž není volán celý formulář, nýbrž pouze jeho část, té je předána daná proměnná (například text popisující obchodní podmínky), kterou je nutné ve volané části vytisknout. Předaná data jsou nadále zpracována a přidána do vytvářeného formuláře. Po doběhnutí kódu v samotné části formuláře se běh programu vrací zpět ke kódu volacího programu, který následně může volat další části předlohy.

V tomto běhu jsou jak volací program, tak i samotný formulář reprezentovány kódem v jazyce ABAP, SAPscript tak dovoluje například v rámci tvorby výstupu ověřovat například jakému dodavateli je určený. V závislosti na obdržených může některé části běhu programu vynechat a tím některé prvky například na výsledný výstupní dokument neumístit.

Obrázek 3: Kód SAPScript formuláře (výstřižek z IS SAP)

Jednotlivé části SAPscriptu, které jsou postupně programem volány, můžeme tedy chápat jako dílčí funkce programu, kterým jsou předávány parametry v podobě shromažděných dat. Díky tomu, že je veškerý obsah formuláře realizovaného touto technologií nutno reprezentovat kódem v programovacím jazyce, je úprava SAPscriptu náročná a pro její provádění je nutné mít zkušenosti s programováním v jazyce ABAP (ABAP SAPscripts, 2019).

3.3 Smart Forms

Novější technologie Smart forms oproti rozhraní SAPscript poskytují uživateli několik výhod. Úprava je u této technologie značně rychlejší. Předlohy formulářů, které ji využívají, lze upravovat bez znalosti programování díky GUI v rámci SAP transakce SMARTFORMS pro jejich úpravu. Také dovolují generovat výstup ve formě XML souboru, což umožňuje zasílání formulářů webovou cestou.

Pro tisk formuláře pomocí technologie Smart Forms uživatel potřebuje jednak program, který zajistí data pro tvořený výstup a předlohu formuláře, která obsahuje veškerá pravidla pro tvorbu formuláře a jeho obsah (tyto pravidla jsou nazývána logikou formuláře).

V případě, kdy je potřeba provést změny na daném formuláři, uživatel většinou upravuje pouze předlohu formuláře a nijak nezasahuje do programu pro sběr dat.

Obrázek 4: Transakce SMARTFORMS (výstřižek z IS SAP)

Výhodou oproti technologii SAPscript je možnost vkládat kromě textu a grafiky také čárové kódy či tabulky, ty lze také vytvářet a upravovat skrze grafické rozhraní přímo v IS SAP. Uživatel provádí návrh rozložení Smartformu skrze grafické rozhraní úpravy formuláře (graphical form painter – viditelný v pravé části obrázku 4) a grafické rozhraní úpravy tabulek (graphical table painter). V těchto rozhraních je struktura formuláře zobrazena jako hierarchie jednotlivých prvků, ty se nazývají uzly (nodes – v češtině jsou běžně označovány jako nody), jednotlivé uzly každý reprezentují jinou složku výsledného formuláře. Existují například uzly s globálním nastavením (obsahují zastřešující informace pro formátování formuláře, jako jsou například velikost papíru či pravidla pro formátování konečného výstupu, patří mezi ně i uzel s definicí rozhraní pro přenos dat do Smart formu, více informací o tomto rozhraní viz kapitola 3.3.1), textové uzly či uzly grafiky (SMARTFORM BASICS, 2009).

Pro úpravu jednotlivých uzlů není zapotřebí používat programování, výjimkou jsou uzly, které obsahují přímo kód v jazyce ABAP, ty ovšem není nutné v rámci Smart Forms využívat, ale je možné je přidat do předlohy formuláře pro různé účely. Pokud například tiskneme fakturu určenou zákazníkovy, který preferuje imperiální jednotky, zatímco data z IS jsou v metrických jednotkách, je možné je pomocí takového uzlu s "miniprogramem"

převést podle potřebného poměru.

Pro většinu prvků Smart forms je možné nadefinovat podmínky, za kterých je nebo není proveden jejich tisk, v praxi je toto využitelné například tiskneme-li doklady určené pro odběratele v určitých zemích, ve kterých jsou požadovány na základě právních úprav definované texty, které popisují například původ zboží. Do formuláře technologie Smart Forms tak vložíme na určené místo daný text a nastavíme, aby se tiskl pouze pokud je daná podmínka (adresát z určité země) splněna. Pro nadefinování těchto podmínek slouží uživatelské rozhraní v transakci pro úpravu šablony formuláře, pro definování podmínek pro tisk tak podobně jako pro úpravu většiny částí formuláře není u této technologie zapotřebí programovacích dovedností.

Pro úpravu Smart Forms se v systému SAP užívají dvě různé transakce, těmi jsou transakce SMARTFORMS pro úpravu rozložení a obsahu předlohy formuláře a SMARTSTYLES pro úpravu stylu prvků v jejím rámci (odsazení, písmo, způsob zobrazování čárových kódů…) (Smart Forms, 2013), transakci SMARTSTYLES můžeme vidět na obrázku 5.

Do jednotlivých Smart formů můžeme vkládat i tabulky, mohou být statické či dynamické, ty dynamické jsou specifické tím, že obsahují kód v jazyce ABAP, který může například řadit jejich obsah či podmínky pro zobrazení různých verzí textu v dané tabulce. Grafika, kterou je možné do smart formů také vkládat, může být zobrazena dvěma způsoby – jako část formuláře a také jako grafika na pozadí (vodoznak), grafika na pozadí může být při tisku nastavena uživatelem jako neviditelná podle potřeby za využití podmínek (SMARTFORM BASICS, 2009).

Obrázek 5: Transakce SMARTSTYLES (výstřižek z IS SAP)

Narozdíl od technologie SAPscript, která je celá realizována skrze kód v jazyce ABAP, se u Smart Forms nedoporučuje vkládat přímo do formuláře kód, který by získával později vytisknuté informace přímo z databáze, veškerá data by měla být předávána skrze parametry externím programem pro sběr dat. Při dodržení tohoto doporučení jsou Smart Forms výrazně jednodušeji převeditelné na novější technologii PDF Forms by Adobe (Smart Forms, 2013).

Architektura smart formu zahrnuje následující prvky (SMARTFORM BASICS, 2009):

• rozložení stránky formuláře

• jednotlivé prvky, které mohou být zobrazeny ve formuláři

• logiku formuláře, ta řídí zpracování formuláře a může obsahovat také podmínkovou techniku, která ovlivňuje, kdy se zobrazí a nezobrazí jednotlivé prvky

• rozhraní pro přenos získaných dat z databáze do samotného formuláře (vysvětleno podrobněji v následující kapitole)

3.3.1 Volání Smart Forms

Hlavní rozdíl odlišující Smart Forms od technologie SAPscript je ve volání formuláře a předání dat, to probíhá podobně, jako kdybychom v objektově orientovaném programování volali metodu. Program volá takzvaný funkční modul, kterému předává jako parametry jednotlivé hodnoty proměnných definovaných jako rozhraní daného formuláře (Smart Forms, 2013).

Funkční modul každého Smart Formu je vytvořen při jeho aktivaci (založení) na daném prostředí informačního systému SAP, není tak pravidlem, že by jeho název byl vždy stejný.

Při vytváření programu, který volá daný Smart Form, tak vývojář musí nejprve zjistit jméno jeho funkčního modulu a teprve pak jej zavolat a předat mu požadované parametry.

Při generování výsledného tiskového výstupu podle nastavené logiky formuláře se využívá rozhraní Smart Formu, to si můžeme představit jako soubor proměnných, které jsou předdefinované v rámci vytváření předlohy formuláře a kterým jsou při volání jeho funkčního modulu předány hodnoty.

Není pravidlem, že by při volání Smart Formu musely být naplněny všechny prvky rozhraní, což lze využít pro definice v rámci podmínkové techniky, kdy můžeme například určit, že pokud jedné dané proměnné zůstane počáteční hodnota, nebude se část formuláře, kterou tato proměnná ovlivňuje, vůbec tisknout (SMARTFORM BASICS, 2009). Samotný funkční modul tak můžeme přirovnat v případě volání Smart Formu ke konstruktoru z objektově orientovaného programování a prvky rozhraní k jeho parametrům.

3.4 PDF formuláře Adobe

Třetí technologií, která v rámci SAP ERP verze R/3 dovoluje vytvářet výstupní dokumenty, jsou PDF formuláře Adobe. Princip, na jakém jsou formuláře tvořené tímto způsobem vystavěny, využívá ze značné části prvků starší technologie Smartforms a tvoří tak přechod mezi technologiemi dostupnými ve verzi R/3 a novou technologií PDF formulářů s fragmenty představenou ve verzi S/4 HANA.

PDF formuláře Adobe mohou být využity napříč jednotlivými aplikacemi IS SAP a jsou vhodné pro tisk většiny dokumentů. Jejich vytváření probíhá skrze transakci SFP (SAP Forms Process), hlavním rozdílem oproti předchozím technologiím je nutnost definování rozhraní před vytvořením samotného formuláře, je tak nutné vědět, jaké prvky (pole z databázových tabulek) chceme formuláři předávat již na začátku jeho tvorby, kdy sestavujeme samostatně stojící rozhraní. Sestavení funguje na stejném principu jako rozhraní u Smart forms, avšak s tím rozdílem, že je nezávislé na konkrétní předloze formuláře, a tak může být použito ve více formulářích.

Při vytváření rozhraní pro PDF formulář se můžeme rozhodnout, zdali chceme, aby bylo rozhraní kompatibilní i se Smart Forms, při zvolení této možnosti lze později volat daný formulář i tiskovým programem pro Smart Forms. Podmínky pro tisk jednotlivých prvků můžeme definovat již při vytváření rozhraní. Každé rozhraní má parametr 1BCDWB/DOCPARAMS, ten slouží k předání obecných informací, jako jsou kód země odesílatele/příjemce, jazyk výstupního dokumentu a další informace zastřešující celý formulář. Je využíván spolu s ostatními parametry, když je volán funkční modul formuláře.

Dalším parametrem, který je společný pro všechna rozhraní PDF formulářů, je 1BCDWB/

FORMOUTPUT, ten zajišťuje export formuláře ve formě pdf souboru a umožňuje ho tak předat pro další zpracování).

Při vytváření nového formuláře přidělujeme právě vytvářené předloze rozhraní, to ovšem neznamená, že všechny parametry rozhraní můžeme ihned použít pro předání dat finálnímu výstupu. Abychom mohli parametry rozhraní pro tvorbu výstupního dokumentu využít, je nutné umístit je do takzvaného kontextu formuláře, ten specifikuje, jaká data budou převzeta z rozhraní do formuláře, právě kontext formuláře umožňuje využívat jedno rozhraní pro různé formuláře.

Po předání dat do kontextu formuláře můžeme přistoupit k úpravě vzhledu formuláře a určení toho, jak se data na výsledném tiskovém výstupu zobrazí. Před nastavením samotného vzhledu můžeme také nastavit takzvaná globální data, která určí další potřebné specifikace, které nejsou předány rozhraním, můžeme přidat také menší části kódu v jazyce ABAP, které se před generováním formuláře provedou a určí jeho původní podobu nebo například nějak upraví data z rozhraní – takto mohou například být připraveny součty jakýchkoli hodnot pro pozdější zobrazení (Adobe Forms from Scratch, 2009).

Samotná úprava vzhledu formuláře probíhá v GUI, které je velice podobné programu Adobe LiveCycle designer (o jeho spojitosti s formuláři IS SAP se práce zmiňuje v rámci kapitoly 3.5). Dané GUI obsahuje opět Form painter, kde uživatel může nadefinovat rozložení jednotlivých oken, technologie PDF formulářů v tomto ohledu nabízí vylepšení oproti Smart forms v tom, že kromě statických prvků lze do jejích formulářů přidávat i prvky interaktivní jako například pole, do kterých lze vpisovat text, checkboxy či comboboxy, využitelnost těchto prvků však v současnosti klesá, jelikož ve většině webových prohlížečů již nejsou interaktivní webové formuláře podporovány (Is SAP Interactive Forms by Adobe Dead?, 2015).

Struktura návrhu PDF formulářů Adobe se skládá z několika částí, za pomocí kterých lze složit výslednou podobu výstupu. Orientaci, velikost, formát a rozložení jednotlivých stránek ovlivňují takzvané hlavní předlohy (Master pages), každá stránka vlastního formuláře (označuje se termínem body page) se odkazuje na předlohu, která určí její rozložení a pozadí. Každá stránka, na kterou plánujeme umístit nějaký obsah, musí být zastřešena oblastí obsahu (content area), tyto oblasti jsou opět součástí hlavní předlohy.

Rozložení PDF formulářů (layouty) dělíme na statická a dynamická. Statická mají pevně danou velikost prvků, dynamická jsou navržena tak, že jejich prvky se podle obsahu mohou v daných mezích zvětšovat či zmenšovat, což činí technologii PDF formulářů mnohem více flexibilní, nežli starší Smart Forms (Adobe Forms from Scratch, 2009).

3.5 PDF formuláře s fragmenty (SAP S/4 HANA)

Nová verze S/4 HANA přináší pro SAP i novou technologii pro dynamické generování výstupů, přičemž ale původní technologie známé i ze systému SAP R/3 zůstávají stále funkční. Původní myšlenkou firmy SAP SE bylo, že základní nastavení systému v nové verzi bude využívat pouze novou technologii, která se nazývá PDF formuláře s fragmenty (PDF Forms with Fragments) společně s novým způsobem řízení tiskových výstupů podle BRF+ (Business rule framework), od edice 1809 bylo ovšem od této myšlenky upuštěno a v základním nastavení systému jsou stále aktivní i starší technologie a využívání nových je možné zapnout. Pokud uživatelé tedy chtějí využívat starší technologie SAPscript, SMARTFORMS či PDF formuláře Adobe, je jim to umožněno, pokud chtějí využívat PDF formulářů s fragmenty, musí nejprve prostřednictvím kustomizace změnit nastavení determinace tiskových výstupů. Při přechodu ze starší verze systému na verzi S/4 HANA, stávající již nastavené dokumenty nadále využívají původních rozhraní (SAP S/

4 HANA Output Control, 2018).

Kromě nově stavěných předloh formulářů přináší SAP S/4 HANA i nové prostředky jejich úpravy, PDF formuláře s fragmenty totiž již nejsou upravovány přímo v prostředí informačního systému SAP, k jejich úpravě je využívaný program Adobe Livecycle designer (ALD), jeho uživatelské rozhraní můžeme vidět na obrázku 6. Příslušné soubory typu XDP, které jsou vkládány do programu ALD není možné získat ve standardním rozhraní systému SAP, nýbrž pouze skrze webové rozhraní SAP Fiori. Konkrétně export XDP souborů provádíme skrze aplikaci Údržba předloh formulářů (Maintain form templates) (Application form Templates, 2018). Program Adobe Livecycle designer je poskytovaný společně se systémem SAP pro využití při tvorbě formulářů následně využívaných uvnitř systému SAP (Providing Adobe Layout Technology for Form Processing, 2017).

Přímo v systému SAP pak lze udržovat standardizované texty pro výstupní dokumenty skrze transakci SO10. Texty mohou být vytvářeny v různých jazycích, při běhu pak systém správný jazyk vybere podle zamýšleného adresáta dokumentu, například pokud je u business partnera uvedena jako standardní jazyk italština a existuje verze formuláře v italském jazyce, je italština vybrána jako jazyk pro výstupní dokument.

Pokud jsou texty napevno zanesené v předloze formuláře, je nutné je manuálně přeložit v programu Adobe LiveCycle Designer (Maintaining Customized Master Forms, 2018).

Samotné PDF formuláře s fragmenty jsou technologií, která při tvoření konečného výsledku využívá dva samostatné celky, těmi jsou aplikační formuláře (application forms - v rámci systému je k nim odkazováno jako k šablonám formuláře), které upravují, jak se zobrazí jednotlivá data formuláře při tisku (například formát seznamu položek u prodejních dokladů). Tyto se pak odkazují na fragmenty (Master Form Templates, 2018) hlavních předloh formuláře (Master forms), ty určují celkové rozložení dokumentu a definují prvky jako je třeba logo firmy, či standardizované texty v záhlaví nebo zápatí (Form Types, 2018).

Obrázek 6: Adobe LiveCycle Designer (výstřižek uživatelského rozhraní)

Jak už bylo dříve řečeno, kombinací aplikačních formulářů a hlavní předlohy formuláře vzniká celková struktura tiskového výstupu. V aplikaci SAP S/4 HANA jsou v rámci řízení výstupů dodávány vzorové šablony pro aplikační formuláře i hlavní předlohy formulářů, tyto základní předlohy mohou být upraveny v rámci kustomizace systému, aby více vyhovovali potřebám daného podniku (Application form Templates, 2018).

Vzor hlavní předlohy formuláře definuje schéma rozvržení jedné či více stránek, toto rozvržení využívá aplikační formulář, může však odkazovat pouze na jeden typ rozložení stránek, to znamená, že nemůže využívat například první stránku z jednoho a ostatní stránky z jiné hlavní předlohy formuláře.

V základu jsou se systémem SAP S/4 HANA poskytovány dvě rozvržení hlavních předloh formuláře, SOMU_FORM_MASTER_A4 pro hlavní předlohu formuláře velikosti A4 a SOMU_FORM_MASTER_LETTER pro hlavní předlohu formuláře velikosti dopisního papíru. Součástí zmíněných předloh je rozvržení statických textů a grafiky.

Každá z hlavních předloh formuláře obsahuje následující fragmenty (Master Form Templates, 2018) :

• Landscape_Factsheet

• Landscape_ItemList

• Portrait_Factsheet

• Portrait_ItemList

• Portrait_OutboundLetter

Zmíněné fragmenty jsou rozděléné podle orientace (Landscape – na šířku, Portrait – na výšku) a varianty rozložení reprezentované druhou částí názvu (Factsheet – obecné informace, ItemList – seznam položek, OutboundLetter – dopis), jména fragmentů se nesmí měnit, jinak jsou při výsledném vytváření tiskového výstupu systémem ignorována.

Fragmenty představují jednotlivé formy rozložení prvků formuláře, které jsou k dispozici pro vytvářené výstupní dokumenty, při generování zpráv je na jednotlivé fragmenty odkazováno. Výběrem hlavní předlohy formuláře tak nevybíráme konkrétní vzhled finálního dokumentu, ten je rozvrhnut teprve podle odkazu na daný fragment. Může se stát, že v hlavní předloze formuláře není fragment vůbec definován, tato situace většinou

Obrázek 7: Schéma fragmentu hlavní předlohy formuláře (Fragment layout, 2018, překresleno prostřednictvím draw.io)

nastává, předpokládáme-li, že daná předloha bude používána pouze pro dokumenty, které budou mít specificky definovaný formát. Například odkazují-li se na předlohu formuláře pouze dokumenty orientované na výšku, není vůbec potřeba fragmentů typu Landscape.

Samotné fragmenty zahnují dvě další podčásti, těmi jsou předloha první stránky a předloha stránek následujících. Zmíněné předlohy v sobě nesou definici několika prvků důležitých pro výsledný vzhled výstupu. Jako příklad mohou být uvedeny velikost a orientace papíru, velikost obsahové části dokumentu a rozložení dílčích části dokumentu, jako jsou název formuláře, logo, číslo stránky, adresy (pokud jsou potřeba) nebo třeba bloky zápatí (Master Form Templates, 2018). Na obrázku 7 můžeme vidět schéma možného rozdělení prvků fragmentu.

Pro definici rozmístění obsahu pocházejícího z informačního systému SAP slouží aplikační formuláře, ty stejně jako hlavní předlohy formuláře můžeme upravovat prostřednictvím programu Adobe Livecycle designer. Zjednodušeně řečeno tak tato část PDF formulářů s fragmenty určuje, jaká data se objeví v jednotlivých oblastech definovaných hlavní předlohou formuláře. Narozdíl například od technologií Smartforms či PDF formulářů Adobe neprobíhá předání dat ze strany SAP ke zpracování skrze definované rozhraní, nýbrž skrze RFC (Remote Function call) bránu (gateway) SAPu (Application form Templates, 2018).

Technologie RFC slouží ke vzdálenému volání funkcí mezi jednotlivými systémy IS SAP či mezi SAPem a externími aplikacemi (RFC, 2017), v souvislosti s tiskovými výstupy slouží k předání dat právě vznikajícího výstupního dokumentu technologie PDF formulářů s fragmenty aplikaci Adobe Document Services, která zajišťuje vytvoření konečné podoby dokumentu za použití předloh vytvořených v programu Adobe Livecycle designer (Installing Adobe Document Services (ADS), 2018).

Volání PDF formulářů s fragmenty probíhá skrze rozhraní Forms processing framework (jeho fungování je popsáno v kapitole 4.3), tomuto rozhraní jsou předána data určená k umístění na finální výstup prostřednictvím funkčního modulu, který je nakonfigurován uživatelem při přípravě rozhraní BRF+ (viz kapitola 4.3) pro řízení tiskových výstupů.

V rámci rozhraní BRF+ jsou definované také veškeré proměnné, které slouží pro uložení a předání dat určených pro formuláře.

Na technologii PDF formulářů s fragmenty můžeme sledovat zjednodušení oproti technologii PDF formulářů Adobe, která při téměř stejných možnostech byla daleko složitěji customizovatelná a pro obyčejného uživatele také složitěji uchopitelná. PDF formuláře s fragmenty disponují mnohem jednodušší strukturou pouze o dvou hlavních prvcích, které dohromady tvoří celkový výstup (Form Types, 2018).

Obrázek 8: Objekty proměnných v BRF+

(výstřižek z webového prostředí SAP)

4 Řízení zpráv

V rámci informačního systému SAP jsou nalezení správného tiskového formuláře pro daný vytvořený dokument a jeho následný tisk zabezpečeny mechanismem řízení zpráv. Tento systém podle předem nadefinovaných podmínek pomáhá zabezpečit tiskové výstupy činností v rámci IS, zejména podobu vytvořeného dokumentu, čas a způsob uvolnění výstupu (dokument nemusí být pouze tisknut, může být i rovnou odesílán svému adresátovi například e-mailem). Z důvodu odlišností tohoto mechanismu v různých verzích SAP je tato kapitola nadále rozčleněna na informace týkající se systému SAP R/3 a ty, které se týkají verze SAP S/4 Hana.

4.1 Determinace druhu výstupu v SAP R/3

Systém SAP R/3 nabízí v rámci několika svých modulů systém řízení výstupních zpráv, ten se v jednotlivých nastaveních pro různé moduly liší, a tak v rámci kustomizace systému je řízení výstupů součástí nastavení každého modulu zvlášť. Jednotlivé výstupní zprávy lze ale také centrálně spravovat skrze transakci NACE, data z této transakce se ukládají do tabulky NAST, která nám umožňuje provádět nastavení pro jednotlivé druhy zpráv, které zde přiřazujeme k jednotlivým aplikacím v rámci různých modulů, například všechny zprávy související s nákupními objednávkami (objednávka, změna objednávky, upomínka,...) jsou skrze zmíněnou transakci přiřazeny k druhu aplikace EF.

Obrázek 9: Změna výstupních podmínek v transakci NACE (výstřižek z IS SAP)

Typický postup determinace druhu výstupu v systému SAP R/3 můžeme dobře vidět na tisku nákupního dokladu z modulu MM (materiálové hospodářství). Objednávky i zprávy o jejich změnách je ve většině případů nutné doručit dodavateli. Jednotlivé zprávy však nemusí být vždy tisknuté na papír, jako alternativa klasického tisku mohou fungovat také automatický e-mail ihned po uložení dokumentu nebo doklad ve formě datové věty standardu EDI. Výběr výstupního média lze pak provést v závislosti na dodavateli či druhu zprávy (nový tisk objednávky, upomínka, upomínka zaslání potvrzení objednávky…). Systém dovoluje nastavit pro různé druhy dokumentů pro jednoho dodavatele i různé druhy výstupních médií, nastavení podmínek pro řízení tiskových výstupů lze provádět jako součást kustomizace IS SAP.

Při vytváření nákupního dokladu vždy vzniká výstupní zpráva, systém ještě předtím musí jednoznačně určit správný druh zprávy a formu odeslání pro daného dodavatele.

Obrázek 10: Schéma nalezení výstupního média

(Maasen, 2007, s. 238, překresleno prostřednictvím draw.io)

Na obrázku 10 výše můžeme vidět graficky znázorněný průběh určení výstupního média pro objednávku při jejím uložení. Při uložení objednávky systém vybere druh zprávy

„Nová objednávka“ a k němu určí odpovídající formulář s texty, podle něhož je dán vzhled výsledného dokumentu (ke každému druhu zprávy je přiřazen volací program, který shromáždí data a dá jim výslednou strukturu podle předlohy formuláře viz. Kapitola 3).

S druhem zprávy je spjaté tzv. pořadí přístupu, to obsahuje kombinace polí, podle nichž jsou prohledávány podmínkové tabulky a v nich uložené záznamy. Systém pak prohledává tabulky podmínek a mezi jednotlivými záznamy hledá takový, který by vyhovoval informacím z hlavičky uloženého dokladu. Když nenajde vyhovující záznam, hledá pak systém v následující podmínkové tabulce určené pořadím přístupu. V příkladu výše byl jako vyhovující výstupní médium podle podmínkového záznamu v první tabulce nalezen fax díky tomu, že se jedná o doklad typu NB pro dodavatele 99005 spadající pod nákupní organizaci 1000, kdyby v této tabulce podmínek nebyl záznam nalezen, systém by vybral v následující tabulce jako výstupní médium tiskárnu, která je nadefinována jako základní výstupní médium pro typ dokladu NB. V rámci kustomizace je možné jednotlivé druhy zpráv, pořadí přístupu a atributy tabulek podmínek definovat (Maasen, 2007).

4.2 Proces uvolnění tiskové zprávy

Každá vzniklá zpráva je automaticky zařazena do fronty zpráv, odkud k jejímu vytisknutí dojde v ten čas, který je zvolen při nastavení parametrů času odeslání dané zprávy (toto nastavení je také součástí kustomizace IS SAP). Pro zprávy, které mají být vytištěny, musí být vytvořeny tzv. spoolové požadavky, ty slouží jako příprava tisku a odkazují na úložiště, kde je umístěna dočasná kopie finálního výstupu – provedením tisku můžeme pak rozumět odeslání dat spoolového požadavku na určitou tiskárnu, fax či jiné výstupní médium.

K jednomu požadavku lze zadat více výstupních zařízení, a tak je možné tisknout jeden doklad například na dvou různých tiskárnách.

Kdy samotný tisk nastane, záleží na nastavení parametru času odeslání, u automaticky odesílaných zpráv systém nabízí čtyři základní možnosti (Maasen, 2007):

• Odeslání pomocí periodicky plánovaného jobu. Toto je zajištěno programem, který je nastaven tak, že v pravidelných intervalech prochází frontu zpráv a čekající zprávy, u kterých je zvolen tento parametr, překlápí ve spoolové požadavky. Ty jsou později měněny na výstupní požadavky a tištěny. Vytvoření spoolových a výstupních požadavků lze ovládat i ručně. Pojmem job se rozumí program s předem nakonfigurovanými vstupními údaji běžící na pozadí.

• Odeslání pomocí jobu s dodatečným časovým údajem. V okamžiku vytváření zprávy je zadáván i datum a čas, který značí, kdy je možné zprávu překlopit ve spoolový a dále také výstupní požadavek, do té doby zprávu ve frontě zpráv program ignoruje.

• Odeslání pomocí vlastní transakce aplikace. Spoolové a výstupní požadavky jsou v tomto případě tvořeny až použitím příslušného programu.

• Okamžité odeslání. K vytvoření spoolového požadavku dojde ihned po uložení případného dokumentu, systém vůbec nevyužívá frontu zpráv.

4.3 Determinace druhu výstupu v SAP S/4 Hana

Systém SAP S/4 HANA umožňuje v rámci verze 1809 využívat původní systém řízení tiskových výstupů, známý ze systému SAP R/3, ten je nastaven jako základní při implementaci systému, jeho nevýhodou ovšem je, že jeho prostřednictvím nelze využívat PDF formuláře s fragmenty (viz. kapitola 3.5) a zároveň vyžaduje oddělené nastavování pro každý modul informačního systému. Řízení výstupů ve verzi S/4 je oproti tomu konfigurováno v rámci jedné zastřešující oblasti informačního systému a je šité na míru přímo nové technologii tvoření dynamických tiskových výstupů (Henninger, 2016).

V nejnovější verzi systému SAP je tak možné využívat novou technologii určení formy tiskového výstupu pro jednotlivé aplikace, která je kustomizována na jednom místě v rámci komponentů nad rámec aplikace, tedy oblasti zastřešující nastavení, která propojují veškeré moduly systému. Pro definování podmínek pro určení předlohy formuláře se v nové technologii již nepoužívá transakce NACE s tabulkou NAST, nýbrž rozhraní nazvané

BRF+ (business rule framework +), které běží kompletně v internetovém prohlížeči, pro používání tohoto prostředku za účelem řízení tiskových výstupů je nutné splnit několik předpokladů.

Pro umožnění řízení výstupů skrze BRF+ musíme zajistit nastavení vzdáleného volání funkcí na pozadí (background RFC, objasnění pojmu RFC je součástí kapitoly 3.5), musí být nastaveno přechodné úložiště pro vytvořené PDF formuláře před vytisknutím a nainstalovaná aplikace Adobe Document Services, která zajišťuje generování výstupního dokumentu dle předlohy. Do systému BRF+ je poté skrze XML soubor poskytovaný podporou SAP třeba nahrát jednotlivá kritéria (jednotlivé podmínkové tabulky) pro výběr předlohy formuláře, tím jsou splněny všechny předpoklady pro použití nového řízení tiskových výstupů (Setup and Configuration of SAP S/4HANA Output Control, 2017).

Zmíněné XML soubory obsahují nejen podmínkové tabulky, ale i přednastavení vazeb jednotlivých proměnných a datových struktur používaných při vytváření formuláře na databázové tabulky informačního systému SAP stejně jako funkční moduly pro získání dat pro formuláře a odeslání dat skrze RFC ke zpracování ve službě Adobe document services.

Výběr předlohy pro finální tiskovou zprávu probíhá v novém procesu v několika krocích, z nichž každý je zastoupený podmínkovou tabulkou, jíž uživatel upravuje, aby nastavil podmínky, za kterých dojde k automatickému vytištění zvoleného dokumentu v nastavené Obrázek 11: Rozhraní pro stanovení parametrů tiskových výstupů

(výstřižek z webového prostředí IS SAP)

formě. Podobně, jako tomu bylo v původním řízení tiskových zpráv, slouží ke komplexnímu nastavení zmíněných podmínek jednotná transakce, která v SAP S/4 HANA nese název OPD, spuštění této aplikace uživatele přenese do internetového prohlížeče, kde může nadefinovat (pozměnit) obsah jednotlivých podmínkových tabulek nahraných během příprav do systému BRF+. Vzhled transakce OPD pro definici výstupních podmínek tiskových dokumentů můžeme vidět na obrázku 11.

Postupné určení finálního tiskového výstupu systémem si můžeme dobře ukázat na příkladu faktury odběrateli. První tabulka, kterou systém prohledává, určuje, o jaký typ dokumentu se jedná, pro fakturu se jedná o typ BILLING_DOCUMENT, ve stejné tabulce může být nastaven i druh daného dokumentu, má-li podrobnější dělení, můžeme tak již v tomto bodě vytvořit různé podmínkové zápisy například pro faktury a dobropisy, které jinak spadají pod stejný typ výstupu, nakonec určíme čas vytvoření výstupního dokumentu, pro ten existují dvě možnosti, v nastavení 1 dojde k tisku výstupního dokumentu ihned, při nastavení 2 dojde k vytisknutí dokumentu teprve po užití speciální transakce, která zadaná data i více dokumentů najednou odešle ke zpracování a následně do tiskové fronty.

Další definovatelnou podmínkou je role příjemce dokladu, ta je stanovena v návaznosti na typ dokladu a může být využita také pro vyloučení dokumentu z procesu determinace, není-li například role příjemce shodná s rolí definovanou v tabulce, dokument se nevytiskne. V další tabulce uživatel definuje výstupní kanál pro daný typ dokumentu, může volit mezi kanály PRINT (přímé vytisknutí), E-MAIL (automatické zaslání výstupu e-mailem s průvodní zprávou), XML či IDOC. Poslední dva zmíněné kanály generují datové věty, které musí druhá strana přeložit pomocí příslušného programu a jejich kustomizace je v novém způsobu determinace tiskových výstupů značně omezena, doporučuje se tak pro ně využívat spíše staršího způsobu determinace tiskových výstupů známého z předchozích verzí SAP.

Podle zvoleného výstupního kanálu pak systém vyhledává v dalších tabulkách podmínky určené pro stanovený kanál. Pokud je například výstupním kanálem dokumentu kanál PRINT, pak v následující tabulce zvolí systém přednastavenou tiskárnu. V dalších podmínkových tabulkách program nachází definovanou šablonu aplikačního formuláře, podle které budou na konečný výstup přenesena data (viz. kapitola 3.5). U fakturačních formulářů je taky možné nadefinovat, v jaký okamžik se doklad stává relevantním pro tisk,