(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,
můžeme například určit, že doklad bude tisknut teprve když je uvolněn do účetnictví.
Prostřednictvím tabulek určená šablona formuláře se v následujícím kroku podle kritérií určených v rámci kustomizace systému propojí s hlavní předlohou formuláře, která určí rozložení formuláře v rámci výstupního média, například rozestavění jednotlivých polí na papíře (Output Management via BRF+, 2016).
Při řízení výstupů za využití BRF+ dochází v příslušném momentě, kdy má být dokument vytisknut, k volání šablony formuláře rozhraním Forms processing framework (Rozhraní pro zpracování formuláře). FPF z nastavení aplikace pro tisk příslušného typu dokladu zjistí potřebná data pro vytvoření programu a ta zajistí pomocí příslušného funkčního modulu definovaného v BRF+, poté potřebná data a údaje zjištěné pomocí determinace výstupu na základě parametrů tisknutého dokladu předá skrze vzdálené volání funkcí na pozadí (bgRFC), programu Adobe Document Services (ADS), data tak putují mimo SAP (Crapo, 2019).
Následně ADS použije získaná data a po spojení šablony formuláře a hlavní předlohy formuláře uspořádá formulář do výsledné podoby a předá jej zpět systému SAP, který ho zařadí do zvolené tiskové fronty nebo rovnou zašle v závislosti na definovaných parametrech výstupního kanálu. (Configuring Adobe Document Services for Form Processing (ABAP), 2017).
5 Srovnání popsaných technologií
Tato kapitola slouží jako souhrn navazující na předchozí kapitoly a vystihuje důležité charakteristiky jednotlivých technologií a zamýšlí se nad jejich využitelností.
5.1 Technologie pro vytváření výstupních zpráv
Informační systém SAP za dobu svojí existence představil již několik technologií pro vytváření výstupních zpráv. Díky rozhodnutí firmy SAP SE, která se bude i v nejnovější verzi SAP S/4 HANA podporovat technologie používané ve verzi SAP R/3, existují pro uživatele celkem čtyři možnosti, nejstarší SAPscript, přehlednější Smart Forms, PDF formuláře Adobe a PDF formuláře s fragmenty.
V postupném vývoji těchto technologií můžeme sledovat trend jistého zjednodušování a zpřístupňování úpravy předloh formulářů i uživatelům méně zběhlým v programování, největší skok v tomto směru můžeme sledovat mezi technologií SAPscript, kde je celá předloha formuláře reprezentována (kromě rozložení jednotlivých oken) pouze kódem v programovacím jazyce ABAP, a Smart Forms, pro jejichž úpravu se již používá přehledné grafické uživatelské rozhraní a obsah je přehledně rozdělen do jednotlivých uzlů, které mohou být relativně jednoduše upravovány.
Přínos Smart Forms můžeme sledovat také v tom, že jako první obsahovaly rozhraní pro přenos dat, které umožnilo volání celého formuláře v programu podobným postupem, jako například při volání metody v objektově orientovaném programování. Na tomto rozhraní staví také PDF formuláře Adobe, které byly poslední technologií představenou pro SAP R/3, přinesly možnost využívat jedno rozhraní pro více formulářů, s čímž přišla ale také větší náročnost na promyšlený koncept výstupního dokumentu, který tvůrce musel mít připravený již během tvorby počátečního rozhraní.
PDF formuláře Adobe obsahovaly kromě nového přístupu ke tvorbě rozhraní i nové prvky pro tvorbu formulářů, které dovolují vytvářet interaktivní formuláře. I když v době uvedení představovali tyto formuláře zajimavou možnost, v současnosti bohužel kvůli problémům s kompatibilitou interaktivních prvků s webovými prohlížeči a složitosti samotné tvorby šablony formuláře tato technologie ztrácí na oblibě, jelikož její využitelnost se stává srovnatelnou s využitelností Smart Forms, jejichž úprava je mnohem méně náročná.
Z PDF formulářů Adobe a Smart Forms čerpá technologie PDF formulářů s fragmenty, ta byla představena společně se SAP S/4 HANA. Při tvorbě šablon této technologie již není nutné definovat data potřebná k naplnění výsledného výstupu, ta jsou definovaná pro každý typ dokladu předem v rámci přednastavení řízení výstupních zpráv skrze BRF+, můžeme tak říct, že rozhraní pro předání dat je u této technologie postavené mimo formulář. Tvůrce šablony ovlivňuje pouze to, co se vytiskne v rámci finální výstupní zprávy prostřednictvím šablony formuláře a rozložení spolu s grafikou výstupu prostřednictvím zvolené hlavní předlohy formuláře.
Za největší změnu ohledně technologie použité ke generování výstupních zpráv můžeme označit přenesení veškerých aktivit spojených s úpravou vzhledu a vlastního generování finální podoby formuláře mimo vlastní prostředí IS SAP u PDF formulářů s fragmenty, jejichž vzhled je upravován prostřednictvím programu Adobe Livecycle designer, jednotlivé šablony formulářů pro úpravu je možné získat pouze skrze aplikaci Údržba předloh formuláře v SAP Fiori.
Každá z představených technologií pro tvorbu výstupních zpráv má své výhody i nevýhody. Nejstarší SAPscript má velkou nevýhodu v reprezentaci předlohy finálního výstupu pouze skrze kód v jazyce ABAP, což tuto technologii dělá nepřehlednou pro uživatele bez znalostí tohoto programovacího jazyka. To samé, co je pro SAPscript největší nevýhodou, skýtá pro uživatele zběhlé v programování SAPu výhodu, jelikož mají naprostou kontrolu nad průběhem tvorby formuláře. Taková kontrola u ostatních technologií není možná, jelikož funkční moduly pro generování formuláře u nich vytváří sám systém.
PDF formuláře Adobe díky možnosti využití jednoho nadefinovaného rozhraní slibují větší variabilitu a rychlejší nastavení rozhraní formuláře. Kvůli mezikroku v podobě uvedení prvků rozhraní do kontextu formuláře, kdy vývojář musí jednotlivé prvky "zpřístupnit"
formuláři, ztrácí využití přednastaveného rozhraní téměř smysl, jelikož konečný soubor parametrů formuláře musí být stále ručně definován. Složitá struktura formuláře činí jeho úpravu ještě více složitou. Vzhledem k tomu, že výsledné možnosti PDF formulářů Adobe jsou srovnatelné se Smart Forms, pokud pomineme prvky pro tvorbu interaktivních prvků a tabulky s dynamicky se měnící velikostí, není technologie PDF formulářů Adobe zajimavou volbou, jelikož by mohla spíše zdržovat úpravy jednotlivých formulářů.
Pro finální využití v rámci podniku se vhodnějšími díky širokým možnostem a srozumitelnému způsobu nastavení stávají dvě z existujících technologií tvorby výstupů, těmi jsou Smart Forms a PDF formuláře s fragmenty. Při srovnání těchto dvou se paradoxně starší Smart Forms zdají být univerzálnější a lépe přizpůsobitelné potřebám v rámci různých situací chodu podniku, je možné do nich vkládat kód ABAP a vytvářet tak unikátní pravidla pro každý formulář. U PDF formulářů s fragmenty je nutné definovat všechna data, která se zobrazí na formuláři, předem v rozhraní BRF+, kód ABAP nelze přímo do šablony formuláře vkládat, jelikož samotná tvorba formuláře probíhá mimo prostředí SAP, v programu, který není postaven na jazyce ABAP a neumí jej ani spouštět.
Technologie ze SAP S/4 HANA tak opět klade větší nároky na přípravu dat před samotnou tvorbou formuláře, její velkou výhodou ovšem je, že může využívat determinaci výstupních zpráv podle BRF+ a pro každý samostatný formulář není nutné definovat volací program, jako je tomu u Smart Forms.
Díky velké univerzálnosti a přizpůsobitelnosti se tak nakonec nejvyužitelnější technologií pro tvorbu výstupních zpráv zdají Smart Forms, jelikož jsou dostupné v SAP R/3 i SAP S/4 HANA a možnosti jejich úpravy jsou téměř nekonečné, jejich nevýhodou je nutnost vytvářet pro každý formulář nový volací program.
PDF formuláře s fragmenty nabízejí podobné možnosti ohledně vložitelného obsahu jako Smart Forms, nicméně není možné v rámci jejich tvorby manipulovat s daty prostřednictvím kódu a pro úpravu i tvorbu formulářů je nutné využívat programy mimo rámec informačního systému SAP, přičemž spravovat jednotlivé předlohy formulářů je možné zpracovat pouze skrze launchpad SAP Fiori. Celá technologie působí dojmem, jako by byla primárně vytvářena pro cloudovou SaaS verzi informačního systému SAP S/4 HANA a její nastavení je rozděleno na několik aktivit na různých místech, což oproti Smart Forms, kde většina nastavení probíhá při vytváření šablony formuláře, působí velice složitě.
Smart Forms se tak jeví jako nejlepší volba při výběru technologie pro tvorbu výstupních dokumentů v SAP R/3 a dokud budou stále podporovány, tak i v SAP S/4 HANA.
PDF formuláře s fragmenty jsou zajimavou novou možností, ovšem kvůli vyšší složitosti úprav své využití najdou spíše v cloudové verzi SAP S/4 HANA a u uživatelů, kteří implementují SAP S/4 HANA jako svou první verzi IS SAP.
5.2 Řízení výstupních zpráv
Determinace předlohy a formy výstupu ve verzi SAP R/3 je řešena odděleně v rámci kustomizace pro každý modul, kdy každému typu dokumentu je přidělena jeho předloha a volací program. To, jaká předloha výstupu bude vybrána, je ovlivěno podmínkovými tabulkami, které systém prohledává dle předem definovaného pořadí přístupu k nim.
Veškerá nastavení pro výstupní zprávy v rámci tohoto typu determinace jsou k dispozici v databázové tabulce NAST.
Když je v podmínkové tabulce nalezen záznam odpovídající situaci (například zaúčtování faktury pro specifického odběratele), systém zavolá přiřazený program pro tvorbu výstupu a vytvořený dokument odešle ve zvolený čas skrze zvolené médium.
Tento postup řízení zpráv můžeme využít pro všechny formuláře s předlohami vytvořenými pomocí technologií známých ze SAP R/3 a je možné jej využívat i ve verzi SAP S/4 HANA.
Oproti determinaci tiskových výstupů známé ze SAP R/3 je řízení zpráv skrze BRF+
představené v SAP S/4 HANA řešeno jednotně pro všechny moduly, jeho nastavení probíhá přes Webdynpro (uživatelské prostředí IS SAP běžící v prohlížeči) a je navržené specificky pro technologii PDF formulářů s fragmenty.
Pomocí souborů XML jsou do BRF+ nahrány objekty, které v sobě zahrnují jednotlivé tabulky podmínek, proměnné pro uložení dat určených pro zpracovávaný formulář, pravidla a funkční moduly pro zpracování a odeslání dat pro tvorbu formuláře, každý z objektů se váže k určitému typu výstupního dokladu.
Skrze nadefinované podmínky v BRF+ je podle vstupních dat vybrán výstupní kanál zprávy a její formulář, kterému je přiřazena hlavní předloha, data o šabloně formuláře a připravovaném výstupním dokumentu jsou odeslána skrze RFC bránu mimo IS SAP do programu ADS (Adobe Document Services), který zajistí sestavení finálního výstupu a předá jej zpět IS, ten pak zajistí odeslání výstupního dokumentu.
Řízení výstupních zpráv skrze BRF+ lze využít pouze pro PDF formuláře s fragmenty.
Původní koncept SAP S/4 HANA počítal s využitím pouze nového řízení zpráv, od tohoto kroku však firma SAP SE upustila, a tak v edici SAP S/4 HANA 1809 je možné použít
původní determinaci výstupů známou ze SAP R/3. Při přechodu ze systému SAP R/3 na SAP S/4 HANA tak stávající výstupní zprávy zůstávají funkční a novou determinaci je možné posléze zapnout, přeje-li si tak uživatel učinit.
Oba dva možné způsoby řízení zpráv mají své výhody i nevýhody. Determinace výstupních podmínek skrze BRF+ má velkou přednost díky tomu, že je řešena nad rámec všech modulů SAP, a tak je její nastavení jednotné pro všechny typy dokumentů z různých částí podnikového procesu. Nevýhodami řízení skrze BRF+ jsou složitější příprava, kdy je potřeba nejdříve připravit tabulky výstupních podmínek, a to, že tato technologie řízení je vhodná pouze pro PDF formuláře s fragmenty. Tvorba výstupního dokumentu také probíhá mimo IS SAP, kam jsou data předána skrze bgRFC, tento způsob komunikace mezi programy je nutné před spuštěním tohoto řízení také nakonfigurovat.
Původní řízení výstupů známé ze SAP R/3 dovoluje využití všech technologií tvorby výstupního dokumentu známých z této verze. I přes větší složitost svého nastavení a absenci možnosti volat PDF formuláře s fragmenty se v současné době, kdy po přechodu ze SAP R/3 na SAP S/4 HANA (edice 1709 a novější starší tuto determinaci nepodporují, původně bylo firmou SAP SE zamýšleno, že by nešlo využívat jiné tiskové determinace než přes BRF+) bude většina firem mít své vlastní formuláře připravené pomocí starších technologií, které skrze BRF+ nelze determinovat. Nový způsob řízení tiskových výstupů tak nejspíše nalezne největšího využití zvláště u uživatelů, kteří implementují poprvé SAP již ve verzi S/4 HANA a také u uživatelů cloudové verze tohoto IS.