Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Aplikace na zpracování daňových formulářů v SAP SuccessFactors
BAKALÁŘSKÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Aplikovaná informatika
Autor: David Ramba
Vedoucí bakalářské práce: RNDr. Helena Palovská, Ph.D.
Praha, květen 2021
Prohlášení
Prohlašuji, že jsem bakalářskou práci s názvem Aplikace na zpracování daňových formulářů v SAP SuccessFactors vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Letohradu dne 9. května 2021 ………..……….
David Ramba
Poděkování
Chtěl bych touto cestou poděkovat RNDr. Heleně Palovské, Ph.D. za odborné vedení a rady poskytnuté při z pracování mé bakalářské práce. Dále bych chtěl poděkovat rodině a přátelům za jejich podporu.
Abstrakt
Bakalářská práce se věnuje návrhu a vývoji aplikace na zpracování daňových formulářů pro SAP SuccessFactors. Konkrétně se jedná o formulář prohlášení daně z příjmu fyzických osob ze závislé činnosti a žádost o roční zúčtování záloh a daňového zvýhodnění.
Cílem této práce je vytvořit SAPUI5 aplikaci pro SAP SuccessFactors, která se bude používat pro zpracování daňových formulářů. Pro dosažení cíle bylo potřeba provést analýzu technologií SAP, provést analýzu formulářů a ze získaných informací navrhnout řešení, podle kterého se aplikace realizovala. Návrh řešení obsahoval funkcionality, kterými musí aplikace disponovat a návrh databáze, jež bude sloužit pro uchování dat z formulářů.
Výsledkem této práce je aplikace pro zpracování daňových formulářů, jenž ulehčuje práci zaměstnancům a mzdovým účetním se zpracováním formulářů. Aplikace je součástí HR nástroje SAP SuccessFactors, tím je zajištěno uchování informací zaměstnance na jednom místě a zjednodušený přístup k aplikaci.
Klíčová slova
SAPUI5, webová aplikace, SAP SuccessFactors, JavaScript
Abstract
This bachelor’s thesis concern with the design and development of an application for processing tax forms for SAP SuccessFactors. Specifically, it is a form of Declaration of the taxpayer liable to personal income tax from dependent activity and Request for annual account of prepayments and tax benefits.
The aim of the thesis is to create an SAPUI5 application for SAP SuccessFactors, which will be used for processing tax forms. To achieve the goal, it was necessary to perform an analysis of SAP technologies, perform an analysis of forms and from obtained information to design a solution, according to which the application was developed and implemented. The design of the solution included the functionalities that the application must have and the design of a database that will be used to store data from forms.
The result of this thesis is an application for processing tax forms, which facilitates the work of employees and payroll accountants with the processing of forms. The application is part of the HR tool SAP SuccessFactors, which ensures the storage of employee information in one place and simplified access to the application.
Keywords
SAPUI5, web application, SAP SuccessFactors, JavaScript
Obsah
Úvod... 9
1 Rešerše ... 10
2 Použité technologie ... 11
2.1 SAP Fiori ... 11
2.2 SAPUI5 ...12
2.3 JavaScript...13
2.4 Model View Controller ...13
2.5 SAP SuccessFactors ... 14
2.6 SAP Business Technology Platform ... 15
2.7 SAP SF Metadata Framework ... 15
2.8 oData version 2.0 ... 16
3 Analýza a návrh řešení ... 17
3.1 Zadání aplikace ... 17
3.2 Formuláře ... 17
3.2.1 Prohlášení a dodatečné prohlášení ... 17
3.2.2 Žádost ... 22
3.3 Legislativní nařízení ... 26
3.4 Analýza systému SAP SuccessFactors... 26
3.5 Prerekvizity pro aplikaci ... 27
3.6 Případy užití a role ... 27
3.7 Návrh uživatelského rozhraní ... 30
3.8 Databáze ... 30
3.8.1 Schéma databáze ... 30
3.8.2 Picklisty ... 35
4 Vývoj aplikace a implementace ... 40
4.1 Časový plán ... 40
4.2 Vývojový prostředí ... 40
4.3 Struktura souborů aplikace... 41
4.4 Tvorba MDF objektů ... 42
4.5 Vývoj aplikace ... 43
4.6 Implementace na testovací prostředí ... 48
5 Aplikace ... 49
5.1 Uživatelské rozhraní ... 49
5.1.1 Hlavní obrazovka z pohledu zaměstnance ... 49
5.1.2 Hlavní obrazovka z pohledu mzdové účetní ... 50
5.1.3 Prohlášení a dodatečné prohlášení ... 51
5.1.4 Žádost ... 52
5.1.5 Kontrola mzdovou účetní ... 54
Závěr ... 55
Použitá literatura ... 56 Přílohy ... I Příloha A: Formulář prohlášení poplatníka daně z příjmů fyzických osob ze závislé činnosti... I Příloha B: Formulář žádost o roční zúčtování záloh a daňového zvýhodnění ... I Příloha C: Schéma databáze ... I Příloha D: Případy užití ... I
Seznam obrázků
Obrázek 1: Schéma MVC ... 14
Obrázek 2: Možnosti využití SAP BTP ... 15
Obrázek 3: 1. část formuláře prohlášení - osobní údaje ... 18
Obrázek 4: 2. část formuláře prohlášení - slevy na dani ... 19
Obrázek 5: 3. část formuláře prohlášení - uplatnění slevy na děti ... 20
Obrázek 6: 4. část formuláře prohlášení - jiná osoba uplatňující slevu na děti ... 20
Obrázek 7: 5. část formuláře prohlášení - podpisová část...21
Obrázek 8: 6. část formuláře prohlášení - změnová část ...21
Obrázek 9: 1. část formuláře žádost - osobní údaje ... 22
Obrázek 10: 2. část formuláře žádost - předchozí plátci daně ... 22
Obrázek 11: 3. část formuláře žádost - sleva na manželku ... 23
Obrázek 12: 4. část formuláře žádost - sleva za umístění dítěte v předškolním zařízení .... 23
Obrázek 13: 5. část formuláře žádost - nezdanitelné části základu daně ... 24
Obrázek 14: 6. část formuláře žádost – adresa nemovitosti a jiná osoba uplatňují úroky .. 25
Obrázek 15: 7. část formuláře žádost - podpisová část ... 25
Obrázek 16: 8. část formuláře - další záznamy ... 26
Obrázek 17: Diagram případů užití, vlastní zpracování (zdroj: autor)... 28
Obrázek 18: Schéma databáze s MDF objekty sloužící pro ukládání dat pro formulář žádost ...31
Obrázek 19: Schéma databáze s MDF objekty sloužící pro ukládání dat pro formulář prohlášení ... 32
Obrázek 20: Schéma databáze s MDF objekty sloužící pro ukládání dat pro formulář dodatečné prohlášení ... 33
Obrázek 21: Schéma databáze s MDF objekty sloužící pro ukládání příloh ... 35
Obrázek 22: Struktura souborů aplikace ... 41
Obrázek 23: Definice základních parametrů MDF objektu... 42
Obrázek 24: Definování fieldů a asociací MDF objektu ... 43
Obrázek 25: UI flow hlavních obrazovek ... 49
Obrázek 26: Hlavní obrazovka na záložce prohlášení z pohledu zaměstnance ... 50
Obrázek 27: Hlavní obrazovka na záložce prohlášení z pohledu mzdové účetní ... 51
Obrázek 28:Obrazovka prohlášení - slouží k vyplnění formuláře prohlášení a dodatečné prohlášení ... 52
Obrázek 29: Obrazovka žádost – slouží k vyplnění formuláře žádost ... 53
Obrázek 30: Obrazovka kontrola mzdovou účetní - seznam uplatňovaných slev ... 54
Obrázek 31: Obrazovka kontrolou mzdovou účetní - detail nezdanitelné části ... 54
Úvod
Bakalářská práce se věnuje návrhu a vývoji demo verze aplikace na zpracování daňových formulářů, prohlášení daně z příjmu fyzických osob ze závislé činnosti a žádost o roční zúčtování záloh a daňového zvýhodnění. Této práci dala vzniknout potřeba vytvořit rozšiřující aplikaci pro SAP SuccessFactors, která poskytne firmám digitální zpracování zmíněných formulářů a zároveň uložiště formulářů s jejich přílohami.
Cílem této bakalářské práce je vyvinout demo verzi cloudové aplikace pro SAP SuccessFactors, která se bude používat pro zpracování a digitalizaci daňových formulářů a příloh. Pro dosažení tohoto cíle je potřeba provést analýzu formuláře prohlášení daně z příjmu fyzických osob ze závislé činnosti a žádost o roční zúčtování záloh a daňového zvýhodnění, která nám poskytne informace, které je potřeba získat od zaměstnance k vyplnění formulářů. Dále bude provedena analýza datového modelu SAP SuccessFactors, abychom zjistili, které údaje o zaměstnanci zde jsou uchovány a které budou moct být použity v aplikaci. Dalším cílem bude stanovit funkcionality aplikace, navrhnout datový model pro aplikaci, popsat procesy, popsat postup vývoje a představení výsledné aplikace.
Cíl práce bude považován za splněný, pokud vyvinutá demo verze aplikace zdigitalizuje proces zpracování formulářů a zpracování formulářů bude efektivnější než současná řešení.
V současné době se formuláře zpracovávají několik způsoby, nejrozšířenější způsob je, kdy zaměstnanec nebo účetní oddělení ve firmě formulář vytiskne a poté vyplní papír ručně.
Finanční správa české republiky poskytuje formuláře i ve formě interaktivního pdf, tak není potřeba formuláře tisknout a lze to vyplnit na počítači. Nejméně rozšíření způsob zpracování formulářů je využití webových nebo desktop aplikací. Některé firmy mají vlastní řešení na míru, jiné firmy používají aplikace třetích stran nebo mají řešení již v rámci podnikového informačního systému.
Metodika dosažení cílů
Nejdříve byly získány informace o formulářích, kterými se bude aplikace zabývat, informace o SAP SuccessFactors a jaké technologie bude potřeba použít. Na základě těchto informací byl sestaven návrh aplikace, který obsahoval role uživatelů, funkcionality aplikace a návrh databáze pro uchování potřebných informací.
Dalším krokem bylo vytvoření databáze na vývojovém prostředí a vývoj aplikace. Během vývoje probíhalo průběžné testování aplikace. Po dokončení vývoje se aplikace nasadila na testovací prostředí SAP SuccessFactors, kde proběhlo ještě jedno testovaní s reálnými daty zaměstnanců a následná optimalizace aplikace.
1 Rešerše
Před vývojem aplikace byla provedena rešerše několika informačních zdrojů. Podstatné zdroje jsou v této kapitole představeny. Konkrétní zdroje jsou uvedeny v jednotlivých kapitolách této práce.
Oficiální stránky dokumentací společnosti SAP (SAP Help Portal), které poskytují informace o všech jejich produktech.
Webové stránky technologie SAPUI5 poskytují popis základních funkcí této technologie, dokumentaci jednotlivých komponent SAPUI5 a ukázky kódů.
Sbírka zákonů České republiky, kde jsou poskytnuty všechny předpisy Sbírky zákonů v aktuálním znění.
Články na komunitním webu SAP se věnují všem technologiím a produktům společnosti SAP z pohledu vývojářů, konzultantů, zákazníků a ostatních, kteří přichází do styku se SAP technologiemi.
2 Použité technologie
Tato část bakalářské práce se budě věnovat technologiím, které jsou použity pro tvorbu této aplikace. Jsou zde zahrnuty designové a vývojové technologie. Zároveň je zde zahrnuta platforma SAP Bussiness Technology Platform a HR nástroj SAP SuccessFactors.
2.1 SAP Fiori
SAP Fiori je designový jazyk a přístup k uživatelské zkušenosti, který vyvinula společnost SAP pro použití samotného SAP, jeho zákazníků a partnerů. SAP poskytuje UI knihovny SAPUI5 JavaScript, které jsou v souladu s Fiori. Pokyny pro design Fiori poskytnout vodítko k tomu, jak implementovat UI které vyhovuje požadavkům designérského jazyka Fiori.
Cílem Fiori Design pokynů je vést designéry a vývojáře při tvorbě aplikací, které jsou pro uživatele rozpoznatelné jako aplikace Fiori a které se chovají konzistentně a předvídatelným způsobem. Pokyny definují sdílené služby, jako je vyhledávání, Fiori Launchpad a zobrazení zpráv, které se objevují v určitých aplikacích. Rovněž definují funkce, které jsou společné pro všechny aplikace, například vzhled a chování běžných ovládacích prvků, jako jsou tlačítka, datové vstupy a tabulky. Pro dosažení konzistentního vzhledu Fiori aplikací je poskytována i knihovna ikon. V pokynech pro design SAP Fiori jsou definovány koncepty designu a personalizace na základě rolí. To znamená, že ve výchozím nastavení by měla být rozhraní Fiori navržena tak, aby poskytovala uživatelům funkce, které potřebují k výkonu své role ve společnosti. Záměrem je povzbudit designéry a vývojáře, aby pečlivě zvážili role svých uživatelů a odstranili z jejich návrhů nadbytečné aplikace a aplikační prvky. [3]
2.2 SAPUI5
„Sada nástrojů pro vývoj uživatelského rozhraní pro HTML5 je technologie uživatelského rozhraní, která se používá k vytváření a přizpůsobování klientských aplikací. SAPUI5 je klientská knihovna pro vykreslování HTML5 s bohatou sadou standardních a rozšiřujících ovládacích prvků a odlehčeným programovacím modelem. Vykreslující knihovna poskytuje bohatou sadu ovládacích prvků na straně klienta. Tyto ovládací prvky můžete rozšířit a vyvinout nové vlastní ovládací prvky.“1 [2] (překlad autora) SAPUI5 se používá pro tvorbu SAP Fiori aplikací. SAP disponuje dokumentací, kde jsou všechny komponenty podrobně popsané a k některým komponentám mají vytvořené i praktické ukázky.
Výpis 1: Ukázka zápisu SAPUI5 komponenty Button (Tlačítko)
1 Původní znění: „The UI development toolkit for HTML5 is a user interface technology that is used to build and adapt client applications. The SAPUI5 runtime is a client-side HTML5 rendering library with a rich set of standard and extension controls and a lightweight programming model.
The client-side rendering library provides a rich set of controls. You can extend these controls as well as develop new custom controls.“
<Button
enabled="true"
icon="sap-icon://action-settings"
iconDensityAware="true"
iconFirst="true"
text="Nastavení"
textDirection="Inherit"
type="Default"
width=""
busy="false"
busyIndicatorDelay="1000"
busyIndicatorSize="Medium"
visible="true">
</Button>
2.3 JavaScript
JavaScript, také známo jako pouze JS je skriptovací jazyk operující na straně uživatele v prohlížeči. Tato technologie se stará o pokročilejší procesy jako je například práce se vstupy uživatele nebo vytváření a zobrazení výstupy pro uživatele. [4] V dnešní době se čístý JavaScript používá už zřídka, velmi často se používají rozšiřující knihovny nebo frameworky (např. framework Node.js nebo knihovna jQuery).
Výpis 2: Ukázka JavaScript kódu
2.4 Model View Controller
Model View Controller, běžně známo pod zkratkou MVC, je design aplikace tvořený třemi propojenými komponentami. Model (databáze), view (uživatelské rozhraní) a controller (procesor, který má na starosti zpracování vstupů). Tato architektura je používaná pro vývoj desktopových, mobilních i webových aplikací. Velmi dobře se používá s objektově orientovaným programováním, neboť se jednotlivé komponenty můžou chovat jako objekty a pak je lze použít vícekrát. Model reprezentuje data, které se používají v aplikaci. Může se jednat o databázi, soubor nebo objekt. Komponenta view je jediná komponenta, kterou vidí uživatel, má na starosti zobrazování výstupů. [1] Pro tvorbu se nejčastěji používají šablony s tagy značkovacího jazyka. Controller propojuje celou aplikaci dohromady a zajišťuje komunikaci mezi zbývajícími dvěma komponentami. Přijímá vstupy z view, které následně zpracuje a přepošle do komponenty model. Dále má na starosti aktualizaci view na základě přijatých dat z modelu.
function multiply(a, b) { return a * b;
}
var multiplied = multiply(10, 4);
Obrázek 1: Schéma MVC (zdroj: autor)
2.5 SAP SuccessFactors
SAP SuccessFactors (dále jen SAP SF) je HR nástroj poskytující cloudové softwarové řešení pro řízení lidských zdrojů (Human Capital Management) s využitím software-as-a-service modelu [5] („Software-as-a-Service (SaaS) je model poskytování softwaru, kdy poskytovatel cloudu vyvíjí a udržuje cloudový aplikační software, poskytuje automatické aktualizace softwaru a zpřístupňuje software svým zákazníkům prostřednictvím internetu na platformě bázi průběžných úhrad. Poskytovatel cloudu spravuje veškerý hardware, middleware, aplikační software a zabezpečení.“ [6]).
Seznam klíčových funkcí, které jsou zahrnuty v cloudovém řešení SAP SuccessFactors poskytovaném uživatelům:
• nábor nových zaměstnanců,
• správa pracovních pozic,
• HR transakce (administrativní práce na denní bázi),
• mzdové listy,
• správa dovolených,
• reporty a audity,
• učení a rozvoj,
• integrace a rozšiřitelnost.
SAP SF může být rozšířen integrovanými moduly. Jedním takovým modulem je SAP SF Employee Central, který poskytuje správu struktury organizace, personální správu a správu mezd. Každý zaměstnanec v tomto modulu vidí přehledně veškeré osobní údaje, mzdy a svoje nadřízené a podřízené. Hlavní výhodou tohoto modulu je samoobsluha ze strany zaměstnance, veškeré osobní údaje si může upravovat sám. [7]
2.6 SAP Business Technology Platform
SAP Business Technology Platform (SAP BTP) je cloudová platforma, která poskytuje rychlé zpracování v paměti, agilní řešení a služby pro integraci dat a rozšiřování aplikací. Zahrnuje správu databází a dat, analytiku, vývoj a integraci aplikací i inteligentních technologií. [8]
Obrázek 2: Možnosti využití SAP BTP (zdroj: [9])
SAP BTP nabízí několik různých prostředí pro vývoj a správu v různých regionech. Neo prostředí je jedním z těchto prostředí, který umožňuje nasazení HTML5, Java a SAP HANA rozšiřujících aplikací. Každý region je reprezentovaný geografickou pozicí (Evropa, Asie), regiony nabízí samotný SAP, nebo partneři jako je Amazon Web Services, Microsoft Azure, Google Cloud Platform a Alibaba Cloud.
Centrálním bodem vstupu na cloudovou platformu je SAP BTP Cockpit, kde můžete přistupovat ke svým účtům, aplikacím a spravovat všechny aktivity s nimi spojené.
2.7 SAP SF Metadata Framework
SAP SF Metadata Framework (dále jen MDF) je platforma používající pro tvorbu nových aplikací nebo rozšíření stávajících aplikací v rámci systému SAP SF. Pomocí MDF může být snadno rozšířen modul Employee Central podle potřeb zákazníka. MDF umožňuje vytvářet a spravovat objektově relační nebo objektově hiearchické databáze. Pro zefektivnění práce můžou být MDF objekty propojeny s workflow, rules engine a reportingem. [10] Limitem této platformy je vytvoření maximálně 250 vlastních MDF objektů, základní objekty systému a modulů se do toho nepočítají. [11]
2.8 oData version 2.0
„Open Data Protocol (OData) umožňuje vytváření datových služeb založených na HTTP, které umožňují publikování a úpravy prostředků identifikovaných pomocí identifikátorů Uniform Resource Identifier (URI) a definovaných v abstraktním datovém modelu pomocí jednoduchých zpráv HTTP. OData je určena k použití k vystavení a přístupu k informacím z různých zdrojů, mimo jiné včetně relačních databází, souborových systémů, systémů pro správu obsahu a tradičních webových stránek.“2 [12] (překlad autora) Pro získávání specifických dat můžou být využity rozšiřující možnosti dotazu (např. filter, select a expand). Pro příklad přidávám ukázku dotazu (dotaz je poslán na testovací službu), který získává Name, Rating a Price všech produktů, které mají Rating rovno 3. Data budou vrácena ve formátu JSON (viz. Výpis 3).
Výpis 3: Ukázka oData dotazu
2 Původní znění: „The Open Data Protocol (OData) enables the creation of HTTP-based data services, which allow resources identified using Uniform Resource Identifiers (URIs) and defined in an abstract data model, to be published and edited by Web clients using simple HTTP messages.
OData is intended to be used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems, and traditional Web sites.“
https://services.odata.org/OData/OData.svc/Products?$filter=Rating eq 3
&$select=Name,Price,Rating&$format=json
3 Analýza a návrh řešení
3.1 Zadání aplikace
Zadání bylo vytvořit webovou aplikaci pro platformu SAP SF se zaměřením na digitální správu daňových formulářů zaměstnanců. Aplikace by měla tedy sloužit pro zaměstnance, kteří by si samoobsluhou digitálně vypracovali formuláře prohlášení daně z příjmu fyzických osob ze závislé činnosti za současný rok (dále jen prohlášení), prohlášení daně z příjmu fyzických osob ze závislé činnosti za předchozí rok (dále jen dodatečné prohlášení) a žádost o roční zúčtování záloh a daňového zvýhodnění (dále jen žádost). Po vypracování zaměstnancem by se formulář odeslal mzdové účetní na kontrolu, kde bude mít všechno přehledně zobrazené, tak aby to mzdovým účetním ušetřilo co nejvíce času a nadbytečné práce. Pro zaměstnance bude výstupem vygenerované PDF s vyplněnými informacemi z aplikace a pro mzdovou účetní digitalizované formuláře se všemi přiloženými přílohami od zaměstnance. V aplikaci musí být zajištěny všechny aspekty formulářů, ať už se jedná o vyplnění informací, přikládání souborů tak i legislativní podmínky.
3.2 Formuláře
V této části si představíme formuláře, které se budou v aplikaci zpracovávat. Jak už bylo zmíněno výše (viz. Zadání aplikace) jedná se o prohlášení daně z příjmu fyzických osob ze závislé činnosti za současný rok (dále jen prohlášení), prohlášení daně z příjmu fyzických osob ze závislé činnosti za předchozí rok (dále jen dodatečné prohlášení) a žádost o roční zúčtování záloh a daňového zvýhodnění (dále jen žádost).
3.2.1Prohlášení a dodatečné prohlášení
Prohlášení může zaměstnanec vyplnit dvěma způsoby. První způsob je, kdy poplatník daně vyplní formulář v měsíci, kdy nastoupil do zaměstnání, tím pádem veškeré uplatněné slevy se projeví každý měsíc na mzdě zaměstnance od měsíce nástupu. Druhý způsob je, když poplatník daně vyplní formulář v měsíci leden nebo únor za předchozí rok. Tím pádem se jedná o dodatečné prohlášení a uplatněné slevy se zpětně vyplatí. Formulář prohlášení/dodatečné prohlášení je k nalezení v příloze (Příloha A:). Pro přehledný popis byl formulář rozdělen na 6 částí, které jsou dále popsány.
V první části poplatník daně vyplňuje, za jaké zdaňovací období vyplňuje prohlášení a zda- li prohlášení vyplňuje dodatečně nebo ne. Dále zde vyplňuje plátce daně a svoje osobní údaje. U plátce daně je vyžadovaný název a adresa. Z osobních údajů je požadovaný jméno, příjmení, rodné číslo a adresa trvalého pobytu. Pokud se jedná o daňového nerezidenta ČR je potřeba ještě vyplnit datum narození, číslo dokladu a typ dokladu, který prokazuje jeho totožnost. Dále je potřeba vyplnit identifikaci pro daňové účely ve státu daňové rezidence, stát, kde je daňový rezident a přiložit doklad prokazující totožnost poplatníka3 (viz. Obrázek 3).
Obrázek 3: 1. část formuláře prohlášení - osobní údaje (zdroj: autor)
Ve druhé části poplatník daně uplatňuje slevy na dani (viz. Obrázek 4), které snižují výpočet daně. Všechny uvedené slevy lze uplatnit pouze u jednoho zaměstnavatele za kalendářní měsíc. Nachází se zde celkem 5 slev, které může poplatník daně uplatnit (uvedené částky jsou platné pro zdaňovací období 2021).:
1. Základní sleva na poplatníka, jedná se celkem o daňovou slevu 27 840 Kč za rok. Pokud poplatník daně nastoupil do zaměstnání během měsíce, je potřeba přiložit potvrzení nebo čestné prohlášení, že si pro ten měsíc neuplatňoval slevu u jiného plátce daně. [13]
2. Základní sleva na invaliditu se vztahuje na osoby pobírající invalidní důchod I.
nebo II. stupně. Daňová sleva činí 210 Kč za měsíc a je potřeba přiložit potvrzení o přiznání invalidního důchodu I. nebo II. stupně. [13]
3 Demo verze aplikace nebude zpracovávat formuláře poplatníků, kteří jsou daňový nerezidenti ČR.
3. Rozšířená sleva na invaliditu se vztahuje na osoby pobírající invalidní důchod III. stupně. Daňová sleva činí 420 Kč za měsíc a je potřeba přiložit potvrzení o přiznání invalidního důchodu III. stupně. [13]
4. Sleva pro držitele průkazu ZTP/P se vztahuje na držitele průkazu ZTP/P (zvlášť těžké postižení s průvodcem). Při uplatnění této slevy má zaměstnanec nárok na slevu na dani ve výši 16 140Kč za rok, je však nutné doložit průkaz ZTP/P. [13]
5. Sleva na studenta se vztahuje na osoby, které se připravují na budoucí povolání studiem nebo předepsaným výcvikem, a to nejdéle do věku 26 let. Výjimku mají studenti doktorského studijního programu v prezenční formě, ti mohou uplatnit slevu až do 28 let věku. Roční sleva na studenta činí 4 020 Kč a je potřeba doložit potvrzení o studiu. [13]
Pokud zaměstnanec vyplňuje prohlášení dodatečně, je potřeba uvést měsíce, za které si danou slevu zpětně uplatňuje.
Obrázek 4: 2. část formuláře prohlášení - slevy na dani (zdroj: autor)
Třetí část formuláře je věnována daňovému zvýhodnění na vyživované děti žijící ve stejné hospodařící domácnosti (viz. Obrázek 5). Poplatník daně zde vyplní všechny děti žijící ve společné domácnosti. Poplatník daně má celkem 4 možnost, v jaké výši může uplatnit daňové zvýhodnění na dítě (uvedené částky jsou platné pro zdaňovací období 2021).:
1. Uplatňuji nárok ve výši 1 je sleva ve výši 15 204 Kč za rok a lze uplatnit pouze na 1. dítě.
2. Uplatňuji nárok ve výši 2 je sleva ve výši 19 404 Kč za rok a lze uplatnit pouze na 2. dítě.
3. Uplatňuji nárok ve výši 3 je sleva ve výši 24 204 Kč za rok a lze uplatnit pouze na 3. dítě a každé další.
4. Neuplatňuji nárok značí, že poplatník daně na dané dítě neuplatňuje daňové zvýhodnění.
Pokud se jedná o dítě s držením průkazu ZTP/P sleva na dani je dvojnásobná. Ke každému dítěti je potřebné přiložit rodný list a pokud se jedná o dítě s průkazem ZTP/P, je potřeba doložit daný průkaz. Dále se může jednat o zletilé dítě, v tom případě je potřeba doložit potvrzení o studiu. Pokud zaměstnanec vyplňuje prohlášení dodatečně v posledním sloupci tabulky se udávají měsíce, za které se sleva dodatečně uplatňuje. [14]
Obrázek 5: 3. část formuláře prohlášení - uplatnění slevy na děti (zdroj: autor)
Ve čtvrté části se vyplňuje jiná osoba, která vyživuje tytéž děti v téže domácnosti. U této osoby je potřeba vyplnit jméno, příjmení, rodné číslo a adresu trvalé bydliště. Pokud je daná osoba zaměstnaná, tak je ještě potřeba vyplnit název a adresu plátce daně (viz. Obrázek 6).
Obrázek 6: 4. část formuláře prohlášení - jiná osoba uplatňující slevu na děti (zdroj: autor) V páté části poplatník daně a plátce daně podepisují formulář. Podpis je rozdělen podle toho, jestli se jedná o prohlášení vyplněné za současné zdaňovací období, nebo dodatečně za uvedené zdaňovací období (viz. Obrázek 7).
Obrázek 7: 5. část formuláře prohlášení - podpisová část (zdroj: autor)
Šestá část se věnuje změnám v prohlášení, které mohou nastat během roku (viz. Obrázek 8). U každé změny musí být uveden druh změny, měsíc od kdy je změna platná, datum oznámení a následně podpis plátce daně s datem. Druhem změny může být jakákoliv sleva uvedena v druhé části formuláře. V druhé tabulce se vyplňují změny u dětí. Pokud se provádí změna u dětí, je po potřeba vyplnit všechny děti žijící ve společné domácnosti.
Obrázek 8: 6. část formuláře prohlášení - změnová část (zdroj: autor)
3.2.2Žádost
Žádost se vyplňuje jednou ročně, a to vždy na začátku roku do 15.2. Kdo může podat o roční zúčtování daně? Je to poplatník daně pracující současně jenom pro jednoho zaměstnavatele. Poplatník nesmí mít povinnost podat daňové přiznání a musí mít u zaměstnavatele podepsané prohlášení. „Pokud vám při zúčtování vznikl nárok na daňovou vratku, nebo dokonce na výplatu daňového bonusu, tak je zaměstnavatel povinen tyto peníze vyplatit nejpozději v březnové mzdě“ [15]. Formulář žádost je k nalezení v příloze (Příloha B:). Pro přehledný popis byl formulář rozdělen na 8 částí, které jsou dále popsány.
V první části poplatník daně vyplňuje, za jaké zdaňovací období vyplňuje žádost, identifikaci poplatníka a plátce daně (viz. Obrázek 9). U identifikace poplatníka se jedná o jméno, příjmení a rodné číslo případně datum narození. U identifikace plátce daně je potřeba uvést název plátce a adresu sídla.
Obrázek 9: 1. část formuláře žádost - osobní údaje (zdroj: autor)
Druhá část je věnována vyplnění předchozích plátců daně, u kterých byl poplatník daně zapsán (viz. Obrázek 10). Může se jednat o zaměstnavatele, ale i o úřad práce. Poplatník daně vyplňuje období, kdy byl u plátce daně evidován a jeho identifikaci, název a adresu sídla. Ke každému plátci daně je poplatník daně povinen doložit přílohu potvrzení o zdanitelných příjmech ze závislé činnosti nebo potvrzení z úřadu práce.
Obrázek 10: 2. část formuláře žádost - předchozí plátci daně (zdroj: autor)
Část 3 a 4 se věnuje slevám na dani, jedná se o slevu na manžela/ku a sleva za umístění dítěte v předškolním zařízení. Slevu na manžela/ku může poplatník daně uplatnil pouze tehdy, pokud jeho/její příjmy nepřekročily za celý kalendářní rok 68 000 Kč. Daňová sleva na manžela/ku činí 24 840 Kč za rok, dvojnásobná, pokud je držitelem průkazu ZTP/P (částky jsou platné pro zdaňovací období 2020). [13] Při uplatnění této slevy je potřebné doložit oddací list a potvrzení o příjmech manžela/ky.
Obrázek 11: 3. část formuláře žádost - sleva na manželku (zdroj: autor)
Slevu za umístění dítěte v předškolním zařízení (viz. Obrázek 12) si může uplatnit jeden z rodičů, a to pouze u dítěte, které žilo ve stejné hospodařící domácnosti v uvedeném zdaňovacím období. Výše slevy za umístění dítěte v předškolním zařízení činí maximálně až do výše minimální mzdy (za zdaňovací období 2020 to činí až 14600 Kč) [16] a je potřeba doložit potvrzení o zaplacení předškolního zařízení.
Obrázek 12: 4. část formuláře žádost - sleva za umístění dítěte v předškolním zařízení (zdroj: autor)
Části 5 je věnována nezdanitelným částem základu daně (viz. Obrázek 13), jedná se celkem o 6 části, které snižují daňový základ (uvedené částky jsou platné pro zdaňovací období 2020).: [17]
1. Bezúplatná plnění – dary. Jedná se o dary obcím, veřejným sbírkám, školství apod., částka jednoho daru musí činit alespoň 1 000 Kč. Dále si zde může poplatník uplatnit snížení základu daně na základě darování krve nebo plazmy. O všech darech musí být doloženo potvrzení.
2. Úroky z úvěru na financování bytových potřeb. Pokud poplatník využívá hypoteční úvěr, v této části vyplňuje částku, kterou vynaloží jako úrok za celý rok.
Maximální odečitatelná částka je 300 000 Kč a je potřeba doložit potvrzení o zaplacených úrocích a kopii úvěrové smlouvy.
3. Penzijní připojištění nebo penzijní pojištění nebo doplňkové penzijní spoření. Ze součtu všech uzavřených penzijních pojištění lze odečíst maximální částku 24 000Kč. Musí být doloženo potvrzení o zaplacení a smlouva penzijního pojištění.
4. Pojistné na soukromé životní pojištění. Odečtení částky v maximální výši 24 000 Kč od základu daně na základě doložení potvrzení o zaplacení a smlouvy soukromého životního pojištění.
5. Členské příspěvky člena odborové organizace. „Od základu daně lze odečíst zaplacené členské příspěvky zaplacené ve zdaňovacím období členem odborové organizace odborové organizaci“ [17]. Takto lze odečíst částku maximálně vy výši 3 000 Kč, avšak musí být doloženo potvrzení o zaplacení členského příspěvku.
6. Úhrada za zkoušky ověřující výsledky dalšího vzdělání. Poplatník může uplatnit snížení základu daně, pokud vynaloží během roku výdaje na vzdělání.
Maximální odečitatelná částka je 10 000 Kč, u poplatníka se zdravotním postižení 13 000Kč a 15 000Kč u poplatníka s těžkým zdravotním postižení. Musí být doloženo potvrzení o úhradě vzdělání.
Obrázek 13: 5. část formuláře žádost - nezdanitelné části základu daně (zdroj: autor)
K nezdanitelné části Úroky z úvěru na financování bytových potřeb se váže i 6. část formuláře (viz. Obrázek 14), kde poplatník vyplňuje osoby, které také uplatňuji odpočet úroku ze stejného hypotečního úvěru a adresu bytové potřeby, na kterou se vztahuje hypoteční úvěr. K bytové potřebě je potřeba doložit výpis z katastru.
Obrázek 14: 6. část formuláře žádost – adresa nemovitosti a jiná osoba uplatňují úroky (zdroj:
autor)
Předposlední část obsahuje podpis poplatníka a ověření plátce daně s datumy, kdy k podpisu došlo. Dále zde poplatník žádá o dodatečné uplatnění slev na dani, neboli o dodatečné prohlášení (viz. Obrázek 15).
Obrázek 15: 7. část formuláře žádost - podpisová část (zdroj: autor)
Poslední část obsahuje seznam všech přiložených příloh k formuláři, nebo pokud ve formuláři nestačily kolonky pro vyplnění všech potřebných informací, tak se vyplní zde (viz.
Obrázek 16).
Obrázek 16: 8. část formuláře - další záznamy (zdroj: autor)
3.3 Legislativní nařízení
„V případě elektronické formy je však nezbytné, aby dokumenty byly opatřeny uznávaným elektronickým podpisem nebo aby plátce daně zaručil v rámci svého vnitřního systému jednoznačnou identifikaci poplatníků. K předání předmětných dokumentů elektronickou formou plátcům daně může poplatník také využít datové schránky, pokud s ní disponuje a na základě judikatury Nejvyššího správního soudu lze akceptovat předání předmětných dokumentů prostřednictvím e-mailové zprávy opatřené uznávaným elektronickým podpisem.“ [18] Veškerou identifikace obstarává SAP SF, tím pádem zaměstnanci můžou veškeré potřebné soubory nahrávat přímo do aplikace a zároveň v aplikaci bude moct provádět změny ve formulářích pouze zaměstnanec, kterému formulář patří, takže se nemůže nastat, aby ve formuláři byly vyplněné jiné informace, než vyplnil sám zaměstnanec.
3.4 Analýza systému SAP SuccessFactors
Před samotným návrhem řešení musela proběhnout analýza SAP SF. Analýza proběhla dvěma způsoby, první způsob bylo prozkoumání dokumentací a druhý způsob se věnoval praktickému průzkumu systému, kde se ověřovali poznatky, které byly získány prvním způsobem průzkumu. Při prozkoumávání dokumentací SAP SF byla pozornost zaměřena na datovou strukturu a pracovní vztahy v SAP SF, aby se zjistilo, které data o zaměstnancích můžeme použít do aplikace. Ze zjištěných poznatků z dokumentací vyplývalo, že základní
datová struktura SAP SF nebude dostačující a že neobsahuje pracovní vztahy, proto bylo potřeba prozkoumat rozšiřující moduly. [19]
Modul, který odpovídá potřebám aplikace je Employee Central, jedním z účelů modulu je rozšíření datové struktury pro uchování informací o zaměstnancích. Tím pádem dále probíhal průzkum dokumentací k modulu Employee Central, kde se zjistilo, že tento modul nám zajistí potřebné informace o zaměstnancích. Tento modul obsahuje i pracovní vztahy mezi zaměstnanci, kde lze každému zaměstnanci přiřadit mzdovou účetní. Z dokumentací modulu Employee Central byly zjištěny, které datové objekty budeme potřebovat. Pro získání informací o pracovním poměru bude využitý datový objekt Employment Information [20] a pro získání informací o dětech a partnerovi datový objekt Dependents.
[22] Osobní údaje o zaměstnanci se propisují z vícero datových objektů do jednoho datového objektu User. Dílčí datové objekty obsahují historizovaná data [21, 23, 24], datový objekt User obsahuje informace k současnému dni. Při praktickém průzkumu byly ověřeny struktury všech datových objektů, které byly získány z průzkumu dokumentací, jestli opravdu obsahují potřebné informace. Datové struktury odpovídaly dokumentacím, pouze názvy objektů byly rozdílné (např. datový objekt Employement Information je pojmenovaný EmpEmployment, kde předpona „Emp“ odpovídá názvu modulu Employee Central).
3.5 Prerekvizity pro aplikaci
SAP SF musí mít integrovaný modul Employee Central, z tohoto modulu si aplikace bude získávat údaje o zaměstnanci. Firma musí disponovat Neo prostředím na cloudové platformě SAP BTP, které je propojené se SAP SF. Toto propojení nelze vytvořit bez přístupu k provisioning (backendová služba SAP SF, kde probíhá konfigurace) a to mají pouze certifikovaní konzultanti.
3.6 Případy užití a role
Pro aplikaci bylo identifikováno 6 hlavních případů užití rozděleny mezi 2 role. Na diagramu případu užití je vidět grafické znázornění přiřazení případů užití k rolím (viz. Obrázek 17).
Aplikace nepočítá s případy užití jako je registrace nebo přihlášení zaměstnance do aplikace, neboť aplikace je integrována v SAP SF, kde se účty generují automaticky nově nastoupeným zaměstnancům a pro otevření aplikace je potřeba být přihlášen v tomto informačním systému. Mzdová účetní dědí veškeré případy užití zaměstnance. Pro ukázku je v tabulce (viz. Tabulka 1) zpracován případ užití vygenerování formuláře mzdovou účetní. Všechny případy užití jsou k nalezení v příloze (viz. Příloha D:).
Zaměstnanec
Role zaměstnanec má za úlohu v aplikaci vyplnit formuláře, které mu byly vygenerovány a zároveň zaměstnanec bude mít přehled všech formulářů, které v minulosti vyplnil. Pokud zaměstnanec bude potřebovat formulář v papírové podobě, má možnost si formulář stáhnout ve formátu PDF s vyplněnými informacemi z aplikace.
Mzdová účetní
Role mzdové účetní má za úlohu generovat formuláře zaměstnancům. Po vyplnění formuláře zaměstnancem má za úkol formulář zkontrolovat. Pokud je potřeba formulář změnit do jiného stavu, tak má tuto možnost pomocí změny stavu formuláře a pokud byl formulář špatně vygenerovaný, tak má možnost formuláře mazat.
Obrázek 17: Diagram případů užití, vlastní zpracování (zdroj: autor)
Tabulka 1: Scénář případu užití Vygenerovat formulář (zdroj: autor) Název případu užití Vygenerovat formulář
Identifikace případu
užití UC5
Identifikace obrazovek, které se vztahují k případu užití
Hlavní obrazovka z pohledu mzdové účetní
Cíl případu užití Umožňuje vygenerovat formulář pro zaměstnance Primární aktér(ři) Mzdová účetní
Pomocný aktér(ři) -
Vstupní podmínky Zaměstnanec, kterému se bude generovat formulář má učet v SF.
Výstupní podmínky Vygeneruje se zvolený formulář vybranému zaměstnanci.
Základní scénář
Krok Akce uživatele Akce systému
1 Klikne na tlačítko „nový
formulář“.
Otevře dialogové okno se vstupem pro výběr zaměstnance a výběrem formuláře.
2 Do vstupu pro zaměstnacce
napíše jméno, příjmení nebo uživatelské ID.
Vrátí seznam zaměstnanců, kteří odpovídají vstupu.
3 Vybere zaměstnance ze
seznamu, pro keterého chce formulář vygenerovat.
Zaměstnanec se vyplní do vstupu se všemi údaji (jméno, příjmeni, uživatelské ID).
4 Vybere typ formuláře
(prohlášení, dodatečné prohlášení nebo žádost).
Provede ověření, jestli takový formulář už pro daný rok neexistuje.
5 Pokud neexistuje, klikne na
tlačítko „vytvořit“.
Vygeneruje formulář a zavře se dialogové okno.
Alternativní scénář – formulář se nevygeneruje
Krok Akce uživatele Akce systému
1 Klikne na tlačítko „nový
formulář“.
Otevře dialogové okno se vstupem pro výběr zaměstnance a výběrem formuláře.
2 Do vstupu pro zaměstnacce
napíše jméno, příjmení nebo uživatelské ID.
Vrátí seznam zaměstnanců, kteří odpovídají vstupu.
Vybere zaměstnance ze seznamu, pro keterého chce formulář vygenerovat.
Zaměstnanec se vyplní do vstupu se všemi údaji (jméno, příjmeni, uživatelské ID).
3.7 Návrh uživatelského rozhraní
Při návrhu aplikace nebyl vytvořen návrh uživatelského rozhraní, což se během vývoje ukázalo jako chyba. Při vývoji se muselo UI několikrát předělávat, aby to odpovídalo SAP Fiori pravidlům a aby to bylo přehledné a jednoduché pro zaměstnance. SAP poskytuje SAPUI5 šablony pro UI/UX aplikace Adobe XD, Sketch a Axure RP. [25] V pozdější části vývoje byl vyzkoušen nástroj Adobe XD se staženou SAPUI5 šablonou a návrh uživatelské rozhraní byl velmi jednoduchý a jakékoliv změny na něm byly rychle providitelné. V Adobe XD se dalo i nasimulovat chování aplikace, takže by se dalo vyzkoušet, jestli by bylo UI/UX pro zaměstnance přehledné a jednoduché.
3.8 Databáze
Protože aplikace bude integrována do SAP SF, nebylo třeba provádět analýzu, jaký typ databáze bude zvolen. Pro vytvoření databáze pro aplikaci bude využitá platforma SAP SF MDF (viz. SAP SF Metadata Framework). Pro naše řešení byla zvolena objektově relační databáze a pro uchování všech potřebných dat aplikace bylo celkem vytvořeno 25 tabulek.
Veškeré vazby mezi MDF Objekty jsou typu „composite“, kromě vazeb na MDF objekty cust_etax_attachment, cust_etax_personAttachments a cust_etax_childAttachments, kde jsou vazby typu „valid when“ (více o typů vazeb viz. Tvorba MDF objektů). Celé schéma databáze je k nalezení v příloze (viz. Příloha C:).
3.8.1Schéma databáze
Všechny názvy MDF objektů začínají cust_etax, kde cust značí že se jedná o custom MDF objekt (vlastní rozšiřující objekt, který není součástí základní struktury SAP SF) a etax je označení projektu. Základní MDF objekt databáze je cust_etax_person, která slouží ke spojení všech dat k jednomu zaměstnanci. MDF objekt cust_etax_form slouží pro uchovávání informací o stavu formuláře, například status formuláře (viz. Tabulka 3), typ formuláře (viz.
Tabulka 4) a pro uchování osobních údajů zaměstnance. Tento MDF objekt je sdílený pro prohlášení, dodatečné prohlášení a žádost. Data týkající se daného typu formuláře jsou uchovány v „child“ objektech (cust_etax_declaration, cust_etax_additionalDeclaration a cust_etax_request).
Pro uchování informací formuláře žádost je celkem vytvořeno 7 MDF objektů, včetně objektu cust_etax_form (viz. Obrázek 18). MDF objekt cust_etax_request uchovává informace o nezdanitelných částech základu daně. Každá nezdanitelná část je tvořena čtyřmi fieldy, field datového typu boolean pro uchování, jestli zaměstnanec tuto nezdanitelnou část uplatňuje (např. cust_pensionInsurance), fieldy končící příponou „Status“ datové typu cust_etax_status (viz. Picklisty) pro zaznamenání stavu nezdanitelné části (např.
cust_pensionInsuranceStatus), field končící příponou „Comment“ pro zapsaní chyby, pokud
mzdová účetní vrací formulář na opravu zaměstnanci (např. cust_pensionInsuranceComment) a field končící příponou „Amount“ pro uchování uplatňující částky (např.
cust_pensionInsurnaceAmount). Dále obsahuje navigace na „child“ objekty, které uchovávají předchozí plátce daně (cust_etax_requestDependentActivity), slevu na manželku (cust_etax_requestSpouse), slevu na děti (cust_etax_requestChild) a adresu nemovitosti (cust_etax_requestRealEstate) k nezdanitelné části úroky z úvěru a pokud úroky uplatňují i jiné osoby, tak navigaci na jiné osoby uplatňující úrok (cust_etax_requestInterestsAnotherPerson).
Obrázek 18: Schéma databáze s MDF objekty sloužící pro ukládání dat pro formulář žádost (zdroj:
autor)
Pro uchování informací formuláře prohlášení je celkem vytvořeno 7 MDF objektů, včetně objektu cust_etax_form (viz. Obrázek 19). MDF objekt cust_etax_declaration uchovává informace o uplatňujících slev. Každá sleva je tvořena třemi fieldy, field datového typu boolean pro uchování, jestli zaměstnanec tuto slevu uplatňuje (např.
cust_personalTaxAllowance), fieldy končící příponou „Status“ datové typu cust_etax_status (viz. Picklisty) pro zaznamenání stavu slevy (např. cust_personalTaxAllowanceStatus) a field končící příponou „Comment“ pro zapsaní chyby, pokud mzdová účetní vrací formulář na opravu zaměstnanci (např. cust_personalTaxAllowanceComment). Objekt cust_etax_declaration má celkem 3 vazby na „child“ objekty, jedná se o objekty cust_etax_declarationChild, cust_etax_declarationChange a cust_etax_declarationAnotherPerson. Objekt cust_etax_declarationChild slouží pro uchování dětí žijící ve společné domácnosti. Do objektu cust_etax_declarationAnotherPerson se ukládají informace o jiné osobě, která společně vyživuje tytéž děti a do objektu cust_etax_declarationChange se ukládají změny, které nastaly během roku. Objekt cust_etax_declarationChange má na sebe navázaný ještě další 2 „child“ objekty, cust_etax_declarationChildChange pro uchovaní změn u dětí a cust_etax_declarationAnotherPersonChange pro uchování změn u jiné osoby, která vyživuje tytýž děti.
Obrázek 19: Schéma databáze s MDF objekty sloužící pro ukládání dat pro formulář prohlášení (zdroj: autor)
Pro uchování informací formuláře dodatečné prohlášení jsou celkem vytvořeny 4 MDF objekty, včetně objektu cust_etax_form (viz. Obrázek 20Obrázek 19). MDF objekt cust_etax_additionalDeclaration uchovává informace o uplatňujících slev. Každá sleva je tvořena čtyřmi fieldy, field datového typu boolean pro uchování, jestli zaměstnanec tuto slevu uplatňuje (např. cust_personalTaxAllowance), fieldy končící příponou „Status“ datové typu cust_etax_status (viz. Picklisty) pro zaznamenání stavu slevy (např.
cust_personalTaxAllowanceStatus), field končící příponou „Comment“ pro zapsaní chyby, pokud mzdová účetní vrací formulář na opravu zaměstnanci (např.
cust_personalTaxAllowanceComment) a field končící příponou „InMonths“ datového typu string, kde se ukládají měsíce, za které zaměstnanec zpětně uplatňuje slevu. Objekt cust_etax_additionalDeclaration má celkem 2 vazby na „child“ objekty, jedná se o objekty cust_etax_additionalDeclarationChild a cust_etax_additionalDeclarationChange, které uchovávají stejné informace jako objekty cust_etax_declarationChild a cust_etax_declarationAnotherPerson u prohlášení, akorát objekt cust_etax_additionalDeclarationChild je rozšířen o field cust_additionalyInMonths, kam se ukládají měsíce, za které se dodatečně uplatňuje sleva na dítě.
Obrázek 20: Schéma databáze s MDF objekty sloužící pro ukládání dat pro formulář dodatečné prohlášení (zdroj: autor)
Přílohy, které zaměstnanec přikládá k formulářům se neukládají do objektů cust_etax_request, cust_etax_declaration nebo cust_etax_additionalDeclaration, ale ukládají se do vlastních objektů, které jsou navázané na objekt cust_etax_person (viz. Obrázek 21), protože jsou typy souborů, které zaměstnanec nahraje jednou a víckrát už nemusí (např.
smlouva hypotečního úvěru), ale mzdová účetní je potřebuje vidět každý rok. Přílohy se ukládají do objektu cust_etax_attachment, kde se uchovává například název, velikost a samozřejmě obsah souboru.
Všechny přiložené přílohy k formuláři žádost se ukládají do objektu cust_etax_requestAttachments. Objekt cust_etax_requestAttachments má 6 fieldů s vazbou na objekt cust_etax_attachment, přičemž každý field odpovídá jedné nezdanitelné části ze žádosti a 3 vazby na „child“ objekty cust_etax_personAttachments, cust_etax_childAttachments a cust_etax_dependentActivityAttachments. Do objektu cust_etax_personAttachments se ukládají přílohy nahrané ke slevě na manželku, do objektu cust_etax_childAttachments přílohy nahrané ke slevě na děti, přičemž každé dítě má vlastní záznam v cust_etax_childAttachments a do objektu cust_etax_dependentActivityAttachments se ukládají přílohy nahrané k předchozímu plátci daně, přičemž stejně jak u dětí, zde má každý předchozí plátce daně vlastní záznam.
Přílohy přiložené k formuláři prohlášení a dodatečné prohlášení se ukládají do objektu cust_etax_declarationAttachments. Podobně jako u objektu cust_etax_requestAttachments nezdanitelné části, zde má každá sleva také vlastní field s vazbou na objekt cust_etax_attachments, kde se ukládají přílohy k dané slevě. Přílohy k dětem se ukládají do objektu cust_etax_childAttachments a přílohy k jiné osobě vyživující tytéž děti do objektu cust_etax_personAttachments. Pokud se nahrávají soubory ke změně v prohlášení, příloha se uloží podle typu změny (např. pokud se bude jednat o změnu „Uplatňuji slevu na studenta“, přílohy se uloží do fieldu cust_allowanceForTheStudentNav).
Výstupní PDF formuláře z aplikace se ukládají do objektu cust_etax_annualDocuments, přičemž každý formulář zde má vlastní field s vazbou na cust_etax_attachment, do kterého se výstupní PDF formulář uloží (např. výstupní pdf formulář žádosti se uloží do fieldu cust_requestDocuments).
Obrázek 21: Schéma databáze s MDF objekty sloužící pro ukládání příloh (zdroj: autor)
3.8.2Picklisty
„Picklist definuje sadu hodnot, které lze vybrat pro field.“4 [X1](překlad autora) Jedná se o typ číselníku, který se používá v MDF Object, výhodou je multijazyčnost, každá hodnota v picklistu může mít definované texty ve všech jazycích, ve kterých je nastavený SAP SF.
„Picklisty mohou mít vztah parent-child, takže hodnoty „child“ picklistu závisí na vybrané hodnotě v picklistu „parent“.“5 [26](překlad autora) V aplikaci je použitá pouze multijazyčnost jednotlivých hodnot v picklistu. Datové typy v databázi cust_etax_documentType, cust_etax_status, cust_etax_formType, cust_etax_declarationChangeTypes a cust_etax_childApplyAmount odpovídají picklistům.
4Původní znění: „A picklist defines the set of values that can be selected for a field.“
5 Původní znění: „Picklists can have a parent-child relationship, such that the values in a "child"
Picklist cust_etax_childApplyAmount obsahuje hodnoty, které se používají pro zvolení výše uplatnění slevy na dítě v prohlášení a dodatečném prohlášení (viz. Tabulka 2).
Tabulka 2: Hodnoty picklitu cust_etax_childApplyAmount (zdroj: autor)
ID hodnoty Název Popis
1 1 Uplatnění slevy na 1. dítě
2 2 Uplatnění slevy na 2. dítě
3 3 Uplatnění slevy na 3. dítě a každé další
N Neuplatňuji Neuplatnění slevy na dítě
Picklist cust_etax_status obsahuje hodnoty, které se používají pro označení stavu formuláře.
Určité hodnoty picklistu se používají i pro označení stavu jednotlivých slev, jedná se o stavy, kdy je sleva vrácena zaměstnanci na opravu nebo pokud je sleva schválena. Hodnoty picklistu jsou zobrazeny v tabulce níže (viz. Tabulka 3).
Tabulka 3: Hodnoty picklistu cust_etax_status (zdroj: autor)
ID hodnoty Název Popis
inProcess Ve zpracování zaměstnancem
Status formuláře, který se nachází ve stavu zpracování zaměstnancem
waiting Probíhá kontrola mzdovou účetní
Status formuláře, který se nachází ve stavu probíhá kontrola mzdovou účetní
done Zpracováno
Status formuláře, který se nachází ve stavu zpracováno, zároveň se použivá k jednotlivým slevám a částem formuláře, pokud byla schválena
returned Vráceno zaměstnanci k přepracování
Status formuláře, který se nachází ve stavu vráceno zaměstnanci k přepracování , zároveň se použivá k jednotlivým slevám a částem formuláře, pokud byla vrácena na opravu
Picklist cust_etax_formType slouží pro rozlišení typu formuláře (viz. Tabulka 4) a používá se pouze v objectu cust_etax_form.
Tabulka 4: Hodnoty picklistu cust_etax_formType (zdroj: autor)
ID hodnoty Název
declaration Prohlášení
additionalDeclaration Dodatečné prohlášení
request Žádost
Picklist cust_etax_declarationChangeTypes obsahuje všechny možné typy změn, které lze provést v prohlášení během roku (viz. Tabulka 5).
Tabulka 5: Hodnoty picklistu cust_etax_declarationChangeTypes (zdroj: autor)
ID hodnoty Název
personalTaxAllowanceYes Uplatňuji základní slevu na
poplatníka
personalTaxAllowanceNo Neuplatňuji základní slevu na
poplatníka
basicAllowanceForDisabledPersonYes Uplatňuji základn slevu na invaliditu
basicAllowanceForDisabledPersonNo Neuplatňuji základní slevu na invaliditu
extendedAllowanceForDisabledPersonYes Uplatňuji rozšířenou slevu na invaliditu
extendedAllowanceForDisabledPersonNo Neuplatňuji rozšířenou slevu na invaliditu
allowanceToZTPCardHolderYes Uplatňuji slevu na držitele průkazu ZTP/P
allowanceToZTPCardHolderNo Neuplatňuji slevu na držitele
průkazu TZP/P
allowanceForTheStudentYes Uplatňuji slevu na studenta
allowanceForTheStudentNo Neuplatňuji slevu na studenta
childrenChange Změna u dětí
anotherPersonChange Změna jiné osoby
Picklist cust_etax_documentType obsahuje hodnoty pro rozlišení typů příloh, které zaměstnanci nahrávají (viz. Tabulka 6). Slouží to hlavně pro urychlení práce mzdovým účetním, pokud hledají určitý typ přílohy, nemusí prohledávat všechny (např. mzdová účetní kontroluje nárok na nezdanitelnou část úroky z úvěru v žádosti a potřebuje zkontrolovat pouze potvrzení o zaplacených úroků, tak bude hledat pouze typ přílohy
„Potvrzení o platbě úroků“, místo toho, aby otevírala všechny přílohy.)
Tabulka 6: Hodnoty picklistu cust_etax_documentType (zdroj: autor)
ID hodnoty Název
affidavit Čestné prohlášení
previousEmployerConfirmation Potvrzení od předchozího
zaměstnavatele
disabilityConfirmation Potvrzení o invaliditě
extendedDisabilityConfirmation Potvrzení o rozšířené invaliditě
disabilityIdentificationCard Průkaz ZTP/P
studyConfirmation Potvrzení o studium
childStudyConfirmation Potvrzení o studium dítěte
childDisabilityIdentificationCard Průkaz ZTP/P dítěte
childBirthCertificate Rodný list
childOther Ostatní
employmentDepartmentConfirmation Potvrzení z úřadu práce
taxableWageConfirmation Potvrzení o zdanitelných
příjmech
incomeConfirmation Potvrzení příjmu
marriageCertificate Oddací list
kindergartenPaymentConfirmation Potvrzení platby školkovného
mortgageContract Smlouva hypotečního úvěru
interestsConfirmation Potvrzení o platbě úroků
extractFromLandRegistry Výpis z katastru nemovitostí
pensionInsuranceContract Smlouva penzijního pojištění
pensionInsurancePaymentConfirmation Potvrzení platby penzijního pojištění
premiumLifeInsuranceContract Smlouva životní pojištění
premiumLifeInsurancePaymentConfirmation Potvrzení platby životního pojištění
tradeUnionContributionsConfirmation Potvrzení členství
paymentsForExaminationsConfirmation Potvrzení platby za zkoušku
gratuitousTransactionsConfirmation Potvrzení
other Ostatní
4 Vývoj aplikace a implementace
4.1 Časový plán
Po dokončení analýzy a návrhu řešení se přešlo na vývoj aplikace. Vývoj aplikace byl naplánovaný na 4 měsíce, tedy rozdělen na 4 sprinty. V naplánovaných 4 měsících je zahrnuté i vytvoření databáze v SAP SuccessFactors, implementace na testovací prostředí SAP SuccessFactors a testování aplikace na testovacím prostředí. Při návrhu řešení byl plán jednotlivých sprintů vymezen v nástroji pro řízení projektu.
V průběhu prvních sprintů se věnoval čas vytvoření struktury projektu, vytvoření databáze na vývojovém prostředí SAP SuccessFactors a vývoji hlavní obrazovky aplikace.
V následujících dvou sprintech probíhal vývoj obrazovek, ve kterých se vyplňovali formuláře, zároveň během těchto sprintů probíhalo testování jednotlivých funkcionalit, které odpovídaly vývoji dané části aplikace. Poslední sprint byl věnovaný vývoji obrazovky pro kontrolu formulářů a implementaci aplikace na testovací prostředí SAP SuccessFactors, kde proběhlo celkové testování aplikace.
4.2 Vývojový prostředí
Pro vytvoření projektu byla použita webová služba SAP WEB IDE Full-Stack. Tato webová služba umožňuje vytvořit projekt z přednastavených templatů, byl zvolen template SAPUI5 Application pro Neo prostředí s XML view type. To znamená že pohledové obrazovky budou psány ve formátu XML. Pro správu verzí byl projekt nasazen na git repositář v aplikaci Bitbucket.
Po vytvoření základní struktury aplikace a nasazení na git byl repositář stažen do aplikace Visual Studio Code, kde následně probíhal vývoj aplikace. Do Visual Studio Code byly staženy rozšíření podporující vývoj SAPUI5 aplikací, jako je například knihovna všech SAPUI5 komponent. Toto rozšíření během vývoje napovídalo atributy komponent a kontrolovalo správnost komponent.
Celý vývoj probíhal na lokálním prostředí, což přineslo výhody i nevýhody. Jednou z výhod byla rychlost načítaní aplikace v prohlížeči během vývoje, neboť všechny SAPUI5 komponenty se načítaly z lokální knihovny místo toho, aby se načítaly z externího serveru.
Jendou z velkých nevýhod byla konfigurace web serveru, bez kterého by se aplikace v lokálním prostředí nespustila a nemohla komunikovat se SAP SF.
4.3 Struktura souborů aplikace
Struktura aplikace (viz. Obrázek 22) začíná kořenovým adresářem taxFromsApp s podadresářem webapp a soubory neo-app.json, .gitignore a README.md. Adresář webapp obsahuje veškerý kód, který souvisí s aplikací.
Adresář view obsahuje pouze jenom SAPUI5 views a fragmenty, které jsou rozděleny podle obrazovky, ve který se používají. Adresář neobsahuje žádnou logiku aplikace, veškerá logika aplikace je obsažena v adresáři controller. V adresáři i18n jsou obsaženy všechny lokalizační soubory, to umožňuje mít aplikaci v různých jazykových variacích. Adresář libs obsahuje soubory, které slouží pro tvorbu modelů a logiky týkajících se modelů (např. formátování dat). Zároveň se sem vkládají externí JavaScriptové knihovny. „Soubor manifest.json definuje statické informace o aplikaci, například název aplikace nebo umístění různých souborů.“6 [27] (překlad autora)
Obrázek 22: Struktura souborů aplikace (zdroj: autor)
6 Původní znění: „The manifest.json file defines static information about the application, such as the
4.4 Tvorba MDF objektů
Tvorba MDF objektů probíhá v SAP SF na stránce Configure Object Definition >
Create New> a vybrat ze seznamu Object Definition. Tím se otevře obrazovka s konfigurací objektu.
Při tvorbě MDF objektu je potřeba definovat základní parametry (viz. Obrázek 23), pro potřebu databáze aplikace se jedná o parametry: Code, Effective Dating, API Visibility a Status, ostatní parametry není potřeba definovat, ty se netíkají potřeby pro aplikaci. Code je jednoznačný identifikátor objektu a má automaticky předponu „cust_“, neboť se jedná o rozšiřující objekt systému. U Effective Dating označuje, jestli záznamy budou historizované (tzn. pokud se vytvoří záznam, automaticky má začátek platnosti 1.1.1900 a konec 12.12.9999, ale lze nastavit že určité informace v rámci tohoto záznamu se mají od 1.1.2000 změnit a pokud se přes API zeptáme na informace před 1.1.200, budou jiné než po 1.1.2000.) Pokud jsou vyžadované historizované záznamy, tak jsou zde ještě možnosti, jestli záznamy můžou mít více změn během jednoho dne nebo pouze jednou denně. Pro potřebu aplikace nejsou potřeba historizovatelné záznamy, tím pádem se zde bude vybírat pouze jestli se jedná o „parent“ nebo „child“ objekt. API Visibility označuje, jak s daty můžeme pracovat pomocí API. API visibility může být nastaveno na Read Only (pouze čtení), Editable (editovatelné) nebo Not Visible (není viditelné). Status definuje, jestli MDF objekt je stále aktivní, pokud by byl neaktivní, v systému by nebyl vidět a nemohl by být používaný. [30]
Obrázek 23: Definice základních parametrů MDF objektu (zdroj: autor)
V další části se konfigurují jednotlivé fieldy objektu a asociace MDF objektu (viz. Obrázek 24). Každý field a asociace začíná předponou „cust_“, jedná se o vlastní rozšiřující fieldy a asociace. Field musí obsahovat alespoň Name, Maximum Length a Data Type. Maximální délka může být vynechána, systém automaticky doplní základní hodnotu podle datové typu.
[28] U associace se vyplňuje Name, Multiplicity (kardinalita), Destination Object a Type.
Destination Obejct je název „child“objektu, na který se bude vazba odkazovat. Type označuje typ vazby, vazba může být typu „Composite“ nebo „Valid When“. „Composite“ značí, že záznam v „child“ objektu bude vždy vázán právě s jedním záznamem v „parent“ objektu.
„Valid When“ umožňuje záznam v „child“ objektu vázat na vícero záznamů „parent“ objektu.
[29]
Obrázek 24: Definování fieldů a asociací MDF objektu (zdroj: autor)
4.5 Vývoj aplikace
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.
