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