Aplikace byla naprogramována pomocí JavaScriptu a SAPUI5 ve verzi 1.84 s podporou od SAP až do konce roku 2023.[31] Po dobu celého vývoje se nevyskytnul žádný problém s komponentami SAPUI5 a jejich předdefinovanými metodami. Celá aplikace využívá základní design komponent SAPUI5, který odpovídá designovým pravidlům SAP Fiori.
Zároveň se snažilo dodržet SAP Fiori UX pravidla, pro zachování stejného chování jednotlivých prvků aplikace, jak je pro uživatele těchto aplikací zvykem. Jedním takovým případem porušení SAP Fiori UX pravidla bylo nepoužívat tabulku pro vstupy protože
„responzivní tabulka není optimalizována pro vstupy ve tvaru formuláře,“7 [32] (překlad autora) ale pro zjednodušení práce zaměstnanci to je nejlepší řešení, proto bylo toto doporučení nebrat v potaz a použít tabulku se vstupy v jednotlivých řádcích pro vyplnění záznamu.
Vývoj aplikace byl rozdělen na 4 sprintů, jak už bylo zmíněno (viz. Časový plán). První sprint byl věnovaný vývoji hlavní obrazovce zaměstnance a mzdové účetní. Při tomto sprintu byla věnována největší pozornost filtrům, aby získaná data odpovídala zvoleným filtrům.
Vytvoření hlavní tabulky nebylo náročné, SAPUI5 obsahuje komponentu smartTable, ve které se nadefinují sloupce tabulky, formát zobrazení a zdroj dat a smartTable si data poté získává ze SAP SF automaticky s definovanými filtry. Na ukázce kódu (viz. Výpis 4) je funkce, která se volá předtím, než si smartTable posílá dotaz na SAP SF. V této funkci lze přidat další hodnoty z databáze, které chceme získat mimo těch, které jsou definované v tabulce a přidat filtry, které nejsou textové. Jedná se třeba o filtr statusu, kde se vybírá hodnota z picklistu (viz. Výpis 5).
Výpis 4: Ukázka funkce onBeforeRebindTable v kontroleru pro hlavní obrazovku
MasterPage.prototype.onBeforeRebindTable = function (oEvent) { var tokenOrFilters = [];
var mBindingParams = oEvent.getParameter("bindingParams");
mBindingParams.parameters.expand = "cust_accountantNav";
mBindingParams.parameters.select = mBindingParams.parameters.select +", externalCode, cust_accountant, cust_personId";
var accountantTokens =
sap.ui.getCore().byId("cust_accountantIdForm").getTokens();
// add accountant filter
if (accountantTokens.length !== 0 && Constants.isAccountant === true) { accountantTokens.forEach(function (token) {
tokenOrFilters.push(this.createFilter("cust_accountant", token.getKey()));
}.bind(this));
oEvent.getParameters().bindingParams.filters.push(new sap.ui.model.Filter({
filters: tokenOrFilters, and: false
}));
}
//add status filter
var statusKey = sap.ui.getCore().byId("cust_status_select").getSelectedKey();
if (statusKey !== "allItems") {
oEvent.getParameters().bindingParams.filters.push(this.createFilter("cust_status", statusKey));
};
Výpis 5: Ukázka definice filtru pro field cust_status
Druhý sprint byl věnovaný vývoji části aplikace, která řeší vypracování formuláře žádost.
Tento sprint nakonec trval déle než bylo předem plánováno, neboť se zde muselo věnovat hodně času nahravání příloh k jednotlivým částem formuláře. Pro nahrávání souborů byla použita komponenta UploadCollection a hodně času zabralo vytvoření mapovní souborů, aby se soubor nahrál ke správné slevě. Pro rozdělení formuláře na části byla použita komponenta Wizard, která tvoří jednotlivé kroky a umožňuje tím zobrazovat obsah stránky postupně podle potřeby. Pro vyplňování infromací byly použity tabulky s inputy, ale jak už bylo zmíněno porušilo se tím SAP Fiori UX doporučení, ale pro jednoduchost a přehlednost to bylo nejlepší řešení.
Na ukázce kódu (viz. Výpis 6) můžeme vidět celý kód souboru view, který tvoří obrazovku žádost. Hlavními částmi view je content a footer. Content obsahuje pouze komponentu Wizard, která je dále tvořená jednotlivými kroky. Celkem je tvořená 5 kroky a každý krok obsahuje fragment. „Fragmenty jsou nenáročné části uživatelského rozhraní“8 [33]
(překlad autora), neboli další soubor tvořící části UI. Footer obsahuje tlačítka pro akce uložit, potvrdit a vrátit změny.
<smartFilterBar:ControlConfiguration id="statusFilter"
visible="{viewModel>/isAccountant}" key="cust_status" label="{i18n>cust_status}"
visibleInAdvancedArea="true" controlType="dropDownList" index="7">
<smartFilterBar:customControl>
<Select id="cust_status_select" selectedKey="waiting">
<core:Item key="allItems" text=""/>
<core:Item key="inProcess" text="{i18n>status_InProcess}"/>
<core:Item key="returned" text="{i18n>status_returned}"/>
<core:Item key="waiting" text="{i18n>status_waiting}"/>
<core:Item key="done" text="{i18n>status_done}"/>
</Select>
</smartFilterBar:customControl>
</smartFilterBar:ControlConfiguration>
Výpis 6: Ukázka definice komponenty Wizard pro obrazovku žádost
<WizardStep id="taxClearing" title="{i18n>title_TaxClearing}">
<core:Fragment fragmentName="etax.view.request.TaxClearing" type="XML" />
</WizardStep>
<WizardStep title="{i18n>title_IncomeFromDependentActivity}">
<core:Fragment
fragmentName="etax.view.request.IncomeFromDependentActivity" type="XML" />
</WizardStep>
<WizardStep title="{i18n>title_TaxAllowanceForASpouse}">
<core:Fragment fragmentName="etax.view.request.TaxAllowanceForASpouse"
type="XML" />
</WizardStep>
<WizardStep title="{i18n>title_TaxAllowanceForChildPlacement}">
<core:Fragment
fragmentName="etax.view.request.TaxAllowanceForChildPlacement" type="XML" />
</WizardStep>
<WizardStep title="{i18n>title_NonTaxableAmountsOfTheTaxBase}"
validated="false">
<Button id="undoChangesBtn" width="14em" text="{i18n>undoChanges}"
icon="sap-icon://undo" visible="{viewModel>/modelChange}" class="sapUiSmallMarginEnd"
Třetí sprint se věnoval vývoji obrazovkám pro vyplňování prohlášení a dodatečného prohlášení. V tomto sprintu bylo zapotřebí zajistit, aby se jednotlivé UI fragmenty daly využit jak pro prohlášení, tak i pro dodatečné prohlášení, ale pro uchování dat používá prohlášení a dodatečné prohlášení jiné objekty databáze, proto bylo zapotřebí vytvořit mapování, které by zajistilo při vyplňování prohlášení, ukládání do dat do objektů pro prohlášení a při vyplňování dodatečného prohlášení do objektů pro dodatečné prohlášení.
Pro rozdělení obrazovky na jednotlivé části byla zvolena komponenta ObjectPageLayout, která netvoří jednotlivé kroky, jak je tomu u žádosti, ale každá část má vytvořenou navigaci v menu liště. Pro volbu této komponenty místo komponenty Wizard byly 2 zásadní důvody, samotný formulář není tak obsahově náročný jako žádost, tak nebylo zapotřebí zobrazovat obsah postupně a dalším důvodem je že komponenta Wizard neumožnuje jednotlivé kroky schovat, tím pádem by zaměstnanec při prvotním vyplňovaní prohlášení a při vyplňování dodatečného prohlášení viděl i část, kde se vyplňují změny v prohlášení.
Čtvrtý a poslední sprint byl věnovaný vývoji obrazovce pro kontrolu formulářů ze strany mzdových účetní. Kontrola prohlášení, dodatečného prohlášení a žádosti byla sjednocena do jedné obrazovky, kde bylo zajištěno zobrazení obsahu na základě typu formuláře. Pro zobrazení obsahu byla využita komponenta List, která obsahuje všechny části všech formulářů, ale při vykreslování view se v listu zobrazují pouze ty části, které odpovídají typu formuláře. Zároveň se zobrazují pouze ty části z formuláře, které zaměstnanec uplatňuje, například pokud zaměstnanec v žádosti neuplatňuje slevu na manžela/ku, mzdový účetní se ani tato sleva nezobrazí. Obrazovka kontrola mzdovou účetní se skládá ze dvou view souborů, jeden view soubor obsahuje výše zmíněný list a druhý view soubor slouží pro zobrazení fragmentů s detailem slevy.