VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Počítačové systémy. Aplikace pro vedení záznamů daňové evidence

VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Počítačové systémy

Aplikace pro vedení záznamů daňové evidence bakalářská práce

Autor: Martin Halík Vedoucí práce: Ing. Marek Musil Jihlava 2015

Vložený papír se zadánímVysoká

škola polytechnická Jihlava

Tolstého 16, 586 01 Jihlava

ZADÁNÍ BAKALÁŘSKÉ PRÁCE

Autor práce:

Jan Novák

Studijní program:

Elektrotechnika a informatika

Obor:

Aplikovaná informatika

Název práce:

Název Práce

Cíl práce:

Práce se.

Jméno vedoucího BP

Jméno vedoucího katedry

vedoucí bakalářské práce

vedoucí katedry Katedra elektrotechniky a informatiky

Abstrakt Hlavním úkolem této práce je vytvoření databázové aplikace, která bude umožňovat provedení základních operací pro daňovou evidenci. Bude obsahovat agendy pro vytváření a evidenci účetních dokladů, nabídek a zakázek. Snahou aplikace bude maximální automatizace těchto procesů za pomocí technologií, jako je například optické rozpoznání znaků (OCR). Aplikace bude vytvořena na platformě Microsoft .NET Framework pomocí jazyka C#. Pro návrh uživatelského rozhraní bude využita platforma Windows Presentation Foundation. Dále bude využito moderního návrhového vzoru Model-View-ViewModel. Rovněž bude proveden rozbor použitých technologií a postupů. Výstupem práce pak bude plně využitelný software, která uživateli poskytne maximálně automatizovanou podporu při daňové evidenci.

Klíčová slova C#, Daňová evidence, MVVM, OCR, WPF

Abstract The main objective of this thesis is to develop a database application that will allow doing basic operation for tax records evidence. It will contain agendas for creation and registration of actuarial documents, offers and commisions. The goal of this application will be maximal automatization of these processes by using technologies like for example Optical Character Recognition (OCR). The application will be developed on platform Microsoft .NET Framework with C# language. For the design of user interface, the Windows Presentation Foundation platform will be used. Furthermore, the modern design pattern Model-View-ViewModel will be used. An analysis of used technologies and practices will be done. The output of the thesis will be a fully usable software which will provide maximum automated support for tax records evidence.

Key words C#, MVVM, OCR, Tax Records Evidence, WPF

Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne

............................................... Podpis

Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Ing. Marku Musilovi, za možnost vytvářet tuto práci pod jeho vedením.

Obsah 1

Úvod.......................................................................................................................... 7

2

Současný stav na trhu ............................................................................................... 9

3

4

2.1

Situace na trhu .................................................................................................... 9

2.2

Doporučení vhodného produktu ....................................................................... 13

Návrh řešení ............................................................................................................ 14 3.1

Funkce aplikace ................................................................................................ 14

3.2

Analýza problémových oblastí ......................................................................... 16

3.3

Databáze ........................................................................................................... 20

3.4

Návrh uživatelského rozhraní .......................................................................... 23

Realizace ................................................................................................................. 26 4.1

Popis použitých technologií ............................................................................. 26

4.2

Souborová struktura aplikace ........................................................................... 34

4.3

Rozbor hlavních funkčností programu ............................................................. 36

4.4

Grafické rozhraní ............................................................................................. 47

5

Návrh na další rozvoj aplikace................................................................................ 52

6

Závěr ....................................................................................................................... 54

Seznam použité literatury ............................................................................................... 55 Seznam obrázků .............................................................................................................. 57 Seznam použitých zkratek .............................................................................................. 58 Seznam příkladů ............................................................................................................. 59 Přílohy............................................................................................................................. 60 1

ER diagram ............................................................................................................. 60

2

Přiložené CD ........................................................................................................... 61

3

Manuál aplikace ...................................................................................................... 62

1 Úvod Již zřídka se setkáváme se stavem, že veškerá ekonomická agenda probíhá pouze v listinné podobě. Naštěstí na trhu existuje celá řada ekonomických systémů, které práci účetním subjektům ulehčují v mnoha směrech. Často se jedná o systémy pokrývající velmi širokou škálu činností - od daňové evidence, přes knihu jízd až po podvojné účetnictví a třeba personalistiku. Pro domácí vedení účetnictví jsou však tyto systémy většinou zbytečně komplikované a rozsáhlé. Pak existují aplikace naopak téměř jednostranně zaměřené (například na pouhé vytváření faktur, jednoduchou evidenci dokladů nebo pouze výpočet daně). Uživatel je tak mnohdy nucen instalovat několik takových programů najednou. Poptávku na systémy vytvářejí nejen střední a velké podniky, ale právě i menší firmy a živnostníci, kteří zpravidla nepotřebují provádět tolik úkonů. Mnohdy totiž na samotné účetnictví využívají externích služeb kvalifikovaných účetních. Proto tento segment trhu vyžaduje i aplikace mnohem jednodušší - takové, díky nimž zvládne běžnou denní práci i laik. Navíc tito zákazníci požadují co nejmenší ceny software. Při podrobnějším zkoumání trhu s ekonomickým software se však nepodařilo nalézt takový produkt, který by vyhovoval potřebám zadavatele – firmě Petr Horn. Proto vznikla myšlenka vytvoření aplikace, která je obsahem této práce. Firma se potýká, podobně jako ostatní společnosti podobného formátu (do 5 zaměstnanců), s potřebou vést daňovou evidenci vlastními silami a co možná nejefektivnějším a nejrychlejším způsobem. Proto by jednou z hlavních předností aplikace měla být zvýšená míra asistence uživateli při provádění všech činností (např. asistence při tvorbě nabídek, automatické zaznamenávání faktur atd.). Cílem práce je tedy především vytvořit aplikaci pro tzv. „domácí účetní“. „Domácími účetními“ rozumíme především fyzické osoby a drobné živnostníky zpracovávající si daňovou evidenci a účetnictví svépomocí v domácích podmínkách. U těchto „účetních“ se lze často setkat s nepříliš pokročilými znalostmi výpočetní techniky a potažmo i malou ochotou tyto znalosti získávat. Program je již od začátku pojat jako řešení na míru pro firmu Petr Horn, která podniká v oboru průmyslové automatizace.

7

Motivací této práce je i osvojení a zdokonalení technik WPF (Windows Presentation Foundation). V práci je plánováno využití návrhového vzoru MVVM (Model-ViewViewModel), jenž je pro WPF ideálním konceptem. Ten používají i vývojáři společnosti Microsoft. V běžné programátorské praxi se tohoto vzoru příliš často nepoužívá, proto je zajímavé porovnání, jak bude probíhat vývoj aplikace s jeho striktním dodržením. Dále je cílem vytvořit aplikaci tak, aby co nejvíce usnadnila uživatelům jejich práci. To je velmi nelehký úkol, se kterým se programátoři a analytici musí potýkat každý den. Pro vývojáře není vždy lehké, vzhledem k jeho znalostem a zkušenostem na poli informačních technologií, navrhnout aplikaci tak, aby byla pro laického uživatele snadno uchopitelná, ovladatelná a práce s ní efektivní. Dnešní programy určené pro běžné uživatele se totiž snaží o totéž. Může se jednat o různé formy intuitivního uživatelského rozhraní, interaktivity, cílených nápověd, předplňování formulářových polí atd. Není ovšem ani tak potřeba kopírovat nejnovější trendy v grafickém designu formulářových aplikací, jako spíš uvědomit si, jak tyto trendy umožňují přenést část práce z člověka na výpočetní techniku.

8

2 Současný stav na trhu V této kapitole bude proveden rozbor současné situace na trhu k datu 15. 4. 2015 s ohledem na typ vznikající aplikace. Dále zde bude uvedeno několik způsobů, jak se zadaného problému zhostit.

2.1 Situace na trhu Trh se softwarem veškerého druhu je velmi rozsáhlý. Vzhledem ke své povaze je v podstatě celosvětový. Najdeme na něm jak aplikace volně šiřitelné, tak placené. V poslední době však přeci jen dochází k určitému posunu. Zhruba před deseti lety byly hlavní komoditou klientské desktopové aplikace. Dnešní trend nahrává spíše aplikacím pro mobilní zařízení nebo cloudovým službám. Cloudové služby jsou moderním trendem uchování dat a práce s nimi. Veškerá data jsou uložena na serveru, stejně tak i aplikace k nim přistupující je spouštěna na serveru. Tento způsob řešení přináší tu výhodu, že lze tedy ke svým datům přistupovat kdykoliv a odkudkoliv. Uživatelé tedy neplatí za software, ale za jeho užití. Mohlo by se tedy na první pohled zdát, že na trhu bude k dispozici aplikace, která bude splňovat klientovy požadavky. Při podrobnější úvaze lze ale dospět tomu, že tento trh je potřeba zúžit. Zde jsou vyjmenovány hlavní faktory, které umožňují toto zúžení: 

Výsledná aplikace nemá být plnohodnotným ekonomickým nebo účetním systémem, naopak má sloužit pouze pro evidenci a tvorbu faktur a nabídek



Program má být co nejjednodušší, co se týče grafického rozhraní a uživatelského ovládání



Vzhledem k jazykovým schopnostem uživatele je nutné, aby aplikace byla lokalizována v českém jazyce



Program také musí ctít českou legislativu

Za konkurenty na takto specifikovaném trhu se dají považovat následující výrobci a jejich produkty. Stormware s.r.o. – Pohoda – tento produkt je zde nutné uvést, protože již je zadavatelem pro účetnictví použit. Systém Pohoda je komplexní ekonomický systém, přesto ale nenaplňuje zadavatelovy požadavky. Dle jeho vyjádření je tento software 9

příliš složitý a málo přehledný, obsahuje spoustu nevyužitých funkcí. Stormware nabízí i verzi Pohoda Mini za cenu 1980 Kč bez DPH, která umožňuje základní daňovou evidenci. Ze zkušeností se stávajícím systémem však vyvstávají obavy, že i tato verze nebude příliš vyhovovat, navíc neumí tvorbu nabídek ani sdružování dokladů do zakázek. I proto se zadavatel poohlíží po nadstavbové, možná i náhražkové, aplikaci, která umožní výše požadované funkce. Ježek software s.r.o. – Duel – Společnost Ježek software poskytuje velmi zajímavý produkt Duel. Jedná se o modulární systém, který umožňuje využití pouze některé z jeho částí (modulů). Pro použití dle přání zákazníka by bylo možné využít modul Kancelář. Kancelář sice obsahuje více nadstavbových funkcí, ale vzhledem k poměrně dobře zpracovanému uživatelskému rozhraní se lze v programu celkem dobře orientovat. Uváděná cena za licenci verze programu pro daňovou evidenci, která obsahuje modul Kancelář, je 1500 Kč bez DPH. Uvedený software však nelze pro zadavatele doporučit, neboť neobsahuje možnosti seskupování dokladů do zakázek, evidenci a tvorbu nabídek. Ukázka z programu je na obrázku 1.

Obrázek 1: Ukázka z programu Duel

Milan Bánovský – Fakturky – Tento program je méně zajímavou variantou. Nabízí možnost vytvoření faktury, její export do různých formátů i správu vydaných a přijatých 10

faktur. Nicméně prezentace této aplikace nepůsobí profesionálně ani věrohodně. Mimo jiné nepřesvědčivě působí již fakt, že je na různých serverech po internetu nabízena bezplatná verze programu, kdežto na webové prezentaci výrobce je stejný software nabízen za cenu 660 Kč (navíc není zřejmé, zda se jedná o cenu bez DPH či nikoliv). I přes velmi příznivou cenu nelze produkt doporučit, neobsahuje totiž možnosti evidence zakázek, nabídek a uložení elektronického souboru. Studio Datales – Faktury – část zákazníkova problému by mohla řešit bezplatná aplikace s názvem Faktury. Umožňuje vytvoření a tisk faktury a s určitým omezením také cenové nabídky. Program však neobsahuje správu číselníků pro výběr např. zboží nebo příjemce faktury. Vzhledem ke své bezplatné distribuci může sloužit jako alternativa. Pro zadavatele však vhodný není, podobně jako u ostatních chybí sdružování do zakázek nebo ukládání elektronických souborů. Elisoft s.r.o – Daňová evidence Lite – tento produkt umožňuje evidenci a zakládání nových faktur. Není zatížen spoustou dalších agend jako ostatní ekonomické aplikace. Cena je 1980 Kč bez DPH. Neobsahuje možnost vložení elektronických souborů či práci se zakázkami. Ing. Martin Tobolka – Živnostník – za zmínku stojí i produkt Ing. Tobolky. Je určen primárně pro daňovou evidenci, umožňuje tedy evidenci faktur a jejich tvorbu. Nicméně i podle webové prezentace výrobce je systém již cca 3 roky neaktualizován, proto se lze snadno obávat, že uživatelská podpora nebude na valné úrovni. Tento software navíc neobsahuje funkce jako vložení souboru, práci s nabídkami a zakázkami. Licencování produktu je na webových stránkách popsáno poněkud nejednoznačně, ale dá se s určitou dávkou pravděpodobnosti vyvodit, že licence je dostupná zdarma. Correct software – Firma – Program Firma je určen, mimo jiné, také pro daňovou evidenci. Na rozdíl od jiných software obsahuje rozsáhlou dokumentaci včetně videonávodů. To je však jeho jedinou drobnou výhodou oproti většině ostatních produktů. Program není vybaven funkcemi pro ukládání souborů, tvorbou nabídek ani možností vzájemného provázání dokladů. Na svoji omezenou funkčnost se však vyznačuje poměrně vysokou cenou 2990 Kč (znovu není uvedeno, zda daň z přidané hodnoty je součástí ceny).

11

Asseco Solutions – Helios Red – Jedná se o komplexní ekonomický systém se zajímavým grafickým prostředím. Kromě požadované daňové evidence však obsahuje spoustu agend, které by se velmi pravděpodobně staly nevyužitými a v práci překážely a rozptylovaly. Společnost Asseco Solutions nabízí tento software dokonce i ve freeware variantě, ta je ovšem omezena maximální výší ročního obratu do 200 000 Kč. Tato částka je však pro zadavatele příliš nízká. V případě vyššího obratu se pak částky za software pohybují v mnohem vyšších hladinách, od 2300 Kč až po nejdražší verzi bez omezení, která je k mání za 58 300 Kč bez DPH. ZK Soft – Samostatná fakturace – Firma ZK Soft vyvinula modulární systém, jehož součástí je i program s názvem Samostatná fakturace, který umožňuje vystavování, tisk a evidenci faktur. Tento program by se dal vcelku dobře využít pro některé zákazníkovy potřeby. Neumožňuje však vytváření nabídkových listů, ani sdružování dokladů do zakázek. Cena modulu Samostatná fakturace je 900 Kč (znovu není uvedeno, zda daň z přidané hodnoty je součástí ceny). Ukázka z programu je na obrázku 2.

Obrázek 2: Ukázka z programu Samostatná fakturace

12

2.2 Doporučení vhodného produktu Všechny výše uvedené programy by zákazník mohl pro svou práci využít. Žádný z nich však plně nenaplňuje jeho očekávání. Někdy je to kvůli nedostatečným funkcím (absence tvorby nabídek, seskupování do zakázek, ukládání elektronických souborů), někdy na druhou stranu kvůli přebytku funkcí nebo nepříliš snadnému ovládání. Jindy zase daný software nelze doporučit kvůli ceně, obavě z nedostatečné uživatelské podpory či obecné obavě z funkčnosti produktu. U těch aplikací, které by svou jednoduchostí a lehkostí ovládání mohly splnit některé z požadavků zadavatele, je pak problémem, že tyto programy jsou vyrobeny malými společnostmi pro konkrétní účely, navíc jejich vývoj byl mnohdy již zastaven. Proto u nich nelze čekat možnosti dalšího rozšiřování či zákaznických úprav. Požadavků na výslednou aplikaci by bylo možné také dosáhnout kombinací některých programů od různých výrobců. To by ovšem jistě nebylo vhodným řešením a vnášelo by do domácího účetnictví nechtěnou decentralizaci. Kvůli těmto skutečnostem bylo se zadavatelem dohodnuto vytvoření nového software, který bude vytvořen na míru. Navíc bude možno aplikovat v budoucnu případná rozšíření tak, aby kopírovala potřeby rozvíjející se firmy.

13

3 Návrh řešení Nově vytvářený program tak bude mít za cíl vyvarovat se všech výše popsaných nedostatků, které postihují ostatní ekonomické systémy a zároveň si vzít z každého to pozitivní, co ten který program nabízí. Nedostatky jsou hlavně nepokrytí všech potřeb zadavatele, neefektivní a neintuitivní práce s programem. Nejdůležitějším faktorem výjimečnosti pak bude vlastní invence, především v oblasti návrhu uživatelského rozhraní a inteligence samotného programu. Návrh vzhledu aplikace je na obrázku 3.

Obrázek 3: Návrh podoby nové aplikace

3.1 Funkce aplikace Nová aplikace s pracovním názvem „Domácí účetnictví“ tedy bude obsahovat níže uvedený výčet funkcí. 

Tvorba a evidence faktur a dokladů Program umožní tvorbu nových a evidenci došlých faktur a dokladů, jejichž originál je v listinné nebo elektronické podobě. Po zadání údajů do formuláře bude tento uložen do databáze. Veškeré takto zaznamenané doklady bude možno zobrazit v seznamu.

14



Zjednodušená evidence faktury/dokladu pomocí oskenování listinné podoby dokumentu nebo vložením naskenovaného obrázku Bude kladen důraz na úsporu práce uživatele, takže bude umožněna evidence pomocí vložení oskenované formy dokladu nebo listinné podoby do skenovacího zařízení. Poté proběhne optické rozpoznání znaků a jejich rozbor do formulářových polí s následnou kontrolou uživatelem.



Automatizovaná tvorba a evidence nabídkových listů, využití šablon Aplikace umožní vytvářet a evidovat nabídkové listy, které jsou velmi podobné výsledným fakturám. Bude probíhat obdobně jako evidence dokladů, tzn. vyplněním formulářových polí a jejich uložením do databáze.



Možnost sdružování jednotlivých typů dokumentů (faktur a dokladů) do jednotlivých zakázek Zadavatel si přeje mít jednoduchý přehled o svých zakázkách/dílech a proto bude možno sdružit jednotlivé dokumenty do zakázek tak, aby spolu tvořily logické celky – faktury a doklady, které patří ke stejnému dílu a podobně.



Možnost vložení elektronického souboru k jednotlivým dokumentům Aplikace bude uchovávat libovolné elektronické soubory, které bude možno přiřadit k dokladu, faktuře, nabídce nebo zakázce. Lze si pak snadno otevřít originální doklad nebo nákres výrobku.



Možnost úpravy jednotlivých číselníků – obchodních partnerů, zboží Zadavatel si přeje mít detailní přehled o součástech zakázek a svých obchodních partnerech, proto mu bude program umožňovat tyto položky spravovat, např. vkládat vlastní výrobky, které lze fakturovat, díly, ze kterých se skládají nebo upravovat adresu u subjektu. Program tak tedy bude flexibilní a bude moci obsahovat jakákoliv data z těchto oblastí.



Pokročilé možnosti vyhledávání podle všech možných položek s možností uložení šablon filtrů Aplikace musí pro potřeby snadného dohledání starších dokladů a faktur obsahovat možnost prohledávání záznamů. To bude řešeno dynamickým filtrováním podle množství zvolených vlastností. Takto zvolená kritéria hledání bude možno uložit jako šablonu hledání.

15



Intuitivní a atraktivní uživatelské prostředí Důraz bude kladen především na intuitivitu a snadnost ovládání. Toho bude docíleno za pomoci jednoduchého vzhledu aplikace a skrýváním méně často používaných možností.



Tisk dokladů, faktur a nabídkových listů Aby bylo možno využít evidovaných dokumentů také v listinné podobě, bude připravena možnost jejich tisku.



Export do dokladů, faktur a nabídkových listů do PDF Aby bylo možno využít evidovaných dokumentů také v elektronické podobě, bude zapracována možnost jejich převodu do PDF



Možnost přímého odeslání faktury na zadaný email Pro využití v elektronickém styku s obchodními partnery bude dostupná možnost jednoduchého odeslání přímo z aplikace na zadaný email.



Možnost zálohy databáze Z důvodu obavy uživatelů o ztrátu svých dat bude program obsahovat možnost zálohy uložených informací. Ta bude provedena zálohou celého databázového souboru na FTP server.

3.2 Analýza problémových oblastí V této kapitole bude provedena analýza jednotlivých oblastí, které se týkají požadovaných funkcí programu a představují potenciálně obtížná místa při vývoji aplikace. Zároveň bude přednesen návrh jejich řešení.

Automatizované zadávání faktur Tato oblast je jedna z nejsložitějších. Plná automatizace by představovala stav, kdy by uživatel zadal fakturu pouhými dvěma stisknutími tlačítka myši. Ideální průběh celého procesu je vyznačen na obrázku 4.

16

Obrázek 4: Proces automatizace zadávání dokladů

Automatizované zadávání faktur spočívá v těchto krocích 1) Uživatel vloží listinnou podobu faktury do skenovacího zařízení a zmáčkne tlačítko v aplikaci. 2) Oskenuje se dokument vložený do skenovacího zařízení. 3) Nad výsledným obrázkem, který vznikl oskenováním, je proveden proces optického rozpoznání znaků (OCR). 4) Výsledkem OCR je textový soubor, ze kterého by se následně rozebraly jednotlivé položky faktury a zapsaly do příslušných políček formuláře aplikace 5) Tento formulář spolu s náhledem obrázku oskenované faktury je předložen uživateli ke kontrole zadaných údajů. 6) Uživatel stiskem tlačítka potvrdí správnost údajů a uloží fakturu do databáze. V tomto procesu se vyskytují 3 místa vyžadující zvýšenou pozornost - body 2, 3 a 4. Ad 2) Oskenování dokumentu pomocí aplikace nebude snadný úkol vzhledem k faktu, že existuje mnoho různých typů skenerů. Bude tedy třeba pro tento úkon nalézt obecné řešení. Tím by mohlo být využití rozhraní Windows WIA (Windows Image Acquisition). Ad 3) Provedení OCR je klíčové pro celý proces, jelikož jeho využitím se ušetří uživateli nejvíce práce. Naprogramování OCR systému by však bylo tématem minimálně na diplomovou práci. Proto se nabízí řešení využití některého stávajícího 17

OCR produktu. Jelikož je kladen také důraz na cenu aplikace, je potřeba se porozhlédnout na trhu volně dostupných nástrojů. Zde je jednoznačnou volbou OCR systém Tesseract OCR, který je momentálně nejlepším freeware OCR na světě. I kvůli tomu, že jeho sponzorem se stala v roce 2007 společnost Google, Inc. [1] Tesseract OCR disponuje rozhraním pro příkazový řádek, je tedy lehce využitelný pro napojení v aplikaci. Samotným napojením však práce nekončí, nýbrž začíná, protože existuje mnoho různých ekonomických software, existuje i mnoho podob faktur a dokladů. Faktury jsou rozdílné jak rozložením jednotlivých položek, tak použitými fonty písem, ale i třeba názvy jednotlivých položek. Tesseract OCR, ostatně jako další OCR, není bohužel všemocný nástroj, je potřeba ho určitá písma „naučit“. Ad 4) V případě, že se lze na výsledky z OCR spolehnout, nastává další problém – jak určit, kde se která položka nachází a jaká je její hodnota. Pro ilustraci lze uvést příklad, že jedna faktura používá horizontální uspořádání (hodnota položky je umístěna vedle názvu položky), druhá používá uspořádání vertikální (hodnota položky je umístěna pod názvem položky) a třetí může využívat uspořádání smíšené. Vyřešení tohoto problému bude spočívat především v analýze co největšího množství různých faktur. Problém by se dal řešit tak, že by byly definovány šablony rozložení faktur a položky by se dohledávaly podle souřadnic. Nebo by mohla být definována klíčová slova určující názvy položek faktury a následně by se dohledávalo nejbližší vhodné slovo nalezené pomocí OCR.

Ukládání elektronických souborů Tato oblast navazuje na předchozí téma automatizovaného zadávání faktur, kde je požadováno uložení naskenované podoby faktury/dokladu. Pro tuto potřebu je nutno zřídit úložiště elektronických souborů. U zadavatele se nepředpokládá přítomnost např. cloudového úložiště, proto řešením bude pravděpodobně umístění úložiště přímo na stroji, kde bude aplikace spuštěna. Je několik možností, pro tuto aplikaci je zvolena možnost ukládání na FTP server. Jako server v tomto případě poslouží volně dostupný nástroj FileZilla Server. Důvodem jeho použití je poměrně dlouhá doba jeho vývoje, ověřená spolehlivost a samozřejmě nulové pořizovací náklady. [2]

18

Automatizovaná tvorba nabídkových listů Tvorba nabídkových listů nebude tak častou činností, přesto je možno ji alespoň částečně zautomatizovat. Toho může být docíleno například nabízením šablon nabídkových listů, které by vznikaly na základě již dříve vytvořených nabídek. Samozřejmě by se zohledňovaly aktuální ceny jednotlivých ceníkových položek.

Pokročilé možnosti vyhledávání s možností uložení šablony filtru Ačkoliv úkol zní jednoduše, je potřeba si dát pozor při jeho vypracování. Vše by mělo být zpracováno precizně na straně databáze tak, aby se mechanismus ukládání a používání filtrů dal využívat obecně pro jakoukoliv entitu databáze. Zároveň je v plánu aplikaci obohatit univerzálním hledacím políčkem, které bude hledat zadaný výraz napříč celou databází. Zamýšleným vyhledávacím motorem pak nebudou obyčejné SQL vyhledávací příkazy, ale bude vhodné využít fulltextové vyhledávání pomocí indexů, což bude i mnohem rychlejší.

Export dokladů, faktur a nabídkových listů do PDF Vytvoření PDF z čistých databázových dat také není snadným úkolem. Naštěstí není potřeba studovat architekturu PDF, jehož manuál čítá cca 1200 stran, ale existují také open-source projekty, který se dají k manipulaci s PDF využít. Jedním z nich je i projekt iTextSharp, knihovna pro práci s PDF napsaná v jazyce C#. Ukázka požadovaného výstupu z aplikace je na obrázku 5.

19

Obrázek 5: Výstup z programu v podobě PDF

3.3 Databáze Již samotný úkol jednoznačně definuje povinnost ukládat a uchovávat určité množství dat. Proto je zřejmé, že základem řešení bude databáze. Ta je ostatně jádrem většiny informačních systémů. Existuje mnoho typů a výrobců databází. Každý produkt se vždy trochu liší od předchozích a má své výhody i nevýhody. Proto je řešení koncipováno tak, aby bylo možné dle potřeby napojit hned několik druhů databáze. Typ databáze se pak určí podle požadavků klienta přímo na konkrétní instalaci. Preferována bude databáze typu embedded. Tento typ databáze umožňuje velmi snadnou správ, jelikož celá databáze představuje pouze jediný soubor na disku. Proto lze velmi snadno takovou databázi přesouvat, zálohovat a aplikace, která je na ní postavená, je přenositelná. Využitelné databázové stroje budou: Microsoft SQL Server Compact Edition, SQLite, PostgreSql, Microsoft SQL Server.

ER model databáze ER model databáze je vložen jako Příloha 1. V níže uvedeném seznamu je stručný popis jednotlivých entit diagramu. Entita

Popis

Adresy

Seznam adres osob a subjektů

Aktivity

Číselník aktivit databázového záznamu (aktivní, smazán atd.). 20

DruhZbozi

Číselník druhů zboží

Faktury

Seznam vydaných i přijatých faktur a dokladů

FakturyZakazek

Seznam faktur a dokladů přiřazených k zakázkám

FiltrOperator

Operátor uloženého filtru (rovná se, obsahuje atd.)

Filtry

Seznam dostupných filtrů pro hledání

Kraje

Seznam krajů v České republice

Nabidky

Seznam vytvořených nabídek, lze zde označit nabídku jako šablonu pro nově vytvářené

NabidkyZakazek

Seznam nabídek přiřazených k zakázkám

Nastaveni

Uložená uživatelská nastavení, např. připojení k FTP

Obce

Seznam obcí v České republice

Okresy

Seznam okresů v České republice

Osoby

Seznam kontaktních osob, které mohou být přiřazeny k subjektu

PlatebniMoralka

Číselník typů platební morálky odběratele

Polozky

Seznam položek faktury, dokladu, nabídky

SablonyFiltru

Uložené šablony filtrů hledání

Soubory

Seznam souborů připojených k jednotlivým entitám (dokladu, faktuře atd.)

Subjekty

Seznam subjektů (dodavatelé, odběratelé, výrobci atd.)

TypAdresy

Číselník typů adres (fakturační, dodací, sídlo)

TypEntity

Číselník typů entit použitých v aplikaci, využívá se pro rozlišení v obecných seznamech, obsahuje hodnoty jako faktura, nabídka, zakázka atd.

TypFaktury

Číselník typů faktur (příjmová, výdajová, doklad atd.)

TypPrilohy

Číselník typů přílohy (oskenovaný originál, příloha atd.)

UlozeneFiltry

Seznam filtrů, které jsou obsahem šablony pro hledání

Vyrobci

Seznam výrobců zboží

Zakazky

Seznam zadaných zakázek

Zbozi

Seznam zboží

Systém filtrů Jedním z hlavních požadavků na aplikaci byla možnost vyhledávání jednotlivých entit pomocí zadaných hodnot. Toto vyhledávání je zpracováno obecně tak, aby bylo možno 21

přidávat a měnit předem definované filtry pouze na základě úprav v databázi, případně v serverové části aplikace. Toho je docíleno navrženými entitami FiltrOperator a Filtry. Níže je uveden jejich podrobnější popis na základě výčtu jejich atributů. FiltrOperator 

Id – jednoznačný identifikátor operátoru



Popis – textový popis operátoru, tedy například rovná se, obsahuje, větší než



Znak – znak, který odpovídá textovému popisu



Db_znak – znak, který představuje daný operátor na databázovém stroji

Filtry 

Id – jednoznačný identifikátor filtru.



Popis – textový popis, který uvidí uživatel, tedy položka, podle které se bude vyhledávání provádět, například „Číslo faktury“.



Vyraz – výraz, který danou položku představuje v databázovém dotazu. Zde je nutné, aby bylo v souladu se skutečně napsanými příkazy SELECT na serverové straně aplikace. Výraz se skládá z aliasu (zástupného jména) tabulky použitého v dotazu a jejího atributu, tedy například Faktury.castka_celkem.



Typ – určuje, ke které entitě se filtr vztahuje, cizí klíč do tabulky TypEntity.



DatovyTyp – datový typ, který přísluší výrazu pro hledání. Podle daného typu se aplikace rozhoduje, který operátor nabídne, například String, Int nebo DateTime.

Využití aktivity V návrhu databáze je často využit atribut aktivita, který umožňuje nastavit aktivitu pro jednotlivé entity. Tento atribut nabývá hodnot z číselníku Aktivity, například „aktivní“, „neaktivní“ nebo „smazáno“. V průběhu života databáze tak není nutno mazat záznamy SQL příkazem DELETE, což je nevratná operace, ale postačí nastavit aktivitu na hodnotu „smazáno“. K takovému záznamu se lze pak snadno kdykoliv vrátit, uživatel tedy chybnou operací nepřijde o svá data, což je především u laických uživatelů velmi podstatné. Navíc odpadá problém mazání nebo úpravy dat v případě, že na daný záznam je vázán cizí klíč v jiné tabulce.

22

3.4 Návrh uživatelského rozhraní Uživatelské rozhraní je navrženo tak, aby bylo co nejvíce přehledné a intuitivní. Zároveň je důležité, aby neobsahovalo prvky, které mohou odvádět pozornost nebo být nepříjemné pro oči, ať už svou barvou, proporcemi, nebo umístěním. Důraz je také kladen na vyvážený poměr interaktivity a jednoduchosti ovládání. Současným trendem ve vývoji webových, ale i desktopových, aplikací je také použití tzv. prázdných ploch – uživatel nesmí mít pocit, že je aplikace příliš komplikovaná. Strukturu okna je na obrázku 6.

Obrázek 6: Struktura hlavního okna

Rámec aplikace Samotný rámec aplikace se snaží o udržení aktuální trendů v návrhu grafického rozhraní aplikací a neslouží tedy pouze k ovládání velikosti okna nebo jeho uzavření. Místo toho obsahuje navíc i prvky pro pohyb v aplikaci (mezi jednotlivými záložkami pracovní plochy) a prvky pro společné akce nad všemi spravovanými objekty (faktura, nabídka atd.). Ukázka navrženého rámce je na obrázku 7.

Obrázek 7: Rozšířený rámec aplikace

23

Hlavní menu Jako hlavní ovládací prvek je použit pás karet, takzvaný ribbon, který se začal do podvědomí uživatelů dostávat díky novějším verzím Microsoft Office (od verze 2007) a také Microsoft Windows. Poskytuje rychlý a s pomocí ikon i graficky názorný přehled uživateli dostupných akcí. Zároveň obsahuje pole pro rychlé hledání jakékoliv položky napříč celou databází programu. Na pásu karet jsou dostupné akce všech agend spravovaných aplikací, kterými jsou Faktury, Zakázky a Nabídky. Návrh pásu karet pro aplikaci Domácí účetnictví je na obrázku 8.

Obrázek 8: Pás karet

Ribbon obsahuje také tzv. chytré tlačítko, které nahrazuje všeobecně známou položku menu „Soubor“. Mimo základních operací vložení obsahuje pokročilé možnosti aplikace. Ty jsou záměrně „skryty“ pod tímto tlačítkem tak, aby nerozptylovaly neznalé uživatele. Ukázka takového skrytí je na obrázku 9.

Obrázek 9: Ukázka skrytí nadbytečné akce

24

Pracovní plocha Největší částí hlavního okna aplikace je pak pracovní plocha, která se chová jako běžný internetový prohlížeč – jednotlivé úkony/stránky se zobrazují jako záložky. Mezi těmito záložkami lze jak přepínat, tak je také zavírat. Aplikace díky tomu není přeplněna otevřenými okny a uživatel ihned může vidět, jakou práci ve kterých agendách právě provádí. Možné využití pracovní plochy lze vidět na obrázku 10.

Obrázek 10: Pracovní plocha

25

4 Realizace 4.1 Popis použitých technologií Jedná se nejen o programovací jazyky a běhová prostředí, ale také o nástroje třetích stran, bez kterých by tvorba software tohoto druhu zabrala mnohonásobně více času. Vývojářská obec je celosvětově velmi početná a většinou tak není složité najít i takové produkty, které lze zdarma využít pro vývoj komerční aplikace. V této kapitole bude také stručně popsáno, jak probíhá programování aplikace podle návrhového vzoru Model – View – ViewModel (dále jen MVVM).

Microsoft .NET Framework 4.0 .NET Framework (.NET čteme dot net) je rozsáhlá softwarová platforma, která je určena pro vývoj mnoha různých druhů aplikací. Za pomoci .NET Framework můžeme vyvíjet nejen klasické aplikace pro Windows, ale mimo jiné i webové aplikace a služby, aplikace pro mobilní zařízení a mnoho dalších. [3] Platforma obsahuje velké množství knihoven pro usnadnění práce programátorů. Základní knihovnou je Base Class Library. .NET obsahuje knihovny pro usnadnění přístupu k datům (ADO.NET) a XML, dále knihovny pro vývoj webových a desktop aplikací, webových a systémových služeb. K těmto základním knihován lze přímo přistupovat pomocí množství programovacích jazyků, jejichž základní vlastnosti jsou definovány v Common Language Specification (CLS). Vykonávání programů vzniklých nad .NET řídí jeho součást zvaná Common Language Runtime (CLR). Programy vzniklé v .NET jsou totiž kompilovány pouze do přechodového jazyka MSIL (Microsoft Intermediate Language). CLR provádí jeho překlad do strojového kódu pro konkrétní operační systém [4]. Vývoj samotný pak probíhá ve vývojovém prostředí, nejčastěji pak v Microsoft Visual Studio. Architektura platformy .NET je znázorněna na obrázku 11.

26

Obrázek 11: Architektura .NET [5]

Platformu .NET byla pro práci zvolena z toho důvodu, že je stále velmi výhodnou platformou pro vývoj desktopových aplikací, má rozsáhlé zdroje informací a jednu z největších vývojářských komunit. Navíc s posledními zprávami od Microsoftu se zdá, že tato společnost chce posílit své postavení mezi programátory, jelikož vyhlásila otevření zdrojových kódů pro mnoho dalších větví .NETu a také větší podporu pro operační systémy jako jsou Linux, iOS nebo Android. Tato podpora by měla být v podobě speciálně upravených verzí frameworku. Minimálně aplikační logika by pak byla využitelná pro případný další budoucí rozšiřující modul v podobě aplikace pro jinou softwarovou platformu.

Windows Presentation Foundation Windows Presentation Foundation (dále jen WPF) je podmnožinou výše popsaného .NET frameworku a je primárně určen pro tvorbu uživatelského rozhraní. Společnost Microsoft navrhla tuto technologii jako nástupce své dřívější Windows Forms (nebo také WinForms) založené na rozhraní GDI. Obě tyto technologie v současné době Microsoft stále udržuje jako hlavní pro návrh desktop aplikací. WPF má však oproti WinForms několik hlavních výhod, které jsou vyjmenovány níže.

27



Není založen na GDI, ale na DirectX, což umožňuje hardwarovou akceleraci. Aplikace ve WPF jsou tedy svižnější a nezatěžují tolik procesor.



Z programátorského pohledu lze oddělit část grafickou a část výkonného kódu.



Mnohem rozsáhlejší možnosti úpravy grafického designu.



WPF nevykresuluje grafické prvky na základě použitých pixelů, proto není závislý na změnách DPI, kdežto prvky ve WinForms se mění v závislosti na DPI.

Samotné WPF používá značkovací jazyk XAML. Ten vychází z jazyka XML a má oproti klasickému zápisu grafických prvků (např. pomocí C#) dvě hlavní přednosti: 

Kód je přehlednější a čitelnější.



Právě díky XAML lze oddělit část grafickou od části výkonného kódu.

WPF se skládá ze sady základních knihoven, které tvoří dvě vrstvy: managed a unmanaged. Managed (neboli kontrolovaná) vrstva běží v .NET CLR a obsahuje knihovny pro základní (knihovna PresentationCore.dll) i pokročilejší (PresentationFramework.dll) práci s uživatelským rozhraním. Součástí této vrstvy je i knihovna WindowsBase.dll, která poskytuje základní objekty pro práci s WPF, jako jsou například DispatcherObject nebo DependencyObject. Unmanaged vrstva běží mimo CLR a programátoři s ní přímo nepracují. Její součástí je knihovna milcore.dll. Její plný název zní Media Integration Library Core a stará se o překlad vyšších WPF objektů (tlačítka, pole atd.) do struktur pro DirectX. Je tedy hlavním vykreslovacím nástrojem WPF. Unmanaged vrstvy obsahuje také knihovnu WindowsCodecs.dll, která se stará o převod obrázků do vektorové grafiky. Architektura WPF je znázorněna na obrázku 12.

28

Obrázek 12: Architektura WPF [6]

Technologii WPF byla zvolena kvůli výborným možnostem grafického návrhu a také proto, abych si rozšířil odbornost v tomto oboru. Ačkoliv bylo WPF vydáno již v roce 2006 pod názvem Avalon, tak jsem vzhledem ke svému zaměstnání, kde vývoj stále probíhá ve WinForms, neměl k využití této zajímavé technologie prostor. Velmi mne také láká průzkum možnosti striktního oddělení grafického rozhraní od samotné logiky.

Model-View-ViewModel Model-View-ViewModel (zkráceně MVVM) je návrhový vzor tvorby aplikací, často se používá právě ve spojistosti s WPF. Obě tyto technologie spolu tvoří mocný nástroj, který umožňuje vytvářet programy tak, aby byla pečlivě oddělena vrstva grafického návrhu od logiky. Tento přístup používají také vývojové týmy společnosti Microsoft, příkladem může být třeba aplikace Blend pro Visual Studio, která umožňuje grafický návrh WPF aplikací.

29

MVVM určuje princip rozdělení částí kódu do následujících tří vrstev: 1) Model – Obsahuje samotná data. Většinou ve formě objektů a struktur obsahujících například informace načtené ze zdroje dat. Může představovat třeba napojení na databázi. 2) View - Představuje samotné grafické rozhraní (GUI), tedy to, jak aplikace vypadá. Má za úkol prezentovat data z části Model uživateli v co nejvhodnější formě. Pro View se využívá značkovací jazyk XAML. 3) ViewModel – Umožňuje propojení View a Modelu. Může obsahovat metody a příkazy, které provedou případné změny nad daty, tedy Modelu. Tyto příkazy lze navázat a spouštět ve View například pomocí Bindingu. Výše popsaný vzor lze popsat diagramem viz obrázek 13.

Obrázek 13: Návrhový vzor MVVM

Oddělení grafické a logické části programu je vhodné i pro automatické testování logiky vzniklé aplikace, například pomocí Unit testování. I to je jeden z důvodů, proč bylo rozhodnuto tento návrhový vzor použít. Za předpokladu dalších úprav a rozšiřování programu bude již vhodné takové testování provádět, především v případě, že by se rozšiřoval počet uživatelů. Programování s dodržením MVVM má kromě zmíněných výhod i své nevýhody. Například při psaní této práce jsem se setkal se situací, kdy je potřeba v aplikaci otevřít podřízené okno. Jak ale otevřít okno z části programu (ViewModel), která nemá vědět o grafickém rozhraní? Řešení tohoto problému je vysvětleno níže v kapitole 4.4, ale v porovnání s klasickým přístupem bez MVVM je příliš komplikované a šroubované.

30

Client – Interface – Server V aplikaci je použito vzoru Client – Interface – Server (CIS), který je obdobou síťové architektury Klient – Server s tou modifikací, že je využito ještě vrstvy Interface (česky rozhraní), která představuje most mezi jednotlivými vrstvami. Architektury Client – Interface - Server se využívá především u databázových aplikací, u kterých je potřeba udržovat jednu centrální databázi. Tento návrh tedy obnáší rozvrstvení aplikační logiky mezi jednotlivé vrstvy tak, aby program bylo možno využívat například na aplikačním serveru nebo na stanicích a zařízeních, které nebudou mít spojení s databází (toho je možno docílit pomocí webových služeb). Rozložení je znázorněno na obrázku 14.

Obrázek 14: Architektura Client – Interface – Server

Server je vrstva, která má přímé spojení centrálním zdrojem dat, nejčastěji relační databází. Představuje pouze základní napojení, tedy sběr a ukládání dat. Interface je rozhraní učující jaké vlastnosti mají být společné pro komunikující vrstvy. Nejčastěji určuje metody, které slouží pro operace s daty uloženými v databázi. Client pak nejčastěji představuje logické seskupení dat do objektů a povolené operace nad nimi, které jsou společné pro jednotlivé typy koncových aplikací (desktop aplikace, mobilní aplikace a jiné). V terminologii MVVM tyto vrstvy dohromady tvoří Model, tedy základní datovou strukturu aplikace. Poskytují tak podklad pro tvorbu ViewModelu a následné prezentaci koncovému uživateli. Tento model byl zvolen z důvodu výhledu do budoucna, kdy je

31

možno celé řešení programu Domácí účetnictví rozšířit o systém webových služeb a naprogramování také webové nebo mobilní aplikace.

Microsoft SQL Server Compact Edition 4.0 Microsoft SQL Server Compact Edition 4.0 je embedded databáze a je tedy určena především pro menší webové i desktop aplikace. Je postavena na stejném API jako ostatní série typu Microsoft SQL Server. [7] Důvody zvolení tohoto typu databáze pro program Domácí účetnictví a zároveň jejími hlavními přednostmi jsou: 

Snadný přístup pomocí .NET Framework 4.0, včetně ADO.NET.



Je využitelná jako 32bitová i 64bitová verze.



Malá velikost a přenositelnost. Celá databáze je uložena do jediného souboru, který je velmi malý, roste až s přibývajícím množstvím dat. Je možno přenášet databázi s aplikací nebo provádět její zálohy.



Většinová kompatibilita s velkými Microsoft SQL Servery.



Volně dostupný a šiřitelný databázový stroj.



Lze využít private deployment – není potřeba instalace, postačí pouze kopírování příslušných knihoven spolu s aplikací, která databázi využívá.



Velmi dobrá rychlost – databáze je nahrána v paměti a přístup k ní pomocí dotazů je tak velmi rychlý

Jako ostatní embedded databáze má i SQL Server CE svá omezení. Jedním z nejvýraznějších je nemožnost vytváření příkazů SELECT s vnořenými dotazy, takzvanými subselecty. Toto však lze velmi snadno obejít použitím spojení tabulek – JOIN. Během práce se pak další omezení neprojevila.

Tesseract OCR Jedná se o open source projekt zaměřený na optické rozpoznání znaků (OCR). OCR je proces, při kterém dochází k převodu tištěných nebo psaných textů v listinné podobě do podoby digitální. Digitální podoba pak obsahuje rozpoznaný text, ve kterém lze strojově 32

vyhledávat. Program provádějící rozpoznání znaků se řídí předdefinovanými strukturami znaků a na jejich základě přiřadí části obrázku odpovídající znak. V dnešní době existuje mnoho pokročilých nástrojů, které umí zpracovat téměř jakýkoliv jazyk a font, mnohdy i ručně psané písmo zcela automaticky. Někdy je potřeba OCR nástroji napovědět, co daný kus obrázku znamená, čímž se provede jeho trénink. Jak nejčastěji probíhá proces rozpoznání znaků je znázorněno na obrázku 15.

Obrázek 15: Proces OCR [8]

S vývojem Tesseract začala společnost Hewlett Packard už v roce 1985. V roce 2005 pak byl uvolněn jako open source a o rok později ho převzala společnost Google. Již tyto informace slibují, že se bude jednat o velmi pokročilý a kvalitní nástroj. Už jen značná vývojářská komunita okolo tohoto software je vhodným doporučením pro jeho využití na projektu. Díky tomu je také dostupno mnoho tzv. natrénovaných jazykových souborů, které umožňují použít Tesseract také pro specifické znakové a slovní sady, mezi kterými nechybí čeština. Tesseract OCR je dostupný pod licencí Apache 2.0, která umožňuje i jeho zapojení do komerčního projektu. Tento software je připraven pro operační systém Linux, Windows i Mac OS X, je samozřejmě možné ho přeložit i pro jiné platformy. Je určen pro práci přes příkazový řádek, existuje i několik projektů třetích stran, které poskytují grafické rozhraní, například SunnyPage OCR.

ITextSharp ITextSharp je open source projekt, který se zaměřuje na práci se soubory ve formátu PDF. Pomocí této knihovny lze vytvářet a upravovat soubory PDF. Jedná se pravděpodobně o nejvyužívanější volně dostupný produkt pro tyto účely a jelikož je 33

tento projekt realizován pro platformu .NET, bylo rozhodnuto ho použít pro tvorbu PDF z jednotlivých entit, jako jsou doklad či nabídka. ITextSharp je v aktuální veřejně dostupné verzi 5 poskytován pod licencí Affero General Public License, která nedovoluje jeho komerční využití. Starší verze, konkrétně do verze 4, jsou však vázány jinou licencí - GNU Lesser General Public License (LGPL), která komerční využití povoluje. Verze napojené knihovny iTextSharp bude nejvyšší dostupná k aktuálnímu datu, ale v případě potřeby a rozšíření programu Domácí účetnictví je možno napojit starší verzi. Dle testování na stejném projektu jsou tyto knihovny kompatibilní, alespoň co se týká kódového zápisu v jazyku C#.

4.2 Souborová struktura aplikace Aplikace se skládá z množství vlastních knihoven i knihoven třetích stran. Jelikož je aplikace plánována v tzv. portable formě, tedy má být přenositelná na paměťovém médiu, její distribuce se provádí bez instalačního balíčku. Přesto je nutné vyřešit přítomnost všech potřebných součástí aplikace, včetně softwarových komponent Microsoft .NET Framework 4.0, Tesseract OCR a Microsoft SQL Server Compact Edition 4.0. Toto programové vybavení musí být vždy přítomno na stanici, ze které se program Domácí účetnictví spouští. Proto jsou instalační balíky kompatibilních verzí těchto komponent distribuovány společně s aplikací. Jejich případnou instalaci obstará program Instalace programu Domácí účetnictví.

Instalátor Vzhledem k množství komponent, které aplikace potřebuje ke svému běhu, byl vytvořen jednoduchý instalační program Instalace programu Domácí účetnictví. Je napsán rovněž pro platformu .NET, ovšem pro verzi 2.0. To z toho důvodu, aby bylo možno instalační program spustit i na operačním systému Microsoft Windows se starší verzí .NET Framework. Nejnižší verzí Windows, ve které lze instalátor spustit, je Windows XP, která již v základní konfiguraci obsahuje instalaci .NET Framework 2.0. Instalátor je napsán pomocí technologie WinForms, jelikož .NET 2.0 neobsahuje WPF. Program instalátoru nejprve nabídne přijmutí licenčních podmínek a poté zkontroluje přítomnost požadované verze .NET (4.0 a vyšší), databázového stroje Microsoft SQL Server Compact a Tesseract OCR. V případě, že některou komponentu nenalezne, oznámí to uživateli a začne instalovat. Pokud není přítomen SQL Server CE nebo 34

Tesseract, provede se private instalace do adresáře aplikace. Zobrazení instalovaných komponent lze vidět na obrázku 16.

Obrázek 16: Ukázka z programu instalátoru

Všechny potřebné komponenty jsou vloženy do instalačního balíku jako zabudované zdroje (embedded resource) v podobě archivů zip nebo instalačního soubor. Je to z toho důvodu, aby pro instalaci stačil pouze jeden soubor a nemusela se distribuovat rozsáhlá instalační sada, která by obsahoval množství souborů. Tato cesta je dobrá hlavně kvůli možnosti stažení instalačního souboru z webového úložiště, aby uživatel nebyl nucen stahovat více balíčků nebo stažený soubor rozbalovat. Jelikož je instalátor psaný pro .NET 2.0 a nebylo tak možno využít systémových knihoven System.IO.Packing, jejich rozbalení provede nástroj třetí strany SharpZipLib.

Rozdělení do assembly Výsledný program Domácí účetnictví se skládá jak z knihoven třetích stran, které jsou popsány výše, tak také z šesti knihoven vlastní výroby. Jedná se o knihovny samotného jádra programu, které jsou rozděleny podle výše popsané CIS (Client-Interface-Server) architektury

na

HomeAccountant.Client.dll

(klientská

část

aplikační

logiky),

HomeAccountant.Interface.dll (rozhraní) a HomeAccountant.Server.dll (serverová část aplikační logiky), dále pak samotný spouštěcí soubor aplikace HomeAccountant.exe. 35

Obecné funkčnosti jako práce s databází, PDF, vhodné WPF objekty a další jsou sdruženy v knihovnách HaalaUtilities.dll a HaalaWpfUtilities.dll.

4.3 Rozbor hlavních funkčností programu Tato podkapitola se bude zabývat vysvětlením nejdůležitějších a nejzajímavějších částí programu z hlediska programátora, nemusí se tedy krýt s nejzajímavějšími prvky z hlediska uživatele. Ty sice mnohdy bývají velmi viditelné (především grafické prvky), ale nemusejí být až tak zajímavé pro tvůrce aplikace. Vzhledem k rozsáhlosti projektu pak nelze rozebírat všechny použité třídy nebo implementované funkce.

Databázový objekt Jak již bylo uvedeno, základ programu je vytvořen tak, aby bylo možné bez větších obtíží použít odlišné databázové stroje. Mohou to být jak klasické serverové nástroje, tak také databáze typu embedded. Proto bylo nutno tento fakt brát v potaz při vytváření databázového objektu, který je použit pro práci těmito stroji. Celá funkčnost je zpracována v knihovně HaalaUtilities. Hierarchie použitých tříd je na obrázku 17.

Obrázek 17: Hierarchie tříd databázového objektu

36

Je tedy vytvořen základní objekt HaalaDatabaseBase, který zaštiťuje všechny společné vlastnosti a metody relačních databází založených na jazyku SQL. Důraz byl kladen na to, aby veškeré databázové operace šlo provádět univerzálně. Například byl k účelu databázových dotazů a příkazů UPDATE vytvořen objekt SqlFilter. Tento objekt umožňuje automatické vytváření podmínky WHERE k zadanému SQL dotazu. [9] Pro zakládání nových a úpravu stávajících záznamů v databázi pak slouží speciální metody Update a Insert, které mají na vstupu vždy celý řádek. Tento řádek by pak měl v ideálním případě kopírovat strukturu dané tabulky. Výhodné je proto vytvářet typové datasety s typovými tabulkami. Samozřejmě u typových datasetů je obvykle vhodné i vytvořit si tabulku se sloupci, které nepříslušejí k dané tabulce (např. dotažené sloupce textového popisu z číselníkových tabulek). Pro tento případ je v metodách Update a Insert možnost nastavit předponu názvu sloupce, který do tabulky nepatří, s tímto je pak také potřeba počítat při vytváření typové tabulky. Tímto mechanismem lze docílit toho, že není potřeba psát zvláštní příkazy INSERT a UPDATE pro každou tabulku a přitom je možné mít tento proces plně pod kontrolou, na rozdíl od různých automatizovaných napojení na databázi, které jsou dostupné pro Visual Studio. Kvůli rozdílnému způsobu napojení na databázi a několika dalším odlišnostem klasických a embedded databází bylo potřeba vytvořit poděděné databázové objekty pro daný typ. Následně byl vytvořen hlavní ovládací objekt HaalaDatabase, který slučuje potřebné metody a podle zadaného typu databázové stroje rozhoduje o jejich provedení.

Objekty pro tvorbu podle MVVM Pro tvorbu aplikací podle vzoru Model-View-ViewModel je nezbytné připravit několik objektů tak, aby bylo možné správně propojit View s ViewModelem a ViewModel s Modelem. K tomu slouží především objekty s implementovaným rozhraním INotifyPropertyChanged, které umožňují hlásit změnu svých vlastností, a objekty implementující rozhraní ICommand, které mohou vystavovat sadu příkazů, které pak lze navázat ve View (UI). Dříve než bude uveden stručný popis těchto rozhraní, je potřeba zmínit vlastnost grafických prvků s názvem DataContext. Tato vlastnost nabízí možnost připojení datové struktury, v případě MVVM je to vrstva ViewModel. Pokud je DataContext elementu uveden, lze pak využít Binding – navázání vlastnosti datového objektu na 37

vlastnost

elementu

uživatelského

rozhraní.

Činnost,

kterou

při

provázání

uskutečňujeme, se nazývá bindování. INotifyPropertyChanged je rozhraní, které objektu dovoluje upozornit klienta (volající UI element) na změnu vlastnosti. Toto rozhraní existuje již od .NET verze 2.0, ale jeho pravý potenciál se podařilo naplnit až s příchodem WPF. Zde je totiž možno přímo propojit grafické elementy s daty, v našem případě tedy vlastnostmi ViewModelu. Na rozdíl od dřívějšího způsobu takového bindování využitého ve WinForms má právě ve WPF význam takový, že nejen vlastnost objektu má možnost upozornit na svou změnu příslušné grafické prvky, ale i naopak, to znamená, že v případě změny vlastnosti grafického elementu (typicky třeba formulářového pole) je automaticky provedena změna vlastnosti objektu. Ve WinForms bylo nutno nejprve odchytit správnou událost (např. změnu textu na textovém políčku) a teprve poté provést samotnou změnu vlastnosti objektu [10]. Implementace rozhraní INotifyPropertyChanged v základních objektech aplikace je znázorněna na obrázku 18.

Obrázek 18: Hierarchie základních tříd implementujících INotifyPropertyChanged

38

Jako základní třída implementující toto rozhraní byla vytvořena NotifyObjectBase ve jmenném prostoru HaalaWpfUtilities. Jelikož se jedná o nejdůležitější třídu pro celou implementaci programu, je potřeba uvést její definici, která je v příkladu 1. public class NotifyObjectBase : INotifyPropertyChanged { /// <summary> /// Property changed event /// public event PropertyChangedEventHandler PropertyChanged; /// <summary> /// Notify property change /// /// <param name="propertyName">property name protected virtual void OnPropertyChanged(string propertyName) { PropertyChangedEventHandler handler = this.PropertyChanged; if (handler != null) { var e = new PropertyChangedEventArgs(propertyName); handler(this, e); } } }

Příklad 1: Definice třídy NotifyObjectBase

Program Domácí účetnictví obsahuje možnost vrácení (undo) a znovu provedení (redo) změn uskutečněných na jednotlivých objektech. Z hlediska programátora se jedná o objekty vrstvy Model. Proto bylo nutno vyvinout takový systém ohlašování změn, aby bylo možno tyto zachytávat, ukládat jejich historii a také je zpětně vyvolat (vrácení/znovu provedení změny). Za tímto účelem je vytvořena třída UndoableObject. Tato třída je potomkem NotifyObjectBase a umožňuje kromě vyhlášení změny vlastnosti ji také zaregistrovat do historie změn. Obsahuje totiž instanci třídy UndoRedoManager, která s historií pracuje – poskytuje metody na vložení a odebrání prvku. Prvkem je myšlena informace o tom, která vlastnost kterého objektu byla změněna,

tedy

její

starou

a

novou

hodnotu.

Tyto

informace

nese

třída

UndoableProperty, která také obsahuje nejzajímavější výkonné metody Undo a Redo, které provádějí požadované akce nad instancí objektu, jehož vlastnosti se to týká. Změna vlastností probíhá pomocí metody SetValue ze třídy PropertyInfo ze jmenného prostoru System.Reflection, jak je uvedeno v příkladu 2.

39

public void Undo() { m_oInstance.GetType().GetProperty(m_sPropertyName). SetValue(m_oInstance, m_oOldValue, null); }

Příklad 2: Nastavení vlastnosti pomocí System.Reflection

Kvůli

možnosti

uložení

jednotlivých

entit

byla

vytvořena

abstraktní

třída

SaveableObject, která je potomkem UndoableObject. Potomci třídy SaveableObject mají povinnost umožnit uložení objektu a také validace hodnot v ní uložených, protože implementuje níže popsané rozhraní IDataErrorInfo [11]. Napojení tohoto rozhraní na bindovaném objektu zaručí zobrazení případné chyby vstupu uživateli. Blíže o tomto rozhraní v souvislosti s validací uživatelských vstupů bude pojednáno v kapitole 4.4. ICommand je rozhraní, které má v terminologii MVVM význam hlavně pro propojení View a ViewModelu. Na množství akcí grafických prvků lze totiž navázat Commands (příkazy), pomocí nichž lze z objektu, který je připojen v DataContextu, vyvolat pomocí bindování uvedenou akci. Jako základní třída implementující rozhraní

ICommand je vytvořena třída

TransferCommand ve jmenném prostoru HaalaWpfUtilities. Využívá se na vrstvě ViewModel a pomáhá definici proveditelných akcí nad příslušným objektem. Všechny uživatelské interakce tak probíhají přes tuto třídu, případně její potomky. Toho lze dobře využít pro zachycení všech výjimek, které nastanou při provádění uživatelských akcí, jako jsou kliknutí na tlačítko. Proto vznikla třída HATransferCommand, která je právě potomkem TransferCommand a díky přetížení hlavní výkonné metody ICommand.Execute

dojde

k odchycení

případné

výjimky a

k

její

obsluze.

TransferCommand je tedy jednou z hlavních tříd celého řešení. Další velmi dobře využitelnou třídou ze systémových knihoven je generický seznam ObservableCollection. Tato kolekce umožňuje sledovat její změny v případě přidání prvků, odebrání prvků nebo změny celého seznamu. Co však již tato třída neřeší, a z principu obecnosti ani nemůže, je situace, kdy dojde ke změně vlastnosti některého

z jejích

prvků.

Proto

jsem

jako

její

rozšíření

vytvořil

ExtendedObservableCollection, jejímiž prvky jsou objekty implementující rozhraní INotifyPropertyChanged. Rozšíření spočívá v tom, že se sledují změny vlastností na prvcích a na jejich základě je vyhlášena změna samotné kolekce. Tento 40

způsob dokáže velmi zjednodušit práci se seznamy na úrovni UI, které je potřeba občerstvit při jakékoliv změně jejich prvků. Této vlastnosti je využito například na seznamu dokladů, kdy při editaci dokladu dojde automaticky k občerstvení seznamu. Jako základ pro objekty pracující na vrstvě ViewModel je vytvořena třída ViewModelBase ve jmenném prostoru HomeAccountat.ViewModel. Tato třída dává možnost všem svým potomkům přistoupit do kontextu aplikace a také definuje důležité příkazy na zavření grafického elementu, se kterým se příslušný ViewModel spojen. Toto zavření je pak použito v rámci grafických prvků, které představují okna nebo záložky v prvku TabControl. Obecně takovéto ovládání grafických prvků může ve WPF s MVVM způsobit potíže, proto bude nyní rozepsáno, jaký postup byl při jeho implementaci zvolen. Jelikož způsoby zavírání grafických prvků jsou rozličné a Command lze navázat k libovolným akcím proveditelným z UI, musí se navázání provést obecně. Toho je docíleno vytvořením příkazu ve ViewModelu s názvem CloseCommand a vytvořením události RequestClose, která oznámí jeho zavření. CloseCommand pak vykoná vyvolání dané události, kterou lze odchytávat v libovolném místě, což se zpravidla děje v nadřízeném ViewModelu. Tam většinou dojde k tomu, že zavřený ViewModel je odebrán z kolekce zobrazených objektů, kolekce tuto změnu oznámí UI a to se překreslí již bez zavřeného elementu. Drobnou úpravou lze docílit i vrácení výsledku zavřeného okna (Ano, Ne, Zrušit atd.), stačí pouze rozšířit portfolio příkazů na ViewModelu o další, které představují právě dané akce. Dalším důležitým objektem je MainViewModel. Jak již jeho název napovídá, jedná se o hlavní ViewModel, který se používá pro hlavní okno aplikace. Obsahuje tedy velké množství proveditelných příkazů a povolení je provést. Jsou to ty, které lze vidět při startu aplikace. Tím ale v podstatě jeho práce končí, o další se pak starají již ViewModely ostatních objektů, jako jsou například InvoiceViewModel (faktury a doklady), InvoiceListViewModel (seznam faktur a dokladů), OfferSearchViewModel (hledání nabídek) a další. Mezi zajímavé příkazy patří již zmiňovaná možnost vrácení změn, možnost uložení aktuálně zobrazeného ViewModelu nebo přecházení mezi jednotlivými zobrazenými ViewModely pomocí historie procházení.

41

Ukládání souborů Aplikace umožňuje ukládat elektronické soubory na FTP. K tomu programově slouží třída HaalaFtp. Tu lze konfigurovat pro připojení na libovolný FTP server a je možno se připojovat i pomocí jména a hesla. Samotné ukládání je řešeno pomocí třídy System.Net.FtpWebRequest. Soubory jsou na server ukládány pod unikátními názvy, které jsou generovány pomocí třídy Guid. Tyto názvy jsou uloženy do databáze a následně je možno odkazem na ně soubor stáhnout zpět na klienta. Soubory lze v základní verzi programu vkládat k objektům faktura, nabídka a zakázka, ale

lze

je

vkládat

v podstatě

k libovolné

entitě,

která

je

uvedena

v databázové číselníkové tabulce Entity. Na přání zákazníka tak lze velmi snadno aplikaci obohatit o uložení souboru například k subjektu nebo k dalším entitám. Objekt na vrstvě MVVM Model, který může takto k sobě soubory ukládat, lze velmi jednoduše upravit tak, že bude implementovat rozhraní ICanContainFiles, a bude moci tuto vlastnost používat, jelikož hlavní MainViewModel ukládá soubory právě přes metody tohoto rozhraní.

Rozpoznání textu pomocí OCR Jednou z nejzajímavějších a nejpokročilejších funkcí programu je rozpoznání textu pomocí OCR nástroje Tesseract. Ten jako takový je velmi vyspělý s rozšířenou komunitou vývojářů a uživatelů. Navíc disponuje rozhraním pro spouštění přes příkazový řádek a samotné jeho napojení v programu je tak jednoduché. Ukázka příkazu, kterým lze provést OCR nad obrázkem, je uveden v příkladu 3. Tesseract.exe vstupni_obrazek.png vystupni_hocr –l ces hocr Příklad 3: Příkaz pro spuštění rozpoznání znaků pomocí Tesseract OCR

V této ukázce je nad vstupním souborem vstupni_obrazek.png provedeno OCR, parametrem –l je řečeno, že jazykem dokumentu je čeština (hodnota ces) a výstupem je formát hocr do souboru vystupni_hocr. Aby bylo dosaženo co možná nejlepších výsledků, je potřeba mít zdrojový obrázek v rozlišení alespoň 300 DPI. Pokročilejší komerční OCR nástroje umí pracovat i s horší kvalitou oskenovaného textu, Tesseract bohužel zatím ne. Samozřejmě je také vhodné 42

pro skenování používat co nejlepší možný skener, například ruční varianta rozhodně není dobrou volbou. Výstup a zpracování výsledků se však ukázaly mnohem obtížnějšími, přesně podle předpokladů z počáteční analýzy této práce.

Výstup OCR Jako výstup z Tesseract byl zvolen obecný formát hOCR. Jedná se o soubor formátu HTML, který popisuje, jaké znaky a na jakých pozicích v dokumentu byly nalezeny. Úryvek z takového souboru je uveden v příkladu 4.

<span class='ocr_line' id='line_27' title="bbox 267 614 720 687"><span class='ocrx_word' id='word_74' title="bbox 267 614 720 687">Rozpoznáno

Příklad 4: Ukázka části souboru

V ukázce jsou uvedeny hlavní informace, které může hOCR poskytnout. V Př. 4 je potřeba se zaměřit především na element span, který má vlastnost class na hodnotu ocrx_word. Tento element nese informace o rozpoznaném slovu. Údaj zapsaný ve vlastnosti title pak udává, v jakém umístění se slovo nachází. Umístění je v hOCR dáno pomocí bboxů, které jsou popsány dvěma body [12], viz obrázek 19.

Obrázek 19: Specifikace bbox v hOCR

43

Již zpracování takového výstupu není triviální záležitostí, proto byla vytvořena třída na jeho zpracování s názvem HOCRParser ve jmenném prostoru HaalaUtilities. Ta má za úkol rozebrat HTML kód a vytvořit z něj datovou strukturu. Za účelem práce s HTML je využito knihovny HtmlAgilityPack.dll, která je licencována pod Microsoft Public License (Ms-PL), je tedy povoleno i její komerční použití. Z datové struktury jsou pak nejzajímavější právě objekty BBox. Z výsledných objektů je pak vytvořena mozaika z rozpoznaného textu, která je umístěna na obrázek originální oskenované faktury k nahlédnutí uživateli. Z tohoto obrázku si pak může jednoduše tažením myší přetáhnout potřebné položky do formulářových polí.

Rozbor výstupu V momentu, kdy je doklad oskenován, provedeno rozpoznání znaků a jeho výsledek je uložen v datových strukturách, nastává snad ještě složitější úkol – je potřeba ze získaných dat zpětně sestavit doklad a uložit ho do databáze. Jak již bylo rozebráno v analýze v kapitole 3.2, možnost automatického sestavení dokladu je velmi složitá a časově náročná práce, vyžaduje analýzu mnoha druhů faktur a podrobné testování. Ani tak nikdy nebude možné 100% zaručit, že získaná data jsou správná a budou potřebovat kontrolu od uživatele. Proto v současném stavu projektu Domácí účetnictví není přikročeno k plné automatizaci, ale je uživateli poskytnuta alespoň částečná pomoc v podobě možnosti přetažení dat z oskenovaného dokladu do formuláře. Vedle formuláře dokladu je zobrazen vytažený text a po najetí myší se uživateli zobrazí slova, které lze přetáhnout na formulář. Způsob této práce je vyznačen na obrázku 20.

44

Obrázek 20: Přetažení OCR textu do formuláře

Automatické skenování Uživateli je umožněno nejen vložení faktury z obrázku, ale také automatizovaně přes skener, který se obsluhuje přímo z kódu. To je výhodné z toho pohledu, že je možné nastavit možnosti skenování (např. DPI) tak, aby bylo možno kvalitně rozebrat vzniklý obrázek pomocí OCR nástroje. Přístup ke skenovacímu zařízení probíhá přes Windows obecné rozhraní pro obrazová vstupně-výstupní zařízení (skenery, kamery) s názvem Windows Image Acquisition (WIA). Toto rozhraní obsahuje sadu několika metod, pomocí kterých lze ovládat ta zařízení, která jsou s WIA kompatibilní. Přistupovat k těmto metodám lze po přídání odkazu (reference) ve Visual Studiu na knihovnu COM s názvem Microsoft Windows Image Acquisition Library v2.0. [13] Důležitá je především metoda set_Value(ref object pvResult) na instanci objektu WIA.Property, která umožňuje nastavení libovolné hodnoty požadovaného nastavení skeneru. Využil jsem hlavně vlastností, které zásadním způsobem ovlivňují kvalitu výsledku – DPI, světlost, kontrast a barevný mód.

45

Tvorba PDF Pro vytváření PDF z dokladů, nabídek a potenciálně z libovolných entit byl vybrán nástroj iTextSharp. Ten umožňuje tvorbu PDF jak ve zjednodušené podobě (postupné vkládání textu po řádcích), tak také v o něco složitější, která však disponuje pokročilejšími možnostmi psaní a úprav PDF (přesné pozicování textu). Aby bylo možno mít v kódu téměř vše plně pod kontrolou, byla vybrána druhá možnost. Ta obsahuje použití třídy PdfContentByte [14]. Funkčnost pro tvorbu PDF je zapracována ve třídě HaalaPdfWriter ve jmenném prostoru Haala.Utilities. Ukázka hlavní metody, která zapíše libovolný text s použitím zvoleného fontu na určenou pozici je v příkladu 5. public static void WriteText(PdfContentByte cb, string text, int x, int y, BaseFont font, int size) { cb.SetFontAndSize(font, size); cb.ShowTextAligned(PdfContentByte.ALIGN_LEFT, text, x, y, 0); }

Příklad 5: Metoda pro vložení textu do PDF pomocí PdfContentByte

Do budoucna by mohla být do programu zapracována možnost tvorby PDF podle sestav, tedy například jiného PDF pro doklady přiřazené k zakázce A a jiného PDF přiřazeného k zakázce B. Zřejmě by šlo využít i jakéhosi návrháře sestav pomocí ovládacího prvku, kde by bylo možno přesouvat jednotlivá pole (odběratel, dodavatel, položky atd.). Jejich pozice by se následně ukládala do databáze.

Tisk z aplikace Tisk vybrané entity probíhá tak, že je z ní nejprve vytvořeno PDF a to je odesláno na výchozí tiskárnu. Toto by se dalo realizovat i napřímo bez tvorby dočasného PDF, ale tento způsob byl zvolen proto, že bude společný a exportované PDF bude stejné jako vytištěný dokument. Tisk bude proveden pomocí výchozí tiskárny a jejího výchozího nastavení, odpadne tedy další uživatelská interakce při výběru tiskárny, nastavení tisku atd. Celá akce je provedena vytvořením procesu (System.Diagnostics.Process) tak, aby byl systému předán požadavek na tisk (je potřeba nastavit vlastnost Verb v ProcessStartInfo na

46

hodnotu „print“). Systém sám dohledá aplikaci, která je k danému souboru uvedena jako možnost pro tisk a provede vytisknutí pomocí výchozí tiskárny.

Vyhledávání v datech aplikace V aplikaci je uživateli umožněno hledání dokladů, faktur, nabídek a zakázek na základě předdefinovaných možností filtrování. Tento systém filtrování je psán obecně pro celou aplikaci, je možno přidávat další předdefinované filtry pouhými databázovými příkazy, není tedy potřeba měnit kód aplikace. Je tedy zřejmé, že hlavní částí vyhledávání je databáze, popis příslušných entit je v kapitole 3.3. Ve View pak proběhne samotné zobrazení filtrů, které je díky databázovému návrhu jednotné – je vytvořen pouze jeden grafický prvek - SearchControl, který obsluhuje filtrování pro všechny entity. Nutné je pouze vytvořit příslušný ViewModel (pro hledání faktury, hledání nabídky atd.). Na základě jeho typu se pomocí nastaveného DataTemplate rozhodne, že se zobrazí prvek SearchControl. SearchControl umožňuje jak práci s filtry (jejich přidávání, úpravu a odebírání), tak také práci se šablonami uložených filtrů, jak lze vidět na obrázku 21.

Obrázek 21: Dynamické filtrování

ViewModel musí prvku SearchControl poskytnout sadu přednastavených filtrů z databázové tabulky Filtry. Ten pak sám rozhoduje, jaké operátory bude zobrazovat pro jednotlivé definované filtry.

4.4 Grafické rozhraní V této kapitole bude na několika příkladech ukázáno, jak probíhá praktický vývoj aplikací ve WPF s dodržením MVVM. Budou odhaleny výhody a nevýhody takového řešení. Při navazování vrstvy View na ViewModel nebylo použito žádného toolkitu proto, aby bylo možno pracovat s čistým kódem a všechny vlastnosti programování na

47

platformě WPF podle MVVM se tak mohly řádně vyzkoušet. Uživatelské rozhraní je zpracováno podle návrhu z kapitoly 3.4.

Přihlašovací okno Přihlašovací okno, podobně jako ostatní okna, která je nutno z aplikace WPF psané podle vzoru MVVM otevírat, je dobrým příkladem, jak striktní dodržení tohoto principu může být mnohdy nepraktické a dokonce až na obtíž. Podle MVVM totiž nelze vytvářet instance okna přímo ve ViewModelu – ViewModel by se měl starat pouze o vytváření dalších ViewModelů. Nejdříve je ukázáno v příkladu 6, jak lze otevřít okno jednoduše ve WinForms včetně získání jeho výsledku. LoginForm l_oForm = new LoginForm(l_oCols); if (l_oForm.ShowDialog() == DialogResult.OK) {

…

}

Příklad 6: Otevření okna ve WinForms

Nyní je uvedeno, jak je řešeno v projektu Domácí účetnictví při maximální snaze dodržet principy MVVM. Složitost tohoto řešení oproti výše uvedeným dvěma řádkům kódu pro vytvoření okna ve WinForms dokazuje, že obecně práce s okny ve WPF ve spojitosti s MVVM není snadnou záležitostí. Jednak je použit speciální příkaz (Command) pro otevření okna. Příkaz je v programu vytvořen jako třída OpenWindowCommand (potomek TransferCommand) ve jmenném prostoru HaalaWpfUtilities. Tento příkaz umožňuje dynamické vytvoření okna (jeho typ je T) na základě předání příslušného WindowViewModelu. WindowViewModel je třída, která poskytuje základ pro všechny ViewModely, které mají představovat okna. Mimo jiné obsahuje několik událostí, které simulují výstupní hodnoty oken, tak jak je známe z WinForms – zavření okna, stisknutí Ok, Ne a Zrušit. Právě událost zavření okna musí být odchycena v OpenWindowCommand, aby bylo možné dynamicky vytvořené okno na základě WindowViewModelu zavřít. Toto řešení je vhodné i pro jiná okna, která jsou plně závislá na svém ViewModelu. Okno přihlášení je ještě specifičtější v tom, že v době jeho vytváření neexistuje zatím žádné jiné rodičovské okno (není vykresleno) a dostupný je tak pouze nadřízený ViewModel. Jiné řešení než výše uvedené se tedy nenabízí.

48

Další zajímavou vlastností okna pro přihlášení je zobrazení textu v políčku, které nabádá uživatele zadat hodnotu do tohoto políčka. Takovému textu se říká watermark. Jeho využití v přihlašovacím dialogu je na obrázku 22.

Obrázek 22: Přihlašovací dialog

Požadovaného výsledku je dosaženo využitím dvojice textových polí, jednoho pro zobrazení watermark a druhého pro vlastní uživatelský vstup, přičemž oba vzájemně interagují pomocí vícenásobného bindingu. Na jeho základě se skrývá nebo zobrazuje políčko s watermark. Tento postup je v příkladu 7. <MultiBinding Converter="{StaticResource TextInputToVisibilityConverter}">

Příklad 7: Zobrazení watermark

49

Prvek pro zobrazení OCR Postup zobrazování jednotlivých ViewModelů v rámci programu Domácí účetnictví a také ve většině WPF aplikací lze dobře demonstrovat na prvku pro zobrazení textu získaného pomocí OCR. V podstatě se využívá jakéhosi mapování ViewModelu na View. Toho lze docílit velmi snadno použitím DataTemplate. Nejprve je v příklad 8 uvedeno, jak lze takové mapování napsat. ...

Příklad 8: Zápis mapování objektu pomocí DataTemplate

Tento zápis v podstatě říká, že kdykoliv se objeví bindovaný objekt hWord ze jmenného prostoru hocr, je v UI zobrazen v podobě prvku DragThumb. V implementaci prvku pro zobrazení OCR textu je využito jedné ze základních grafických komponent WPF s názvem ItemsControl, která umožnuje zobrazovat libovolné prvky. Celý zápis zobrazení OCR textu je v příkladu 9. <Style> <Setter Property="Canvas.Left" Value="{Binding BBox.Left}"/> <Setter Property="Canvas.Top" Value="{Binding BBox.Top}"/>

Příklad 9: Konstrukce pro zobrazení OCR textu

50

Jako podklad je použit originální obrázek, aby se uživatel mohl lépe orientovat. Poté v podstatě stačí uvést, jaké prvky se budou zobrazovat, v našem případě to jsou HWords. Jako kontejner pro prvky je zvolen Canvas, který umožní zobrazení prvků na zvolených pozicích pomocí bindování, zde na BBox.Left a BBox.Top. Ostatní už obstará právě DataTemplate, jehož výseč je v Příklad 8. Pro ViewModely hWord vytvoří odpovídající grafické zobrazení, tedy prvek s možností přetažení myší. Výsledná podoba komponenty pro zobrazení OCR nad originálním obrázkem je na obrázku 14. V momentě, kdy je kód DataTemplate zapsán v globálním souboru se zdroji aplikace (standardně GlobalResources.resx), bude stejný ViewModel zobrazen stejně ve všech částech aplikace.

Validace uživatelského vstupu Velmi důležitým prvkem každé aplikace je validace (kontrola) uživatelského vstupu. Ideálně by měl být uživatel informován okamžitě při každém zadání slova nebo kliknutím myši v případě, že provádí něco nestandardního nebo nesprávného. V aplikaci Domácí účetnictví je pro každý objekt, u kterého je vyžadována validace správnosti v něm uložených dat, naimplementováno rozhraní IDataErrorInfo ze jmenného prostoru System.ComponentModel. To zaručí propojení mezi View a příslušným ViewModel, který obaluje daný datový Model. K tomu slouží nastavení vlastnosti bindování s názvem ValidatesOnDataErrors na hodnotu True. Společně s nastavením další vlastnosti UpdateSourceTrigger na hodnotu PropertyChanged se zajístí, že Binding bude sledovat hodnotu vlastnosti Error, která náleží rozhraní IDataErrorInfo. Dále už záleží pouze na způsobu zobrazení. V programu je globálně použito ikony červeného kruhu s vykřičníkem, na kterém lze zobrazit nápovědu, viz obrázek 23.

Obrázek 23: Validace uživatelského vstupu

51

5 Návrh na další rozvoj aplikace Kromě již uvedených funkcionalit je samozřejmě v aplikaci prostor pro její další rozvoj. V této kapitole je uveden seznam možností dalšího vývoje funkcí, které nebyly obsahem této práce, ale uživatel pro ně však jistě najde uplatnění.

Dotažení procesu automatizace zadávání Jak již bylo popsáno v kapitole 4.3.4, celý proces rozpoznání textu z oskenovaných dokladů je složitý a zatím není dokončen. Zbývá doplnit automatické přiřazení textu rozpoznaného pomocí OCR nástroje do příslušných formulářových polí tak, aby uživatel nemusel nic přepisovat ani kopírovat. Tato vlastnost je z hlediska pracnosti nevíce náročná, nicméně v projektu je již pro tuto funkci připravena vlastní větev kódu.

Vytvoření systému webových služeb a mobilní aplikace V plánu rozvoje aplikace je vytvoření webových služeb operujících nad databázi. Bude tak možno vyrobit další modul aplikace například jako webovou stránku (nahlížení do databáze, online vytvoření nabídky a další) nebo jako aplikaci pro mobilní platformy (např. Android), která by umožnila např. zadání faktury do databáze pomocí internetu, kde by stačilo například dokument pouze nafotit mobilním telefonem a odeslat, příslušná data by se rozebrala pomocí OCR sama a uložila do databáze. Nebo by se uložil pouze elektronický soubor, který by byl pak určen k dalšímu zpracování, uživatel by mohl být pak případně upozorněn, že ještě nebyl zpracován. Sama aplikace pro mobilní telefon by pak mohla být vytvořena pro nejpoužívanější operační systém Android. Kromě ofocení a odeslání dokladu by pak měla umět i jejich dohledání z databáze na serveru a také zobrazení přímo v mobilním telefonu.

Systém automatických aktualizací Vzhledem k možnému rozšíření aplikace mezi větší množství uživatelů je potřeba zpracovat systém automatických aktualizací aplikace tak, aby bylo možno aplikaci v případě chyb nebo změn (autorských, legislativních a dalších) snadno aktualizovat z internetu. To by vyžadovalo vytvoření serveru přístupného z internetu a také kontroly ze strany aplikace, zda neexistují nové aktualizace.

52

Historie provedených akcí Jelikož se jedná o aplikaci účetního charakteru, bylo by vhodné do budoucna doplnit i ukládání historie všech provedených databázových akcí. Pro to by byla určena tabulka Historie, která je navržena tak, aby bylo možno zrekonstruovat jednotlivé operace a vrátit je zpět – ať už automaticky programově nebo ručním zásahem uživatele či administrátora. Navíc tato historizace je jakési „krytí“ uživatele i výrobce software před případnými stížnostmi, např. na ztrátu dat a podobně. Plnění historie by mohlo být prováděno jak aplikační logikou na úrovni kódu v .NET tak také pomocí uložených procedura na úrovni samotné databáze.

Napojení na externí systémy Zajímavou funkcí by mohlo být i napojení na externí systémy, některými z nich mohou být i konkurenční produkty popsané v kapitole 2.1. Napojení by bylo vhodné jak pro export, tak pro import dat. Ten by mohl probíhat například pomocí webových služeb nebo výměnou dat přes datové soubory (například .csv, .xls nebo .isdoc).

53

6 Závěr V této práci je zpracována analýza současného stavu na trhu. Tyto poznatky jsou konfrontovány s požadavky klienta na funkce a možnosti. Výsledným verdiktem je pak shoda na vytvoření nové aplikace. Na tomto základě je pak přistoupeno k návrhu budoucího programu. Požadavky zadavatele sice mohou na první pohled působit jednoduše, přesto několik z nich představuje komplexnější a složité řešení. Například návrh grafického rozhraní je úkol, se kterým se mnohdy neúspěšně potýkají i největší výrobci v oblasti software. Dalším problémem je maximalizace automatizace všech úkonů uživatele. Většiny lze poměrně dobře docílit vhodným návrhem báze dat a algoritmů. Zamýšleným prvkem automatizace procesů je však i optické rozpoznání znaků v oskenovaném dokumentu, což ani zdaleka není lehký úkol, který sám o sobě překračuje i meze bakalářské práce. Vytvořená aplikace se snaží o splnění těchto cílů v maximální možné míře. Až na dotažení procesu plné automatizace evidence již existujících dokladů jsou zapracovány. Na aplikaci podobného typu je její uživatelské rozhraní funkční a přehledné, subjektivně i intuitivní, i když nelze předpokládat téměř u žádného software, že každý jeho uživatel bude schopen s ním pracovat bez alespoň základního proškolení nebo manuálu. Kladen je důraz na co možná nejmenší složitost prováděných operací tak, aby uživatel nebyl zatěžován požadavky ze strany programu – potvrzování dialogů, různá nastavení – a práce byla rutinní (což se u evidence dokladů očekává). V programu je nejvíce viditelná právě ta funkčnost, u které se předpokládá, že se ji uživatel chystá provést (toto bylo nastaveno na základě požadavku zadavatele). Vývoj programu Domácí účetnictví pak splnil i učební – proniknutí do světa WPF a MVVM. Dle mého názoru je WPF nejzajímavější technologií pro vývoj grafických desktop aplikací, pokud se uváží rychlost vývoje a výsledný vzhled. Vzor MVVM je pak dobrou volbou převážně pro projekty, do kterých lze zapojit také grafické pracovníky s alespoň částečnou znalostí značkovacích jazyků. Pak je vhodné striktně odpojit grafické prvky od aplikační logiky. Své uplatnění však tento způsob návrhu najde jistě i u menších projektů. Proto lze WPF v kombinací s MVVM doporučit všem programátorům desktop aplikací.

54

Seznam použité literatury [1] KOSSE, Tim. FileZilla: The free FTP solution. FileZilla: The free FTP solution [online]. 2015 [cit. 2015-04-07]. Dostupné z: https://filezilla-project.org/ [2] Tesseract-ocr: An OCR Engine that was developed at HP Labs between 1985 and 1995... and now at Google. TESSERACT-OCR. Tesseract-ocr: An OCR Engine that was developed at HP Labs between 1985 and 1995... and now at Google. [online]. 2015 [cit. 2015-04-07]. Dostupné z: https://code.google.com/p/tesseractocr/ [3] HERCEG, Tomáš. DOTNETPORTAL.CZ: úvod do .net frameworku [online]. 3.4.2009 [cit. 2015-03-19]. Dostupné z: http://www.dotnetportal.cz/clanek/125/Uvod-do-NET-Frameworku [4] NASH, Trey. C# 2010 Rychlý průvodce novinkami a nejlepšími postupy. 1. vydání. Brno: Computer Press, a. s., 2010. ISBN 978-80-251-3034-6 [5] SharePoint & .NET Blogs: NET Framework Overview. BIJU, Joseph. SharePoint & .NET Blogs [online]. Bangalore, India, 2013, 6.12.2013 [cit. 2015-03-22]. Dostupné z: http://tech.just4sharing.com/Pages/tech/NET-FrameworkOverview.aspx [6] SUR, Abhishek. WPF Tutorial: Beginning. In: CODEPROJECT [online]. 2010, 28.12.2010

[cit.

2015-03-22].

Dostupné

z:

http://www.codeproject.com

/Articles/140611/WPF-Tutorial-Beginning [7] Microsoft: Download Center. MICROSOFT. Microsoft: Download Center [online]. 2015 [cit. 2015-04-07]. Dostupné z: http://www.microsoft.com/cs-cz/download/ details.aspx?id=17876 [8] IXTENT: OCR/ICR. IXTENT S.R.O. IXTENT [online]. 6.1.2015 [cit. 2015-04-16]. Dostupné z: http://www.ixtent.com/cs/produkty-a-reseni/digitalizace-a-ocr-icr/ocricr.html [9] AGARWAL, V. – HUDDLESTON, J.. Databáze v C# 2008 Průvodce programátora. 1. vydání. Brno: Computer Press, a. s., 2009. ISBN 978-80-251-30346

55

[10] PETZOLD, Charles. Mistrovství ve Windows Presentation Foundation. Computer Press, a. s., 2008. ISBN 978-80-251-2141-2 [11] SHARP, John. Microsoft Visual C# 2008 Krok za krokem. 1. vydání. Brno: Computer Press, a. s., 2008. ISBN 978-80-251-2027-9 [12] BREUEL, Thomas. The hOCR Embedded OCR Workflow and Output Format. The hOCR Embedded OCR Workflow and Output Format. 2007 [13] Windows Image Acquisition (WIA). MICROSOFT. Windows Image Acquisition (WIA) [online].

2015

[cit.

2015-04-07].

Dostupné

z:

https://msdn.microsoft.com/enus/library/windows/desktop/ms630368%28v=vs.85%29.aspx [14] Creating PDF documents with iTextSharp. KOCH, Thomas Michael. Creating PDF documents with iTextSharp [online]. 2011 [cit. 2015-04-07]. Dostupné z: http://www.codeproject.com/Articles/277065/Creating-PDF-documents-withiTextSharp

56

Seznam obrázků Obrázek 1: Ukázka z programu Duel ............................................................................. 10 Obrázek 2: Ukázka z programu Samostatná fakturace ................................................... 12 Obrázek 3: Návrh podoby nové aplikace ........................................................................ 14 Obrázek 4: Proces automatizace zadávání dokladů ........................................................ 17 Obrázek 5: Výstup z programu v podobě PDF ............................................................... 20 Obrázek 6: Struktura hlavního okna ............................................................................... 23 Obrázek 7: Rozšířený rámec aplikace ............................................................................ 23 Obrázek 8: Pás karet ....................................................................................................... 24 Obrázek 9: Ukázka skrytí nadbytečné akce .................................................................... 24 Obrázek 10: Pracovní plocha .......................................................................................... 25 Obrázek 11: Architektura .NET ...................................................................................... 27 Obrázek 12: Architektura WPF ...................................................................................... 29 Obrázek 13: Návrhový vzor MVVM .............................................................................. 30 Obrázek 14: Architektura Client – Interface - Server ..................................................... 31 Obrázek 15: Proces OCR ............................................................................................... 33 Obrázek 16: Ukázka z programu instalátoru .................................................................. 35 Obrázek 17: Hierarchie tříd databázového objektu ........................................................ 36 Obrázek 18: Hierarchie základních tříd implementujících INotifyPropertyChanged .... 38 Obrázek 19: Specifikace bbox v hOCR .......................................................................... 43 Obrázek 20: Přetažení OCR textu do formuláře ............................................................. 45 Obrázek 21: Dynamické filtrování ................................................................................. 47 Obrázek 22: Přihlašovací dialog ..................................................................................... 49 Obrázek 23: Validace uživatelského vstupu ................................................................... 51

57

Seznam použitých zkratek ADO.NET

ActiveX Data Object pro .NET - skládá se z objektů COM pro přístup k datovým zdrojům

CIS

Architektura Client – Interface - Server

CLR

Common Language Runtime – běhové prostředí pro .NET aplikace

CLS

Common Language Specification – sada pravidel pro jazyky

COM

Component Object Model – rozhraní Windows pro komunikaci mezi procesy a napříč programovacími jazyky

DPI

Dots per inch – hustota rozložení pixelů na velikost jednoho palce

DPH

Daň z přidané hodnoty

FTP

File Transfer Protocol – protokol pro přenos souborů mezi počítači

GDI

Graphics Device Interface – Microsoft komponenta pro zobrazování grafických objektů

GUI

Graphical User Interface - grafické uživatelské rozhraní

MSIL

Microsoft Intermediate Language – přechodový jazyk .NET aplikací

MVVM

Model-View-ViewModel – návrhový vzor pro tvorbu aplikací

OCR

Optical Character Recognition – metoda optického rozpoznání znaků

PDF

Portable Document Format – přenosný formát souboru

SQL

Structured Query Language – strukturovaný dotazovací jazyk pro práci s daty v relačních databázích

UI

User Interface - Uživatelské rozhraní

WIA

Windows Image Acquisition – rozhraní pro práci se vstupními zařízeními jako skener, fotoaparát a další

WPF

Windows Presentation Foundation – grafický subsystém .NET Framework

XAML

Extensible Application Markup Language – značkovací jazyk využívaný pro tvorbu aplikací ve Windows Presentation Foundation

XML

Extensible Markup Language – obecný značkovací jazyk

58

Seznam příkladů Příklad 1: Definice třídy NotifyObjectBase.................................................................... 39 Příklad 2: Nastavení vlastnosti pomocí System.Reflection ............................................ 40 Příklad 3: Příkaz pro spuštění rozpoznání znaků pomocí Tesseract OCR ..................... 42 Příklad 4: Ukázka části souboru ..................................................................................... 43 Příklad 5: Metoda pro vložení textu do PDF pomocí PdfContentByte .......................... 46 Příklad 6: Otevření okna ve WinForms .......................................................................... 48 Příklad 7: Zobrazení watermark ..................................................................................... 49 Příklad 8: Zápis mapování objektu pomocí DataTemplate ............................................ 50 Příklad 9: Konstrukce pro zobrazení OCR textu ............................................................ 50

59

Přílohy 1

ER diagram

Na přiloženém listu se nachází ER diagram databáze.

60

2

Přiložené CD

Na přiloženém médiu se nachází instalátor aplikace ve složce install. Ve složce dokumentace se pak nachází tento dokument ve formě PDF a složka s projektem aplikace.

61

3

Manuál aplikace

Instalace Program Domácí účetnictví lze nainstalovat na systém Windows verze XP a vyšší. Instalaci lze spustit pomocí souboru Domaci-ucetnictvi_setup.exe. Instalace probíhá pomocí průvodce a jsou nainstalovány všechny potřebné komponenty.

Obecné postupy Nápověda Pro každou proveditelnou akci lze v aplikaci zobrazit nápovědu pomocí přidržením ukazatele myši nad příslušným tlačítkem, které akci znázorňuje. Nápověda se pak zobrazí ve formě jednoduchého textu viz Obrázek 1.

Obrázek 1 - Jednoduchá nápověda

Prvky pásu karet pak obsahují obsáhlejší nápovědy, jak je předvedeno na Obrázek 2.

Obrázek 2 - Obsáhlejší nápověda

Hlavní okno Hlavní okno aplikace lze rozdělit do 3 částí podle Obrázek 3.

62

Obrázek 3 - rozložení hlavního okna aplikace

Rychlé volby Toto pole obsahuje tlačítka pro následující akce: - přejít na předchozí otevřenou záložku - přejít na další záložku - uložit aktuální záznam – tato akce je platná pro všechny záznamy a seznamy, které lze uložit, napříč celou aplikací - vrácení provedené změny v rámci aktuálního záznamu - opětovné provedení vrácené změny v rámci aktuálního záznamu Agendy Jedná se o pás karet, které představují jednotlivé obsluhované agendy – Doklady, Zakázky, Nabídky a Administrace. Mezi jednotlivými kartami lze přepínat kliknutím na záhlaví karty. Pole Agendy dále obsahuje hlavní akční tlačítko

, pomocí

kterého lze vyvolat akce „Nový“, „Otevřít“, „Uložit jako…“ a také spravovat možnosti aplikace.

Část

Agendy

obsahuje

také

pole

pro

rychlé

hledání

, které umožňuje jednoduše vyhledat jednotlivé položky (doklady, nabídky, zakázky a další) podle zadaného textu. Hledání se spustí stiskem tlačítka

. Další položkou v části Agendy je tlačítko

nápovědu k programu. 63

, které vyvolá

Pracovní plocha Nejdůležitějším prvkem hlavního okna je část Pracovní plocha. Zde se zobrazují jednotlivé otevřené seznamy i jednotlivé doklady, nabídky a tak dále. Veškerá práce uživatele se tedy odehrává právě v těchto místech. Na Obr. 2 je vidět stav pracovní plochy při stisku tlačítka pro vytvoření nové faktury.

Obrázek 4 - Stav části Pracovní plocha po stisku tlačítka Nový

Agendy Tato část aplikace obsahuje rozličné akce, které lze v aplikaci provádět. Obsahuje níže uvedený výčet záložek. 

Domů – obsahuje akce pro přímé vložení faktur do aplikace, a to buď rovnou ze skenovacího zařízení, nebo ze skenovaného obrázku. Dále obsahuje volby pro zálohu databázového souboru a import a export dat ze systémů třetí strany.



Doklady – umožňuje správu daňových dokladů a faktur. Doklady a faktury lze zobrazit v seznamu, vyhledávat nebo vytvářet nové a evidovat již existující. Detail dokladu nebo faktury lze zobrazit v nové záložce dvojklikem na příslušný řádek v seznamu.

64



Zakázky – umožňuje správu zakázek. Zakázky lze zobrazit v seznamu, vyhledávat, zakládat nové nebo editovat již existující záznamy. Detail zakázky lze zobrazit v nové záložce dvojklikem na příslušný řádek v seznamu.



Nabídky – umožňuje správu nabídek. Nabídky lze zobrazit v seznamu, vyhledávat, zakládat nové nebo editovat již existující záznamy. Detail nabídky lze zobrazit v nové záložce dvojklikem na příslušný řádek v seznamu.



Administrace – tato záložka umožňuje správu číselníků použitých v aplikaci. Jedná se o číselníky „Subjekty“, „Výrobci“, „Zboží“ a „Druhy zboží“. Lze zakládat nové záznamy a editovat již existující.



Aktuální dokument – tato záložka je zobrazena pouze v případě, že je na pracovní ploše zobrazen některý z objektů Faktura, Nabídka nebo Zakázka. Tato karta pak obsahuje funkčnosti, které jsou daným objektů společné. Jedná se o možnost vložení elektronického souboru přílohy k aktuálnímu objektu, možnost uložení ve formátu PDF, uložení provedených změn do databáze, tisk pomocí výchozí tiskárny, odeslání aktuální ve formě PDF přes email, smazání záznamu z databáze a uložení jako šablony (předlohy) pro jeho použití při vytváření nových objektů.



Aktuální seznam - tato záložka je zobrazena pouze v případě, že je na pracovní ploše zobrazen některý z objektů seznamů – například seznam faktur, nabídek, zakázek atd. Obsahuje volby pro občerstvení (opětovné načtení) seznamu, uložení změněných hodnot do databáze, možnost uložení ve formátu PDF a možnost tisku přes výchozí tiskárnu.

Seznamy V aplikaci se vyskytují dva níže uvedené typy seznamů. 

Needitovatelný – tento seznam slouží pouze pro zobrazení položek, například uložených nabídek. U těchto položek pak lze otevřít jejich detail pomocí dvojkliku na řádek. Tento detail se otevře v nové záložce, pokud je však již na některé záložce pracovní plochy otevřen, provede se přesun na tuto záložku. Hodnoty položek nelze měnit.

65

Obrázek 5 - Needitovatelný seznam



Editovatelný – tento typ seznamu se vyskytuje například v detailu faktury, kde slouží pro zaznamenání položek faktury. Přes tento seznam nelze zobrazovat detail položky, ale lze měnit jednotlivé položky. To lze provést kliknutím do políčka. Tento seznam vždy obsahuje prázdný poslední řádek, který slouží pro zadání nového záznamu.

Obrázek 6 - Editovatelný seznam během editace

Detail Detail je karta některého z objektů typ Faktura, Doklad, Nabídka nebo Zakázka. Slouží jako formulář, do kterého se vyplňují jednotlivé položky. Během editace detailu dochází ke kontrole vstupních dat a v případě nesrovnalostí je o nich uživatel informován pomocí výstražné ikony. Pod touto ikonou se skrývá ještě jednoduchá nápověda viz Obrázek 7.

Obrázek 7 - Kontrola vstupních dat

66