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

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

Ekonomický systém bakalářská práce

Autor: David Brychta Vedoucí práce: Ing. Marek Musil Jihlava 2015

Abstrakt Tato práce řeší komplexní návrh aplikace a vlastní realizaci malého ekonomického systému. V rámci ekonomického systému jsou vytvořeny jednotlivé moduly zastřešující oblasti evidence kontaktů, evidenci smluv, vystavování předpisů, importu bankovních výpisů a párování plateb v modulu banka. Součástí systému jsou moduly pro nastavení aplikace a správu elektronických dokumentů. Aplikace je vytvořena v prostředí .NET v jazyce C#.

Klíčová slova .Net Framework, adresář, banka, bankovní výpis, C#, ekonomický systém, MySQL, smlouva

Abstract This work presents complex application design according the standard development process

and

also

provides

the

implementation

of

economic

system

by this application design. The application is divided into five logic modules: contracts solve contracts registration, expiration dates etc., accounts - mainly solve the relationship between contracts and payments, bank accounts - holds records of bank accounts and solve their relationship to contracts accounts, application settings - solve the basic setting of application on global level, document management - interface for storing various types of files. The application is written in C# language using .NET framework.

Key words .Net Framework, address book, agreement, bank, bank statement, C#, economic system, MySQL

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. Markovi Musilovi za poskytnutí tématu a možnost vytvářet ho pod jeho vedením.

Obsah 1

Úvod a motivace ....................................................................................................... 7

2

Současný stav ............................................................................................................ 9

3

Analýza aplikace ..................................................................................................... 14 3.1

Požadavky na aplikaci ...................................................................................... 14

3.2

Definice operací v agendách ............................................................................ 22

3.3

Datový model ................................................................................................... 26

4

Použité technologie ................................................................................................. 31

5

Koncept realizace projektu ..................................................................................... 33

6

5.1

Databázová a datová vrstva .............................................................................. 33

5.2

Logická vrstva .................................................................................................. 36

5.3

Prezentační vrstva ............................................................................................ 41

Realizace projektu................................................................................................... 44 6.1

Přihlášení do aplikace a hlavní okno aplikace ................................................. 45

6.1.1

Přihlašovací okno ...................................................................................... 45

6.1.2

Hlavní okno aplikace ................................................................................ 46

6.2

Modul Nastavení .............................................................................................. 47

6.3

Modul Adresář ................................................................................................. 51

6.4

Modul Smlouvy................................................................................................ 52

6.5

Modul Banka .................................................................................................... 57

6.5.1

Nahlížení a import bankovního výpisu ..................................................... 57

6.5.2

Párování plateb ......................................................................................... 58

7

Testování ................................................................................................................. 63

8

Závěr ....................................................................................................................... 64

Seznam použité literatury ............................................................................................... 66 Seznam obrázků .............................................................................................................. 67 Seznam tabulek ............................................................................................................... 69 Seznam použitých zkratek .............................................................................................. 70 Přílohy............................................................................................................................. 71

1 Úvod a motivace V kapitole jsou rozebrány důvody, které mne vedli k zamyšlení a rozhodnutí realizovat vlastní software pro provoz občanského sdružení. Je mnoho produktů, které se zabývají oblastí ekonomických systémů od malých programů vyrobených v rámci školních projektů až po komplexní ekonomické – průmyslové systémy, které řídí velké výrobní nadnárodní korporace. Na trhu existují produkty, které řeší kompletní řízení chodu společnosti poskytující služby v oblasti přenosu dat. Jejich výhodou je, že zpracovávají data od ekonomické povahy, jako například evidence majetku, smluv či sledování skladových zásob v návaznosti na řízení ovládacích prvků sítě jako jsou koncové zařízení uživatelů sítě, routery a přerozdělování přístupu, konektivity. Hlavní a zásadní nevýhodou spatřuji na provázanost určitých typových zařízení od jednoho výrobce, který dodává komponenty a řídící prvky pro sítě. Přebudování sítě v konečném čase by bylo hlavně finančně nákladné. Dalším aspektem je cena software. Ceny takových software jsou příliš vysoké, co bychom od takového produktu očekáváli. Negativně je vnímána i závislost na produktu třetí strany, do kterého nemůže zasahovat, pokud bychom narazili na nějaký technický problém. Výběr vhodného ekonomického systému třetí strany pro řízení i občanského sdružení je velice komplikovaný problém, do kterého vstupuje mnoho počátečních podmínek. V daný moment značně ovlivňují rozhodování. Před podobnou situaci jsou a budou postaveny všechny spolenosti. Na začátku celého problému existovala evidence smluvních vztahů. Systém byl vybudován v programovacím jazyce PHP s webovým Apache HTTP Serverem na platformě MySQL a to celé provozované na unixovém operačním systému FreeBSD. Celý systém byl obsluhován pouze manuálním způsobem. Z níže uvedených počátečních podmínek pro výběr vhodného ekonomického systému můžeme cítit, že společnost nebyla v dobrém rozpoložení a probíhala jistá transformace společnosti, která se promítnula i do výběru vhodného ekonomického systému. Pokud by byla zajištěna stabilita společnosti i budoucnu, možná bychom uvažovali o komerčním produktu, který by disponoval veškerými potřebnými funkcemi. 7

Počáteční podmínky ovlivňující rozhodování: •

stabilita v řízení společnosti,

•

aktuální ekonomický stav společnosti,

•

ekonomické a účetní znalosti řízení vedení společnosti,

•

ekonomické odvětví fungování společnosti,

•

aktuální používané softwarové nástroje,

•

schopnosti lidí v oblasti informačních technologií v oblastech vývoje software a hardware,

•

aktuální produkty a jejich portfolio služeb vhodné svým zaměřením a odpovídající ekonomickým potřebám společnosti,

•

možnosti konzultačních a outsourcingových firem pro zastřešení účetnictví,

•

a jiné další faktory.

Vlastní proces zpracování plateb vůči evidovaným smluvním vztahům probíhal manuálním párováním příchozích plateb, kdy odpovědná osoba za kontrolu plateb, procházela webové rozhraní bankovního portálu a ručně procházela položku po položce a přiřazovala platbu k dané smlouvě. Neexistoval žádný automatický mechanismu porovnání bankovního výpisu s daty evidovaným v interním systému. Tomuto stavu bohužel nenapomáhal ani bankovní institut, u kterého společnost využívá poskytované služby. Jejich daný produkt nenabízel žádnou rozumnou formu výstupních formátů dat, tak aby bylo možné strojově zpracovat data. Dalším problém byl v účetním programu, který byl v dané době využíván, nedovoloval automatické generování faktur s požadovanou strukturou dat, tak aby mohlo být zpětně naparováno pomocí bankovního výpisu pro strojové zpracování dat. Na základě výše uvedených skutečností a analýzy dostupného software, cenové politiky produktů a využitelnosti služeb, společnost rozhodla o vývoji vlastního software pro ekonomickou analýzu dat a částečnou zprávu účetnictví, který bude schopen vystupovat podklady pro účetní firmu. Cílem projektu bude vybudování metodického podkladu a funkční aplikaci, kterou bude možné provozovat v reálném provozu.

8

2 Současný stav V kapitole jsou představeny produkty, které by mohli být využity k vedení smluv, faktur a plateb. Následně jsou tyto produkty porovnány na základě výběrových kriterií s odůvodněním, proč byla vybrána či zamítnuta daná varianta. Na trhu existují malé účetní programy, středně velké systémy a komplexní systémy. Malé účetní programy umí evidovat všechny potřebná data (z pohledu účetnictví) za rozumnou cenou, ale neumí evidovat data v databázovém serveru a není možný případný zásah do aplikace a dat v případě nutnosti úprav funkcí, zajištující vstupy, zpracování a výstupy dat. Neumí provádět hromadné operace typu: hromadné generování faktur s přesně stanoveným variabilním symbolem a poté je hromadně odeslat klientům e-mailem. Neumí zpracovávat bankovní výpisy a provádět automatické párování plateb. Příkladem pro malý účetní program může být např. Pohoda, která se specializuje pouze na účetnictví v základních modulech. Při zakoupení nadstavbového modulu umožňující pokročilé operace roste jeho cena. Ukázka produktu je vidět na obrázku 1 – Ukázka programu Pohoda níže.

Obrázek 1 - Ukázka programu Pohoda

9

Střední ekonomické systémy, které umí evidovat všechny potřebná data (z pohledu účetnictví a evidence smluv) i další, které v daném oboru poskytování služeb nepotřebuje, jako jsou například evidence zaměstnanců, evidence aut atd. Pro ukládání dat lze využít databázový server. Není možný zásah do aplikace či do dat. Umí provádět hromadné operace typu: hromadné generování faktur s omezením na přesně definovaná data, nelze měnit variabilní symbol. Umí hromadně rozesílat vygenerované faktury klientům e-mailem. Umí zpracovávat bankovní výpisy, a pokud jsou generovány předepsaným způsobem (většinou nelze měnit variabilní symbol, nelze definovat vlastní párovací symbol), lze je i automaticky párovat vůči vystaveným fakturám. Cenově jsou tyto systém již nedostupné. Příkladem pro střední ekonomický systém může být například ISP Servis, který na první pohled může spadat do první skupiny, ale je nutné upravit jeho moduly do prostředí organizace za další finanční náklady. Ukázka produktu je vidět na obrázku 2 – Ukázka programu ISP Servis níže.

Obrázek 2 - Ukázka programu ISP Servis

Komplexní ekonomické systémy se specializací na konkrétní oblast poskytování služeb umí evidovat všechna potřebná data (z pohledu účetnictví, evidence smluv a spousty jiných evidencí pro řízení velkého provozu) i s napojením na koncová zařízení poskytující službu přenosu dat. Ukládání dat je řešeno databázovým serverem. Není možný zásah do aplikace či do dat. Umí provádět hromadné operace typu: 10

hromadné generování faktur s omezením na přesně definovaná data, nelze měnit variabilní symbol atd. Umí hromadně rozesílat vygenerované faktury klientům e-mailem. Umí zpracovávat bankovní výpisy, a pokud jsou generovány předepsaným způsobem (většinou nelze měnit variabilní symbol nelze definovat vlastní párovací symbol), lze je i automaticky párovat vůči vystaveným fakturám. Cenově jsou tyto systém již příliš nedostupné. Dalším pozitivním aspektem je napojení a řízení koncových zařízení v rámci poskytování služeb. Bohužel je většinou stavěno na jednu platformu zařízení či výrobce, takže ve stávající infrastruktuře, která je velice různorodá podle toho co v dané době bylo potřeba řešit a na základě již nabytých zkušeností třeba změnit typ a výrobce zařízení. Názorným příkladem komplexního ekonomického systému pro správu chodu společnosti zabývající se poskytováním služeb v oblasti telekomunikace je ISP Admin. Ukázka produktu je vidět na obrázku 3 – Ukázka programu ISP Admin níže.

Obrázek 3 – Ukázka programu ISP Admin

Určení míry, kdy je daná cena přijatelná a kdy není, se v čase mění v závislosti na dostupných finančních prostředcích společnosti. Návrh a způsob realizace vývoje dané aplikace se odvíjí od přesného pochopení zadání. Komunikace s konečným uživatelem definujeme vstupy a výstupy, pracovní postupy,

11

které by měly probíhat v rámci zpracování vstupních a výstupních dat, případné stanovení algoritmů pro vstupní/výstupní dat. Velikost software

Otevřenost kódu

Ukládání dat

Cena [tis. Kč]

Hodnocení

Malý

Ne

Souborový systém

Cena < 20

Nevyhovuje

Střední

Ne

Souborový systém / databázový server

20 < Cena< 50

Nevyhovuje

Velký

Ne

Databázový server

50 < Cena

Nevyhovuje

Tabulka 1 - Srovnání software

Na základě získaných informací bude zvolena metodika způsobu vývoje a tedy i povaha, rozsah software, který budeme realizovat. V dnešní době existují statistické mapy typických osvědčených druhů softwarových projektů, u kterých jsou doporučené postupy vývoje. Tyto postupy vývoje jsou optimalizovány podle druhů odvětví, kde jsou software využívány, míry chybovosti a tedy i nákladů na vývoj, optimalizaci i dalšího provozu. Za základní skupiny můžeme považovat systémy zajišťující: •

běžné provozy jako jsou účetnictví, evidence majetku,

•

důležité oblasti ale nejsou ve strategickém zájmu, jako je např. energetika,

•

životně důležité oblasti jako je např. zdravotnictví, energetika.

V našem případě se jedná o model běžného provozu, typu malého projektu, kde určité fáze

vývoje

mohou

splynout

nebo

jsou

zadány

na

neformální

úrovni,

tak aby dokreslovali a korigovaly průběh vývoje. Má základě rámcového stanovení koncového produktu můžeme orientačně stanovit metodiku vývoje, kterou dále budeme aplikovat pro celkovou analýzu koncového produktu. Doposud jsem se díval na celou problematiku spíše z nadhledu, kdy jsem se pokoušel do návrhu aplikací přistupovat selským rozumem tak, aby řešení bylo co nejefektivnější jak z pohledu vývoje (řízení dostupných výrobních kapacit), tak i z pohledu koncového uživatele (ergonomie využití produktu).

12

Bohužel v dnešní době je tendence, aby aplikace myslely za člověka. Ano, z jednoho pohledu nejrizikovější prvek všeho, kde se podíváme, ale je to jediný mechanismus, který je schopen odhalit chybu. Na druhou stranu tento přístup nutí lidi méně přemýšlet, o tom, co dělají a proč to dělají. Pokud aplikace selže, přestane něco hlídat a chyba aplikace není zachycena myslícím člověkem, tak propluje nakonec svého životního cyklu, tak se chyba hledá v aplikaci, nikoliv v následném selhání otupělého lidského myšlení zlenivělého všemožnými automatickými procesy. Z praxe, kde jsem byl zařazen do vývoje již existujícího produktu, kde se pohybuji na předem stanoveném rozmezí a řeším pouze dílčí problémy komplexního ERP (Enterprise Resource Planning) systému, jsem si nikdy neuvědomil, že navrhnout aplikaci od přihlášení do aplikace až po konečné výstupy může být tak náročné v maximálním pojetí, které jsem zvyklý řešit na dílčích projektech. Na jednou přede mnou vyvstávají otázky, které jsem dříve považoval za samozřejmost a vůbec jsem si nedokázal představit jejich složitost v konečném řešení. Pravidlo několikráte měř a jednou řež, se ukazuje být dosti pravdivé, protože zpětné přehodnocení vývoje aplikace znamená (v mém malém projektu) „zahodit vše“ a začít znovu. Tyto zkušenosti, kdy jsem se pokoušel začít programovat aplikaci při povrchní analýze a nezkušenosti v praktickém programování, mě utvrdili, že návrh a rozvržení aplikace je velice důležité. Než se pustíme do návrhu vývoje aplikace, tak si připravíme krátký vstup do metodik návrhu a vývoje aplikací, ze které zvolíme jednu a budeme se ji snažit dodržet do konce tohoto projektu.

13

3 Analýza aplikace V kapitole jsou detailně probrány požadavky na aplikaci z pohledu uživatele. Tyto požadavky jsou rozčleněny do jednotlivých agend. V následném kroku je definován datový model vycházející z požadavků na aplikaci a rozvržením jednotlivých agend včetně jejich operací. Aplikace je postavena pro zpracování požadovaných údajů, které jsou definovány v podkapitole kapitole Požadavky na aplikaci. Průběh zpracování dat v čase je zobrazen na obrázku 4 – Stavový diagram – Průběh pořízení dat. S produktem bude aktivně pracovat jeden pracovník. Z tohoto důvodu není řešena část případného paralelního zpracování dat. Z pohledu zabezpečení provozu aplikace je řešena pouze základní přihlášení do aplikace s ověřením uloženého uživatelskému profilu v databázi. Určité nedostatky ohledně paralelního uživatelského provozu, či šifrovanému datovému přenosu mezi klientem a databází jsou samostatné rozsáhlé oblasti řešené právě u větších firemních aplikací, na kterých pracuje rámcově několik pracovních teamů. Z časových důvodů nebude tato část řešena.

3.1 Požadavky na aplikaci Požadavky na aplikaci z hlediska zadavatele můžeme dělit do základních oblastí zpracování dat, které jsou pokryty agendami adresář, smlouvy, banka, nastavení a virtuální dokumenty.

Adresář Adresář musí obsahovat nejnutnější data pro založení smlouvy a následné vytvoření předpisů (obdoba účetních dokladů faktur a dobropisů). Pokud budeme evidovat fyzickou osobu, je nutné evidovat následující údaje: •

jméno, příjmení,

•

rodné číslo,

•

adresu (ulice, město, číslo popisné, číslo orientační, PSČ popřípadě platnost při změně). 14

V případě, že se bude ude evidovat právnická osoba, potřebujeme ebujeme evidovat: •

název subjektu,

•

IČ,

•

DIČ,

•

adresu (ulice, město, mě číslo popisné, číslo orientační, č PSČ Č popřípadě pop platnost při změně) ě popřípad řípadě plátce či neplátce DPH.

Obrázek 4 -Stavový diagram - Průběh pořízení dat

Subjekty, se kterými jsou podepisovány smlouvy pro odběr/dodávku odb r/dodávku služby, mohou mít více druhů adres, tj. fakturační faktura a místo odebírání služby. V případě př sepisování smluvních vztahů, ů, kde bude naše organizace konzumentem konzumentem služby, bude obdobné

15

jako u poskytnutí služby. Na jednu adresu si necháváme zasílat faktury např. pro úhradu nájmů a na jiném místě probíhá odběr poskytnuté služby. Ke každému subjektu je požadováno evidovat poznámku, která může obsahovat různé doplňující údaje k danému subjektu. Bez ohledu na právnickou či fyzickou osobu je požadováno evidovat další údaje subjektu, např. kontaktní údaje, telefon, e-mail. U subjektu bude možnost evidovat bankovní účty. Může sloužit k druhotné identifikaci příchozí platby. Tento údaj je dostupný v bankovním výpisu, resp. bankovní výpis obsahuje název bankovního účtu a v případě vlastnictví fyzické osoby standardně je označen příjmením a jménem vlastníka účtu. Tento údaj je možné na vyžádání vlastníka účtu neposkytovat. Nemusí být vždy dostupný.

Smlouvy Systém musí umět evidovat jak příjmové tak i výdajové smlouvy. Ke každé smlouvě se budou evidovat naskenované kopie smluv/dodatků či jiné další elektronické přílohy. Příjmové smlouvy Smlouvy příjmové jsou z větší části tvořeny poskytováním služeb - internetu. Smlouva musí obsahovat: •

údaje o subjektu, se kterým se daný smluvní vztah uzavírá,

•

adresu, na kterou se má daná fakturovat s možností evidence adres, kde je daná služba poskytována,

•

datum evidence, datum platnosti smluvního vztahu, datum zahájení plateb (měsíc – pro výpočet předpisů a plateb k úhradě),

•

v případě poskytnutí služby internetu, možnost evidovat tarif, se kterým je daná smlouva uzavřena.

Z příjmových smluv se budou tvořit tak zvané předpisy (obsahově odpovídá fakturám, dobropisům). Na základě těchto předpisů bude možné vytvořit podklady pro účetní firmu k tvorbě kvartálního daňového přiznání. Tvorba předpisů se bude provádět v měsíčních intervalech. Dalším rozměrem předpisů bude podklad pro vyhodnocení plnění smluv na základě párování příchozích plateb, které se budou párovat automaticky nebo ručně. 16

Výdajové smlouvy V případě výdajových smluv (nájmy, energie atd.) se bude evidovat: •

subjekt/y, se kterým je daná smlouvy sepsána,

•

datum evidence,

•

datum platnosti (od – do) smlouvy,

•

výpovědní doby jednotlivých smluv – tj. doba, ve které lze smlouvu změnit.

Organizace má sepsány smlouvy, které se do určité doby nevypoví nebo nezmění a následující rok jsou plněny v původním znění nebo dojde k jejich ukončení. Odchozí platby se budou párovat ručně – automatické párování by bylo možné, pokud bychom uváděli do popisného textu určitý párovací symbol, což bude číslo smlouvy, vůči které je provedena úhrada. Pokud by subjekt zasílal faktury, na základě kterých se toto platí lze realizovat, protože bude provedena manuální úhrada prostřednictvím elektronického bankovnictví.

Banka Prostřednictvím banky budou importovány elektronické bankovní výpisy obsahující položky pohybů na bankovním účtu. Import bankovního výpisu je možné provést na základě definičního klíče bankovního výpisu, který je definován v manuálu daného bankovního institutu. Po importu plateb mohou

být

položky

spárovány

s vygenerovanými

předpisy

automaticky

nebo ručně. Pro automatické párování je nutná podmínka stejného variabilního symbolu a částky předpisu a variabilního symbolu platby s částkou. V ostatních případech je možné využít ruční párování. Podrobně je mechanismus rozebrán v následující kapitole. Přesné řešení algoritmů je popsáno v kapitole Realizace projektu. Dalším požadavkem na banku je, aby uměla vyhledávat v importovaných datech, např. podle variabilní symbol (VS), specifický symbol (SS), konstantní symbol (KS), částky

„Od-Do“,

čísla

bankovního

účtu

a

poznámky

příchozí

platby.

Tisk se bude provádět z vyfiltrovaných údajů exportem dat do souboru (*.csv, potažmo do formuláře pro potvrzení přijetí plateb zákazníka nebo jiného výstupního tiskového formuláře).

17

Bankovní výpis Bankovní výpis je textový soubor, který lze získat v různých datových strukturách: •

*.gpc – základní formát, obsahující základní omezené informace o transakci,

•

*.abo – rozšířená forma, která obsahuje navíc od *.gpc název bankovního účtu, což je ve většině případů jméno majitele účtu.

Struktury jsou definovány bankovním institutem, který takové výstupy poskytuje. Stažení bankovního výpisu probíhá pomocí software dodávaným příslušným bankovním institutem. Komunikace je zajištěna ověřením certifikátu příjemce souboru.

Název položky

Počet

Formát

Typ záznamu

3

075

Číslo účtu klienta

16

NNNNNNNNNNNNNNNN

Číslo protiúčtu

16

NNNNNNNNNNNNNNNN

Číslo dokladu

13

NNNNNNNNNNNN

Kód účtování

1

N

Variabilní symbol

10

NNNNNNNNNN

Konstantní symbol

10

NNNNNNNNNN

. Specifický symbol

10

NNNNNNNNNN

. Valuta

6

DDMMRR

Doplňující údaj

20

NNNNNNNNNNNNNNNNNNNN

Kód změny položky

1

N

Druh dat

4

Moo

Datum splatnosti / připsání

6

DDMMRR

Tabulka 2 - Transformační tabulka pro převod z *.GPC

18

Párování plateb Párování plateb je jedna z nejdůležitějších funkcí modulu Banka. Funkce vyhledá neuhrazený nebo částečně neuhrazený předpis a tento předpis spáruje s nespárovanou položkou bankovního výpisu. Párování může být prováděno podle různých druhů párovacích kriterií např. variabilního symbolu vystaveného předpisu a variabilního symbolu položky bankovního výpisu. Pokud někdo provádí platby pod špatným variabilním symbolem nebo vůbec nemá zadán variabilní symbol v platebním příkazu, je vhodné použít ruční párování platby s vygenerovaným předpisem. Automatické párování Po provedení importu dat do databáze, je nutné vytvořit mechanismus automatického párování, který bude probíhat na základě variabilního symbolu platby, který odpovídá jedinečné identifikaci smluvního případu a částky daného předpisu. U spárovaných plateb se nastaví příznak, že bylo spárováno s daným předpisem a na daném předpisu se provede nápočet uhrazené s číslem dokladu platby z bankovního předpisu. Pokud nebyla splněna podmínka párování (VS a částka předpisu) na platbě se nastaví příznak nespárováno a bude nutné provést ruční párování. Ruční párování Při ručním párování plateb mohou následující případy: platba obsahuje správný VS, ale částka úhrady je různá od částky předpisu: •

částka je nižší než částka předpisu,

•

částka je vyšší než částka předpisu,

•

platba obsahuje neexistující variabilní symbol, částka je různá od předpisů.

Funkce ručního párování bude probíhat nad jednou nespárovanou platbou. Nabídku smluv lze přefiltrovat podle příchozích plateb a jejich bankovních účtů a pokusit se dohledat bankovní účet subjektu, který je dané smlouvě. Podle příchozích plateb bude nutné založit příslušné bankovní účty k subjektům. Pokud by se nebyla nalezena shoda, musí se jít opravdu smlouva po smlouvě a názvu účtu, ze kterého byla provedena platba. Pokud se podaří dohledat platbu a daný účet není na daném subjektu, může uživatel přidat daný účet k danému subjektu, tak aby bylo možné příští nespárovanou platbu lépe spárovat.

19

Obrázek 5 - Vývojový diagram - Párování plateb

Na obrázku 5 – Vývoojový diagram – Párování plateb je schematicky znázorněno párování plateb. Na vstupu je částka s variabilním symbolem (c_fak, vs_fak) předpisu a částka s variabilním symbolem symbol (c_pla, vs_pla) platby. Na základěě porovnání předpisu a platby bude provedeno automatické párování nebo ruční ní párování. párování Podrobný popis párování je rozebrán v kapitole Realizace projektu – Modul Banka. Obecně mohou nastat tři stavy: částka platba a variabilní symbol předpisu p edpisu se rovná částce platby a variabilního symbolu. Druhý a třetí t stav představují rozdílné částky předpisu př a platbty.

20

Po výběru dané smlouvy, resp. jeho předpisu dojde k napočítání částky příchozí platby na daný předpis, označí se uhrazeno a v případě úplného spárování platby příznaku spárováno na platbě. Pokud bylo párováno část z částky příchozí platby, nastaví se příznak párováno částečně, číslo platby se přidá na párovaný předpis a platba zůstane otevřena k dalšímu párování.

Nastavení V této

části

bude

probíhat

administrace

malého

ekonomického

systému.

Část administrace se bude ukládat do konfiguračního souboru a část se bude ukládat do databáze serveru. Základní informace o subjektu využívající produkt budou ukládány do konfiguračního souboru. V systému se vyskytují typy číselníků, které se v čase mění a je nutné je umět administrovat uživatelsky. Ukázkou mohou být tarify, které se v čas mění a rozšiřují. V další části Nastavení bude možnost administrovat uživatele (přidat, editovat či odebrat), kteří mohou vstoupit do systému. Uživatelé se budou ukládat do databáze, vůči které bude probíhat základní ověření uživatele. Součástí nastavení bude možnost nastavení uživatelské dokumentace. Dokumentace bude v podobě přiloženého souboru, který bude uživatel moci udržovat. Přednastavený formát pro dokumentaci je PDF. Uložení souborů bude probíhat do přednastavené složky, která bude umístěna na počítači. Cestu bude možné změnit.

Dokumenty Zvláštní agendou jsou Dokumenty. Agenda je spíše virtuální a tvoří společnou datovou vrstvu pro ukládání elektronických dokumentů v agendách. Prozatím bude využito pouze v modulu Smlouvy pro přikládání elektronických příloh. Pokud se budou v budoucnu generovat elektronické obrazy u faktur, tak budou též ukládány do této virtuální datové vrstvy.

21

3.2 Definice operací v agendách Na základě definice problému tj. požadavku klienta, klienta jsou řešeny čtyři okruhy evidovaných a zpracovávaných dat. Podle toho se dělí i aplikace plikace do agend: Adresář, Adresá Smlouvy, Banka, Nastavení a virtuální Dokumenty.. Pro každou agendu jsou vydefinovány základní operace s daty. Agenda Adresář Agenda bude zpracovávat všechny potřebné pot ebné údaje, pro korektní identifikaci subjektu, se kterým jsou uzavírány smluvní vztahy a dále vystavovány předpisy předpisy (obdoba faktur). Pasivní operace umožňují ňují ují uživateli nahlížet na data (zobrazení seznamu evidovaných položek) a nad těmito ěmito daty provádět provád t vyhledávání dle kriterií zadané ve filtrační filtra masce nad seznamem dokladů. ů.. Další pasivní operací je tisk. Tisknou se pouze zobrazená data v seznamu položek vybraných agend (Adresář, (Adresá Smlouvy, otevření ření bankovního výpisu). výpisu) Aktivní operace umožňují ňují ují uživateli zakládat nový záznam (nový subjekt) a dále tento subjekt upravovat (editace subjektu). Pokud záznam není vázán na smluvní vztah, lze provést jeho smazání. Operace jsou ukázány v diagramu užití na obrázku 6 – Diagram užití – Adresář.

Obrázek 6 - Diagram užití – Adresář

22

Agenda Smlouvy Agenda bude zaopatřovat řovat kompletní evidenci příjmových p íjmových a výdajových smluvních vztahů..

Základní

identifikace

partnera

bude

p přejata

z agendy

Adresář.

Na základě evidovaných smluvních vztahů, vztah lez připravit ipravit generátor faktur či sledovat plnění ní smluvních vztahů. vztahů Pasivní operace umožňují ňují ují uživateli nahlížet na data (zobrazení seznamu evidovaných položek) a nad těmito ěmito daty provádět provád vyhledávání dle kriterií zadané né ve filtrační filtra masce nad seznamem dokladů. ů.. Další pasivní operací je tisk. Tisknou se pouze zobrazená data v seznamu do souboru (*.csv). Aktivní operace umožňují ňují ují uživateli zakládat nový záznam (novou smlouvu) a dále tento subjekt upravovat (editace smlouvy). smlouvy). Pokud záznam není vázán na předpisy, př lze provést jeho smazání. K dané smlouvě smlouv lze vytvářet nové předpisy, edpisy, editovat a případně p odstraňovat ovat (pokud nejsou vázány na platbu. Po vytvoření vytvo předpisu, ředpisu, lze vytvářet vytvá platby a tyto platby odesílat k párování. Evidence smluvního vztahu je možnost přidávání p a odebírání elektronických příloh. p

Obrázek 7 - Diagram užití – Smlouvy

23

Agenda Banka Agenda bude se starat o provedení importu dat z bankovního výpisu, které poté bude možno spárovat s vystavenými předpisy (obdoba faktur). V modulu bude možné provést otevření ení bankovního výpisu, kde bude možné vyhledávat a tisknout do souboru. souboru Agenda Banka bude obsahovat tyto základní operace: •

import bankovních výpisů, výpis , párování plateb: automatické a ruční, ruč

•

vyhledávání v importovaných výpisech.

Obrázek 8 - Diagram užití - Banka

24

Agenda Nastavení V agendě bude uživatel provádět provád t základní nastavení systému. Jak je vidět na obrázku 9 – Diagram užití – Nastavení bude možné provádět ět evidence základních údajů o organizaci (název organizace, ulice, číslo popisné, obec a poštovní směrovací sm číslo.. Tyto základní údaje budou uloženy v konfiguračním ním souboru, Součástí nastavení bud správa číselníků. ů. Mezi takové patří pat správa tarifů pro smlouvy,, kde jsou definovány základní operace s tarify. Správa číselníků se bude ukládat do databáze. Pro práci se souborovým úložištěm m a dokumentací je nutné mít možnost nastavení jejich cest, kde se budou ukládat dat elektronické přílohy p ílohy a volat soubor dokumentace. Nastavení práv přístupů uživatelů,, které je řešeno v části Správa uživatelůů se základními operacemi, obrázek 9 – Diagram užití – Nastavení.

Obrázek 9 - Diagram užití - Nastavení

25

3.3 Datový model Na základě definice problému a vyspecifikování požadavků na aplikaci vznikl návrh datového modelu aplikace. Datový model je vytvořen v EER diagramech. Datový model odpovídá agendovému zpracování dat a je rozdělen do částí: •

adresář,

•

smlouvy,

•

banka,

•

nastavení a

•

virtuální dokumenty.

Datový model je navržen tak, aby na jedné straně v maximální míře odpovídal normalizačním pravidlům návrhů datových modelů a na druhé straně nekomplikoval realizaci na úrovni aplikace obsluhující data.

Adresář Datový model obsahuje objekty subjekt, po (právnická osoba), fo (fyzická osoba) a adresy. Základním objektem je subjekt, ve kterém se automaticky generuje identifikátor evidovaného subjektu (id_subjektu) při každém založení záznamu. Identifikátor subjektu je cizím klíčem v objektech po a fo. Vizuálně tato vazba je znázorněna pomocí čárkované vazební čáry mezi objekty tvořící vazbou 1:1. Tedy k danému subjektu může být právě jeden po a fo. Jiná situace je u vztahu subjekt a adresy. Zde je vazba znárodněna plnou čarou s rozvětvením u objektu adresy. Tento vztah odpovídá vazbě 1: n, kde v objektu adresy existuje primární klíč složený dvěma atributy (id_subjektu, id_adresy – automaticky generováno). Toto nám umožňuje uložit více záznamů v objektu adresy k subjektu, jako je například instalační či fakturační adresa daného subjektu. Názorný popis atributů objektů je zobrazen na obrázku 10 – Datový model – Adresář. Ve spodní části diagramu navazuje vazba (čárkovaná čára s roztřepeným koncem u objektu smlouvy) na objekty smlouvy, kde identifikátor subjektu je cizím klíčem a tvoří vazbu 0 : n, subjekt může vzniknout a nemusí být vázán na žádnou smlouvu a daný subjekt může být vázán na n smluv.

26

Obrázek 10 - Datový model – Adresář

Smlouvy Datový model obsahuje objekty smlouvy a předpisy. Vazba mezi subjekty a smlouvou je popsána v části Adresář. Identifikátor subjektu je zde definován jako cizí klíč, tedy není možné pořídit smlouvu se subjektem, který neexistuje v modelu Adresář. Při založení záznamu do objektu smlouvy se automaticky generuje identifikátor smlouvy. Toto je definováno na vlastnosti atributu id_smlouvy – atribut je plněn autoinkrementální hodnotou. Vazba mezi objekty smlouvy a předpisy je 0 : n znárodněná na obrázku čárkovaná čára s roztřepeným koncem u objektu předpisy. Prostřednictvím objektu předpisy je vytvořena vazba na datový model banka. Detailní návrh modelu je vidět na obrázku 11 – Datový model – Smlouvy. Smlouvy využívají číselník tarify, který je definován v datovém modelu Nastavení.

27

Obrázek 11 - Datový model – Smlouvy

Banka Datový model Banka se skládá z následujících objektů: párování, platby a soubory. Objekt párovaní disponuje dvěma primárními klíči. První primární klíč identifikátor párování (id_parovani) je zakládán automaticky při založení záznamu a k němu existuje druhý primární klíč, identifikátor předpisu (id_predpisu). Takto založený dvou klíč nám umožní vyřešit problém, kdy částka párování je kryta dvěma a více platbami. V praxi to znamená, že se založí další záznam se stejným identifikátorem předpisu, ale novým identifikátorem párování. Dojde k rozdvojení záznamu. Do systému jsou importovány soubory obsahující soupis týdenních plateb vystavené bankovním institutem ve specifickém formátu. Tyto soubory jsou převedeny do databáze a to do objektu výpisy, kde se založí hlavička a základní informace o nahraném souboru a poté se naplní obsah objektu platby. Objekt výpisy má primární klíč název souboru, který v sobě nese jedinečnou hodnotu. Ukázka názvu souboru: 15034_608100800_CZK.gpc. Název souboru vystupuje jako cizí klíč v objektu platby.

28

Vazba mezi platbami je zobrazena na obrázku Obrázek 12 - Datový model – Banka, čárkovanou čárou zakončenou roztřepeným koncem u objektu banka vyjadřující vazbu n: 1. Objekt platby má primární klíč převzatý z vlastní položky platby, tedy není nutné zakládat umělý primární klíč. Většina položek objektu je převzata z dostupných dat dávky. V objektu existují hodnoty, které byly přidány kvůli identifikaci platby a jejímu stavu vůči naparovaným platbám. Jedná se o položky stav párování (stav_parovani), způsob párování (zpusob_parovani) a částku, kterou zbývá uhradit (zbyva_uhradit). U položky „zbývá uhradit“ můžeme polemizovat, zdali to není duplicitní zadání dat a mělo by to být dopočítáváno. Z praktického hlediska a jednoduššími manipulací s daty byl zvolen pevný záznam. Detailní návrh modelu je zobrazen na obrázku Obrázek 12 - Datový model – Banka.

Obrázek 12 - Datový model – Banka

29

Nastavení Datový model v sobě zahrnuje objekty, které jsou vytvářeny v administraci systému, jako je řízení přístupu k aplikaci nebo administrací číselníků (tarify). Detailní návrh modelu je vidět na obrázku 13 – Datový model – Nastavení.

Obrázek 13 - Datový model – Nastavení

Dokumenty Datový model obsahuje jeden objekt pro ukládání elektronických dokumentů. Tvoří společnou vrstvu pro všechny moduly. Jak je vidět na obrázku 14 – Datový model – Dokumenty datový objekt el_dokumenty má dva primární klíče. První primární klíč identifikátor elektronického obrazu dokumentu, který je generován automaticky databází

díky

příznaku

atributu

pro

auto-inkrementální

zakládání

záznamu.

Druhý primární klíč je identifikátor objektu, ke kterému elektronický dokument přísluší. Detailní návrh modelu je vidět na obrázku 14 – Datový model – Dokumenty.

Obrázek 14 - Datový model – Dokumenty

30

4 Použité technologie Kapitola obsahuje popis výběru použité technologie (programovacího jazyka a databázového serveru) pro realizaci projektu s jejich stručnými charakteristikami.

Programovací jazyk Pro realizaci projektu přicházely do úvahy programovací jazyky C, C++, C#, PHP, Java. Výběr byl proveden na základě několika osobních kriterií (spíše pocitových než objektivních): •

srozumitelnost jazyka,

•

objektová povaha jazyka,

•

dostupnost a kvalita vývojového prostředí,

•

budoucí přínos s rozšířením znalostí v daném jazyku.

Pro tento projekt byl vybrán C# na platformě .Net Framework.

Databázový server Pro realizaci projektu přicházely do úvahy databázové server: PostgreSQL, MySQL, Express MS server, Oracle, Informix. Databázový server byl vybírán z několika kriterií: •

licenční politika,

•

multiplatformní (provoz možná UNIX/Linux/MS Windows),

•

komfortní instalace pomocí instalátoru,

•

pokročilé nástroje pro vizuální práci s návrhem databáze,

•

využívá SQL jazyk pro práci s daty,

•

osobní zkušenost s jeho instalací a provozem.

Na základě výše uvedených kritérií byl vybrán server MySQL (verze 5.7.7-rc-log). Instalace probíhá formou msi balíčku, který je k dispozici ke stažení na stránkách poskytovatele serveru: http://dev.mysql.com/downloads/windows/installer/. Databázový server existuje v několika základních variantách Enterprice a jejich dalších odnoží nebo Community. Pro naše potřeby využíváme verzi Community, která v sobě 31

nezahrnuje různé placené nadstavby a podpory. Tento aspekt by byl důležitý, v případě pokud by databázový server byl využíván na strategickém projektu, kde je vysoká závislost na produktu a jeho neustále podpoře v případě problémům na úrovni databázového stroje. V rámci instalačního balíčku jsou dostupné nástroje: MySQL Installer, MySQL Connectors, MySQL Workbench atd. Pomocí MySQL Installeru se provede vlastní instalace serveru, kde probíhá i základní administrace jako je volba typu komunikace, zadání hlavního uživatele a dalších možných uživatelů atd. MySQL

Connectors

obsahuje

ovladače

pro

připojení

k databázi

z určitého

programovacího jazyka např.: .Net, Java, Python, C/C++. Velice zajímavou nadstavbou je MySQL Workbench, pomocí kterého je možné provádět následující operace jak s datovým modelem, tak i s databází: •

návrhy datových modelů (EER modely) a poté tyto návrhy převést do databáze pomocí synchronizačního nástroje,

•

standardní SQL dotazy,

•

administrace databází,

•

databázové migrace.

V rámci projektu nebylo využito pouze operace pro databázové migrace.

32

5 Koncept realizace projektu V kapitole si představíme základní koncept rozdělení a logiku projektu. Aplikace je postavena na níže uvedených vrstvách: •

databázová

•

datová,

•

logická,

•

prezentační.

Logika je držena pro každý jednotlivý moduly aplikace.

5.1 Databázová a datová vrstva Databázová a datová vrstva se do určité míry prolínají. Datová vrstva zahrnuje práci s daty a ty jsou za pomocí datových objektů a posléze přenášeny do databáze prostřednictvím databázové vrstvy. Otevření spojení probíhá z pevného nastavení připojovacího řetězce, který je definován v inicializační metodě volané v kontruktoru třídy obsluhující vlastní připojení k databázi. Zvláštním výstupním rysem metody je, že nejenže provede otevření spojení, ale i zároveň funguje jako test, zdali je spojení otevřeno nebo ne.

Obrázek 15 - Datová vrstva - Ukázka metody otevírající spojení s databází

33

Po otevření spojení jsou dostupné následující operace s databází vyobrazené na obrázku Obrázek 15 - Datová vrstva - Ukázka metody otevírající spojení s databází.

Obrázek 16 – Databázová vrstva – Ukázky operací nad databází

Metody tříd pracující v datové vrstvě jsou navrženy jako statické nebo nestatické, dle charakteru práce s daty. Pokud se jedná o obecné vyhledání dat (select) je použit statický model metod. Pokud se pracuje v režimu změny dat (insert, update, delete) je použito nestatických metod v rámci dané třídy. Operace pracující se změnou dat (insert, update, delete) s rozsáhlejšími databázovými operacemi jsou použity v tzv. transakčním režimu, který zaručí konzistenci dat celé jedné operace. Například, pokud probíhá insert do více databázových tabulek a jedna s operací nad danou tabulkou nedopadne dobře (dojde k chybě), provede se navrácení do původního stavu před provedením operace. Pomocí tohoto mechanismu nemůže dojít k vytvoření nekonzistenci v datech.

Obrázek 17 - Databázová vrstva - Zahájení transakce

34

Výměna dat probíhá pomocí takzvaných datových objektů definovaných ke každému modulu (např. Data_Subjekt), které sebou nesou příslušné vlastnosti. Z datového objektu se budují SQL řetězce. Na úrovni datového objektu Data subjekt je využit generický objekt, umožňující přenést více datových objektů Data_Adresy. Ukázka datového objektu je zobrazen na obrázkuObrázek 18 - Datová vrstva - Datový objekt Subjektu.

Obrázek 18 - Datová vrstva - Datový objekt Subjektu

Naplněním vlastností datového objektu dochází i k naplnění atributů pro SQL řetězce, které se poté předají objektu komunikující s databází. Zajímavostí je využití zřetězeného dotazu pro vložení dat do databáze (insert) a vzápětí spuštění speciálního SQL dotazu pro získání identifikátoru záznamu vzniklý auto inkrementálním vlastností daného sloupce v databázi. Tento speciální příkaz je pro různé databázové servery odlišný. V našem případě pro MySQL databází má formu ukázaném na obrázku Obrázek 23 – Databázová vrstva – Insert, zobrazující celé provedení příkazu insert do databáze. Metoda dostane na vstup sestavený SQL řetězec vzniklý v datovém objektu. Výstupem metody v případě kladného založení záznamu je vlastní identifikátor záznamu. Pokud operace nedopadne, metoda vrací hodnotu -1, která je ošetřena v try-catch konstrukci.

35

Obrázek 19 - Databázová vrstva - Insert

5.2 Logická vrstva Logická vrstva zahrnuje metody zpracovávající dat v aplikaci, které jsou předány z datové vrstvy nebo z prezentační vrstvy a zpět. Vytváří převodní most v komunikaci s databází

a

aplikací.

Aby

bylo

možné

pracovat

s databázovým

spojením

bez duplicitního vytváření kódu, je využitá vlastností objektového jazyka C# a dědění (inheritance), prostřednictvím které jsou dostupné databázové operace.

Obrázek 20 - Datová vrstva – Dědění

Před každou operací s databází je provedeno otevření spojení s databází. Pokud se provádí hromadné operace, tak se spojení otevře jednou před zahájením provedení operací a po ukončení všech operací se uzavře. Pokud bychom otevíraly a zavíraly spojení při každé jednotlivé operaci, dochází k značnému zpomalení chodu aplikace. Skutečnost jsem si ověřil při načtení bankovního výpisu, kde časový rozdíl byl značný.

36

Pro dané otevřené spojení s databází je zapnut transakční režim. Po pozitivním nebo negativním provedení aktivní operace (insert, update nebo delete) v databázi dojde k pokusu o provedení potvrzení operací v databázi („komitu“) danou transakci. Pokud se „komit“ nepodaří provést, dojde k vytvoření a zachycení výjimky a následnému provedení vrácení operací s daty zpět („rollbecku“). Po kladném i záporném provedení transakce se vždy provede uzavření spojení. Tento mechanismus je aplikován na všechny aktivní operace s daty (insert, update a delete). V kontrolerové vrstvě dochází k získání jednotlivých položek objektů, tak i objektů, které jsou schopny nést obraz databázových tabulek. Ukázka aktivní operace uložení jednotlivé položky v databázi a je vyobrazena na obrázku níže (Obrázek 21 - Logická vrstva - Uložení jednotlivé položky v transakčním zpracování)

Obrázek 21 - Logická vrstva - Uložení jednotlivé položky v transakčním zpracování

Metoda dostává na vstup datový objekt, který je v části try – catch rozdělen podle toho, zdali se má provést založení položky v databázi nebo provedení aktualizace existující položky v databázi. V tom případě se vyhodnocuje naplnění hodnoty v datovém objektu smlouva.IdSmlouvy zdali je null nebo je přiřazen identifikátor smlouvy. 37

V případě získání hromadného objemu dat bylo využito objektu DataTable, který se dále předává do prezentační vrstvy. Ve většině případů do objektů DataGridView k zobrazení seznamů. V prvním kroku je vytvořen datový objekt DataTable. V druhém kroku se provede otevření spojení s databází. Po otevření spojení s databází se provede operace Select(Data_Smlouva.getSelectQuery())

plnící

object

MySQLDataReaderu.

Pokud je DataReader naplněn daty, dojde k převedení dat do datového objektu DataTable, který se poté předá prezentační vrstvě. U pasivních operací není použito transakčního režimu komunikace s databází, protože nemůže dojít k vytvoření nekonzistentních dat. Ukázku použití je možné vidět na obrázku 22 – Logická vrstva – Získání hromadných dat z databáze. Nejsložitější operace jsou prováděny v rámci výpočtu párování a odpárování v bance. Ukázka je vyobrazena na obrázku 23 – Logická vrstva – Ukázka metody párování. Na obrázku je vidět složitost triviálního požadavku na ruční spárování předpisu a platby. Mechanismus párování je vytvořen na základě vývojového diagramu popsaném v kapitole Realizace projektu – Modul Banka obrázek vývojového diagramu (Obrázek 45 - Vývojový diagram - Ruční párování). Jedna část je rozhodovací logika a druhá část je vlastní plnění dat se zapojením inicializačních metod jak je vidět na obrázku 24 – Logická vrstva - Ukázka metody párování dle podmínky. Aktualizace data je řešena metodami InicializaceDataPlatby() a InicializaceDataParovani(). Ukázka inicializační metody platby je zobrazena na obrázku 25 – Logická vrstva – Inializační metoda. Metoda na vstup dostane potřebné hodnoty pro nastavení položky platby pro provedení úkonu spárování platby s předpisem.

38

Obrázek 22 - Logická vrstva - Získání hromadných dat z databáze

39

Obrázek 23 – Logická vrstva - Ukázka metody párování

Obrázek 24 – Logická vrstva - Ukázka metody párování dle podmínky

Obrázek 25 - Logická vrstva - Inicializační metoda

40

5.3 Prezentační vrstva Celý grafický vzhled aplikace je postaven na tzv. MDI (Multiple – Document Interface) aplikaci. V praxi to znamená, že můžeme mít otevřené větší množství dokumentů v rámci jedné aplikace. Základní okno aplikace je v inicializační metodě nastavena příznakem označující hlavní okno: isMdiContainer = true , který tvoří rámec pro další formuláře či dialogy vyvolané z aplikace. Každému dalšímu formuláři nebo dialogu vyvolaného z aplikace je přidán příznak, který říká kdo je jeho rodičem, tj. bude zobrazen v hlavním kontejneru. Tento příznak je například nastaven takto: formSubjekt.MdiParent = this.mdiContainer. V hlavním okně může být otevřen pouze právě jeden seznam (agendou seznam). Nemůže se stát, že v aplikaci si uživatel vyvolá několik stejných seznamů smluv. Kontrolu provádí metoda: private

void openFormOnMainForm(Form form).

Obrázek 26 - Prezentační vrstva – Kontrola znovu otevření seznamu

Prezentační vrstva v sobě zahrnuje uživatelské rozhraní např. formuláře, dialogy obsahující standardní komponenty pro projekty psané pomocí WF (Windows Form): •

formuláře (Forms), dialogy (Dialogs),

•

menu (ToolStripMenuItem),

•

popisy (Label), políčka (TextBox), víceřádkové políčka (RichTextBox),

•

tlačítka (Button),

•

přepínače (RadioButton), zatrhávací políčka (CheckBox),

•

datové mřížky (DataGridView). 41

Obrázek 27 - Prezentační vrstva – Ukázka MDI aplikace

Zobrazení

seznamu

je

provedeno

v DataGridView.

Vyhledávání

probíhá

nad zobrazenými daty pomocí metody pro fulltextové vyhledávání. Metoda pro fulltextové vyhledávání je použita pouze na sloupce typu string. Ukázka takové metody je zobrazena na obrázku 28 – Prezentační vrstva – Ukázka filtrování. Metoda zobrazena na obrázku 28 – Prezentační vrstva – Ukázka filtrování dostává na vstup parametry, podle kterých poté seskládá vyhledávací řetězec, obdoba SQL řetězce pro databázi pracující s SQL jazykem. Seskládaný řetězec je poté předán do připravené objektu BindingSource a jeho vlastnosti Filter, která provede přefiltrování zobrazených dat. Takto připravená data jsou předána do zobrazovacího objektu DataGridView.

42

Obrázek 28 - Prezentační vrstva – Ukázka filtrování

43

6 Realizace projektu V kapitolách Realizace projektu jsou podrobně posnány jednotlivé části aplikace. Projekt je rozdělen do logických částí zobrazeném na obrázku 29 – Projekt – MES. Součástí projektu jsou základní knihovny .Net Frameworku, které jsou umístěny do části References. Popis částí projektu je umístěn pod obrázkem Obrázek 29 – Projekt – MES.

Obrázek 29 - Projekt – MES

44

Data obsahuje statické metody, které umožňují převádět datový typ string na decimal či konverze řetězce na datový typ long. Database obsahuje třídy pro práci s databází a tvoří databázovou vrstvu aplikace. Forms obsahuje formulář hlavního okna aplikace, přihlašovacího okna a základní formulář, ze kterého jsou děděny další formuláře v modulech. Základní formulář je přenášena vlastnost o nastavení rodičovského MDI kontejneru a zároveň nese metody pro validaci hodnot v textových políčkách obsahující datum. Icons obsahuje seznam ikon použité v aplikaci. Moduly

obsahuje

realizaci

jednotlivých

modulů.

V rámci

každého

modulu

jsou obsaženy složky pro formuláře, kontrolery a datové objekty. Zvláštním modulem je modul Dokumenty, který se stará o společnou vrstvu všech modulů obsluhující přidání a odebrání elektronických příloh. Tisk řeší problematiku tisku seznamů. Součástí projektu je konfigurační soubor (App.config), nesoucí některé administrační údaje. Tento soubor je ovládán v modulu Nastavení. V rámci každého modulu jsou definovány datové objekty, controlery a prezentační objekty dle navržené logiky jak je vyobrazeno na obrázku Obrázek 27 – Projekt – MES.

6.1 Přihlášení do aplikace a hlavní okno aplikace Pod kapitoly popisují jakým způsobem je řešen vstup do aplikace a jak je rozvrženo hlavní okna aplikace.

6.1.1 Přihlašovací okno Kapitola popisuje proces přihlašování a ověření uživatele před vstupem do aplikace. Po spuštění aplikace je vyvolán dialog pro zadání login a hesla. Předpokladem koretního přihlášení do databáze je správně nastavený konfigurační soubor v části pro připojení k databázovému serveru (server, databáze, uid atd.).

45

Obrázek 30- Realizace projektu - Login

Ověření probíhá vůči databázi, kde jsou uložení uživatelé s jejich loginy a hesly. Administrace se provádí pomocí modulu Nastavení – Správa uživatelů. Pokud ověření nedopadne, uživatel není vpuštěn do aplikace a je upozorněn, že nezadal správné uživatelský login nebo heslo. Záměrně není specifikována chybná hodnota. Kvůli bezpečnosti je heslo zobrazeno symboly „*“. Z programového hlediska byl problém řešen co nejjednodušší cestou. Před inicializační metodou hlavního okna programu byl vsunut formulář s přihlašovacími údaji. Zde je vyhodnoceno, zdali proběhlo správné ověření uživatele. Pokud neproběhlo ověření, aplikace se ukončení a nedojde ke spouštění hlavního okna.

Obrázek 31 - Realizace projektu – Přihlašovací okno

6.1.2 Hlavní okno aplikace Hlavní okno aplikace je rozděleno do dvou částí: •

menu,

•

zobrazovací plocha pro jednotlivé moduly.

46

Obrázek 32 - Realizace projektu - Nastaveni organizace Hlavní okno aplikace

V menu jsou dostupné volby: Aplikace (Nastavení, ukončení aplikace – Konec), Adresář, Smlouvy, Banka, Pošta, Okna a Nápověda. Téměř každá z voleb otevírá samostatný modul. Specifické volby jsou pouze Okna a Nápověda. Volba Okna má možnost uspořádat spuštěná okna v rámci MDI kontejneru (vertikální, horizontální a kaskádové rozložení oken v základním kontejneru), Pomocí

volby

Nápověda

se

v aplikaci

vyvolá

nápověda

(PDF

soubor),

která je definována v Nastavení – Systémové cesty – Cesta k dokumentaci. Pro ukončení aplikace je uživatel vyzván, zdali opravdu chce ukončit práci v aplikaci a aplikaci uzavřít.

6.2 Modul Nastavení Modul

slouží

k provedení

základní

administrace

systému.

Jeho

specifikou

je, že částečně je administrace uložena do konfiguračního souboru (App.config) a částečně pracuje s databází.

Nastavení popis organizace Nastavení popisu organizace se ukládá do předem připraveného konfiguračního souboru. Uživatel může libovolně měnit nastavení, které se poté uloží pomocí funkce uložit (tlačítko Uložit). Odstranění položky se provede smazáním daného políčka a uložení formuláře.

47

Obrázek 33 - Realizace projektu - Nastavení organizace

Nastavení číselníků tarifů V rámci nastavení je možné spravovat číselník tarifů. Tarify jsou využívány při zpracování smluvních vztahů, pokud se jedná o specifickou smlouvu pro poskytnutí služby. Realizace nastavení je vidět na obrázku 34 – Realizace projektu – Nastavení číselníku tarifů.

Obrázek 34 - Realizace projektu - Nastavení číselníku tarifů

48

Nastavení systémových cest V rámci nastavení systémových cest se ukládají: •

nastavení cesty k dokumentaci,

•

nastavení cesty k ukládání elektronických příloh na disk.

Nastavení cesty k dokumentaci bylo zvoleno takto, aby bylo možné vytvářet například uživatelské dokumentace a tato dokumentace byla nezávislá od verze programu. Do budoucna bude vhodné rozdělit dokumentace jako systémovou a uživatelskou. Dokumentace systémová by byla distribuována spolu s aplikací a uživatelská dokumentace by byla vytvářena případně uživateli aplikace. Nastavení uživatelské cesty k ukládání souboru je pro účely ukládání elektronických příloh, které jsou ukládány do souboru ne do databáze. Do databáze se ukládá pouze jejich hlavička a identifikátor.

Obrázek 35 - Realizace projektu - Nastavení systémových cest

49

Správa uživatelů V části Správa uživatelů je možné přidávat a odebírat uživatele, kteří mohou vstoupit do aplikace a pracovat s jednotlivými moduly. Základní administrace uživatelů je vytvořena v co nejjednodušší formě, tj. obsahuje jméno, příjmení uživatele, login a heslo. Při uložení uživatele je ověřeno zadání uživatelského hesla dvojím zadáním a ověřením vůči sobě. Smazání uživatele je záměrně posunuto až do detailu uživatele, tak aby bylo zřejmé, jaký uživatel je odstraněn.

Obrázek 36 - Realizace projektu - Nastavení správy uživatelů

Dalším rozšířením se může být šifrované ukládání hesla do databáze s šifrovanou komunikací. Co se týče rozšíření Správy uživatelů, tak může dojít k řízení přístupů k jednotlivým modulům s právy provádět určité typy operací, např. možnost pouze nahlížet do modulů bez možnosti měnit data nebo pracovat pouze ve vybraných modulech, tak aby mohla být podporována plná metodika rozdělení práce v aplikaci.

50

6.3 Modul Adresář Kapitola popisuje realizaci modulu Adresář s vysvětlením a logikou ovládání jednotlivých částí. V modulu Adresář jsou dostupné dvě úrovně pohledů: seznam evidovaných subjektů a detail subjektu. Po vybrání volby „menu: Adresář“ se zobrazí seznam evidovaných subjektů v adresáři. Nad seznam a v detailu dokladu jsou dostupné následující operace: •

přidání, editace, smazání – seznam,

•

tisk – seznam,

•

uložení, editace a smazání – detailu.

Obrázek 37 - Realizace projektu - Adresář

51

Po spuštění modulu Adresář dojde k načtení kompletního adresáře z databáze a načtením dat do objektu DataGridView. Před zobrazením dat jsou využity filtry, které umožňují převedení dat číselníkových hodnot do standardních slovních popisů. Například, pokud je daný subjekt plátce DPH, je hodnota v datech uložena jako 0 (neplátce) nebo 1 (plátce). Základní operace s položkami jsou definovány na tlačítka nad seznamem. Pomocí těchto tlačítek lze přidat, editovat nebo smazat danou položku. Položku lze smazat, pouze tehdy, pokud není ani není navázána smlouva. Pokud bychom dovolili smazat takový subjekt, neměli bychom možnost zpět zjistit, s kým byla daná smlouva uzavřena. Na detailu smlouvy se ukládá pouze identifikátor subjektu z adresáře. Po změně dat detailu subjektu a uložení se automaticky občerství seznam dle aktuálních hodnot. Občerstvení seznam probíhá celého seznamu – předpoklad malého množství dat. Pokud bychom pracovali s velkým množstvím dat, bylo by vhodné aktualizovat pouze jednu položku v seznamu a nenačítat znovu celý seznam. Součástí seznamu je fulltextové vyhledávání, které prochází všechny sloupce, které jsou definované

typu

string.

Vyhledávání

probíhá

nad

objektem

DataGridView

ne v databázi. Seznam lze vytisknout do *.csv souboru pomocí tlačítka tisk. Tisknou se data uložené v objektu DataGridView, tj. pokud není seznam přefiltrován, vytiskne se celý seznam. Pokud jsou data zobrazeny dle filtru fulltextového vyhledávání, vytisknou se pouze tyto přefiltrovaná data.

6.4 Modul Smlouvy V modulu je dostupný seznam přehledu smluv. V rámci dané smlouvy je možné vystavovat předpisy k úhradě (obdoba faktur), které jsou posléze odesílány do banky k párování.

52

Nad seznam a v detailu dokladu jsou dostupné následující operace: •

přidání, editace, smazání – položky v seznamu,

•

tisk – seznamu,

•

uložení, editace a smazání – detailu.

•

navázat/odvázat na subjekt evidovaný v modulu Adresář – Detail smlouvy – záložka Smluvní partner,

•

pro danou lze vystavit/smazat předpis (Fakturu) – Detail smlouvy – záložka Faktury,

•

v rámci faktury lze odeslat/ stáhnout předpis k párování.

Na obrázku 38 – Realizace projektu – Smlouvy je vidět náhled na seznam smluv spolu s vybraným jedním detailem smlouvy.

Obrázek 38 - Realizace projektu – Smlouvy

53

Seznam dokladů smluv Po spuštění modulu Smlouvy dojde k načtení kompletního smluv z databáze a načtením dat v objektu DataGridView. Před zobrazením dat jsou využity filtry, které umožňují převedení dat číselníkových hodnot do standardních slovních popisů. Např. pokud je smlouva výdajová v datech uložena jako 10 (výdajová) nebo 20 (příjmová). Nad seznam je vybudován filtr umožňující fulltextové vyhledávání nad řetězcovými sloupci, nebo v datumových polích datum platnosti „Od-Do“. Posledním zabudovaným vyhledáváním je podle typu, zdali je příjmová nebo výdajová. Seznam lze vytisknout do *.csv souboru pomocí tlačítka tisk. Tisknou se data uložené v objektu DataGridView, tj. pokud není seznam přefiltrován, vytiskne se celý seznam. Pokud jsou data zobrazeny dle filtru, vytisknou se pouze tyto přefiltrovaná data. Detail dokladu smlouvy V detailu dokladu lze vyplnit základní atributy smlouvy. Při uložení jsou striktně kontrolovány pouze správné formáty datumů a to zdali datum platnosti Od, je větší než datum platnosti Do. Jiná omezení na uložení hlavičky smlouvy nejsou. Na záložce Smluvní partner v detailu smlouvy lze pomocí tlačítka

přidat

smluvního partnera. Výběr je proveden z vyvolaného seznamu Adresáře dvojklikem na vybranou položku. Odebrání smluvního partnera se provede pomocí tlačítka

.

Po odebrání smluvního partnera se provede aktualizace detailu dokladu. Tlačítko pro odebrání subjektu je aktivní, pouze pokud je navázán smluvní partner. Na záložce Faktury lze založit nový předpis (forma pseudofaktury – nenese kompletní náležitosti faktury). Odstranění faktury je možné pouze z detailu faktury, aby si uživatel pořádně přečetl obsah faktury a že ji opravdu odstranit. Záložka Poznámka slouží k uložení doplnění doplňujících informací k danému smluvnímu vztahu. Informace není povinná, má určité datové omezení. Detail smlouvy je vyobrazen na níže (Obrázek 39 - Realizace projektu - Detail smlouvy seznam faktur).

54

Obrázek 39 - Realizace projektu - Detail smlouvy seznam faktur

Detail předpisu Detail předpisu je vyobrazen na obrázku níže (Obrázek 40 - Realizace projektu Smlouvy - Detail předpisu). Pomocí tlačítka „Nová“ vyvolá detail předpisu pro vyplnění základních atributů předpisu a je mu automaticky přiřazeno ID smlouvy. Pokud není uložen předpis do databáze, není mu přiřazen jeho interní identifikátor. Po uložení do databáze dostane svůj interní identifikátor a aktivuje se tlačítko pro smazání dokladu. Při uložení se neprovádí žádná formální kontrola na data. Pro otevření existující předpisu je nutné vybrat myší řádek v seznamu položek a použít tlačítko Detail pro otevření vybraného předpisu. Řádek, který je aktuálně vybraný je podbarven modře. Odstranění předpisu je záměrně zařazeno až do detailu předpisu, tak aby si uživatel uvědomil, že maže tento daný doklad a nedocházelo k chybnému odstranění záznamu. Záznam je odstraněn z dat. Otázka je, zdali by nebylo výhodnější záznam ponechat a pouze mu nastavovat aktivitu, aby bylo možné se případně podívat na zneplatněný záznam. 55

Obrázek 40 - Realizace projektu - Smlouvy - Detail předpisu

Ukázka přehledu plateb k danému předpisu je vyobrazena na obrázku výše (Obrázek 40 - Realizace projektu - Smlouvy - Detail předpisu). Pro odeslání k párování do banky je nutný pouze jediný atribut a to je částka. Pokud není částka vyplněna, nelze odeslat k párování. Systém o této skutečnosti informuje formou chybového dialogu.

Obrázek 41 - Realizace projektu - Chyba při odeslání platby do banky

Pokud je odesláno do banky a ID platby se rovná nule, je možné provést opětovné stažení. V opačném případě je nutné provést odpárování v bance a poté je možné provést odpárování. Uživatel o této skutečnosti je informován chybovým dialogem. 56

6.5 Modul Banka Kapitola popisuje realizaci modulu Banka s vysvětlením a logikou ovládání jednotlivých částí. Součástí agendy banka jsou dvě základní operace: •

nahlížení a import bankovního výpisu do databáze,

•

párování plateb s vystavenými párovacími předpisy.

6.5.1 Nahlížení a import bankovního výpisu Funkce „Výpisy“ pro otevření bankovního výpisu je dostupná po otevření modulu Banka v horní „menu“ v pravé části. Pokud modul Banka není aktivován, není vidět jeho rozšířené menu. Toto chování je základní vlastnost MDI aplikací. Po otevření souboru dojde k zobrazení v okně „Bankovní výpis“. Okno disponuje třemi základními funkcemi: zobrazení bankovního souboru, možnost vyhledání v datech bankovního výpisu bez připojení k databázi, import do databáze.

Obrázek 42 -Realizace projektu - Banka - Import souboru

57

Před provedením importu je provedena kontrola, zdali daný soubor byl již importován do databáze. Pokud kontrola dohledá importovaný soubor v databázi, nedovolí druhé nahrání souboru do databáze. Po provedení importu je možno začít pracovat v okně Banka s párováním nových plateb.

6.5.2 Párování plateb Okno banka je rozděleno do tří částí. V levém dolní části je vyobrazen seznam předpisů k párování. V pravé dolní části okna je zobrazen seznam importovaných plateb z bankovního výpisu do databáze. Nad každým seznamem je vybudován filtr pro vyhledávání dle předpokládaných kriterií V horní části se nachází detaily vybraných položek k manuálnímu párování. Základní operace banky je systém párování plateb s předpisy. Párování dělíme do dvou kategorií: •

automatické,

•

manuální.

Obrázek 43-Realizace projektu - Banka

58

Automatické párování Počáteční ní podmínky pro automatické párování jsou: •

částka předpisu ředpisu je rovna částce zbylé k úhradě platby,

•

variabilní symbol předpisu předpisu je roven variabilnímu symbolu platby,

•

identifikátor platby není vyplněn vypln na předpisu – není spárováno. spárováno

Obrázek 44 - Vývojový diagram - Automatické párování plateb

59

Pokud jsou splněny výše uvedené počáteční podmínky, systém dohledá takové případy a provede následující algoritmus: •

na předpisu doplní identifikátor platby,

•

na položce platby se nastaví částka „zbývá uhradit“ na nulu,

•

nastaví způsob párování na automatické,

•

nastaví se stav úhrady na „uhrazeno“.

Po provedení automatického párování je zobrazeno okno se spárovanými platbami. Seznam spárovaných plateb lze vytisknout do *.csv souboru. Automatické odpárování není uvažováno pro jeho nereálné využití. Ruční párování/ odpárování V rámci ručního párování se pracuje pouze s jednotlivými položkami předpisů a plateb. Výběr dané položky se provede dvojím poklepáním do seznamu předpisů a plateb. Obsah jednotlivých výběrů se přenese do oblasti určené pro párování. Podle obsahu položky předpisu se aktivují tlačítka pro párování či odpárování. Pokud se jedná o párování, nesmí být vyplněn identifikátor platby a zároveň nesmí být platba uhrazena a naopak. Při ručním párování předpisu mohou nastat tři algoritmy: 1. částka předpisu se rovná částce napárované platby, 2. částka předpisu je nižší než částka platby, 3. částka předpisu je vyšší než částka platby. První algoritmus – ALG 1 je totožný s automatickým párováním zobrazeném na obrázku 44 – Vývojový diagram – Automatické párování plateb, kdy se provedou následující operace: •

na předpisu doplní identifikátor platby,

•

na položce platby se nastaví částka „zbývá uhradit“ na nulu,

•

nastaví způsob párování na automatické,

•

nastaví se stav platby na „uhrazeno“.

60

Druhý algoritmus – ALG 2 (částka předpisu je nižší než částka ástka platby): platby) •

na předpisu edpisu doplní identifikátor platby,

•

na položce platby se odečte ode částka předpisu edpisu od „zbývá uhradit“ platby,

•

nastaví způsob ůsob párování na „ruční“, „ru

•

nastaví se stav platby na „částečně „ uhrazeno“.

Obrázek 45 - Vývojový diagram - Ruční párování

Třetí algoritmus – ALG 3 (částka předpisu je vyšší než částka ástka platby): platby) •

na předpisu edpisu doplní identifikátor platby,

•

na položce platby se nastaví částka „zbývá uhradit“ na nulu,

•

nastaví způsob ůsob párování na „ruční“, „ru

•

nastaví aví se stav platby na „uhrazeno“,

•

založí se nový předpis předpis se stejným identifikátorem párován, ale s novým identifikátorem párování s částkou, kde se odečte částka platby od částky předpisu.

61

Při ručním odpárování předpisu mohou nastat tři algoritmy, které odpovídají opačným opeací provedených při párování: 1. částka předpisu se rovná částce napárované platby, 2. částka předpisu je nižší než částka platby, 3. částka předpisu je vyšší než částka platby. První algoritmus (částka předpisu se rovná částce napárované platby): •

na předpisu doplní nulový identifikátor platby,

•

na položce platby se nastaví částka „zbývá uhradit“ na částku předpisu,

•

nastaví způsob párování na „nespárováno“,

•

nastaví se stav platby na „neuhrazeno“.

Druhý algoritmus (částka předpisu je nižší než částka platby): •

předpisu doplní nulový identifikátor platby,

•

na položce platby se přičte částka předpisu k „zbývá uhradit“ platby,

•

nastaví způsob párování na „nespárováno“,

•

nastaví se stav platby na „částečně uhrazeno“.

Třetí algoritmus (částka předpisu je vyšší než částka platby): •

na předpisu doplní nulový identifikátor platby,

•

na položce platby se nastaví částka „zbývá uhradit“ přičtením částky platby,

•

nastaví způsob párování na „nespárováné“,

•

nastaví se stav platby na „neuhrazeno“,

•

pokud předpis byl částečně párován, tak existuje právě jedna nespárovaná položka. Tato položka se dohledá, napočte se na ni částka odporované položky a původní položka se vymaže.

62

7 Testování Kapitola představuje koncept testování aplikace. Testy jsou postaveny logické sletu, jak by je uživatel měl využívat. Testování bude probíhat na základě pracovních postupů definovaných v manuálu k aplikaci Manuálu Malého ekonomického systému (MES). •

Test 1 - Nastavení MES: o Nastavení konfiguračního souboru pro připojení k databázi, o Ověření přístupů pomocí administrátorského účtu, o Vyplnění a uložení údajů o organizaci, o Nastavení systémových cesty k dokumentaci a ke složce pro přílohy, o Připravení základních tarifů v části číselníky, o Vytvoření uživatelů, kteří mohou pracovat v aplikaci. o Ověření přihlášení uživatele do aplikace.

•

Test 2 - Práce v modulu Adresář: o Zaevidování nového subjektu, změna subjektu, odstranění subjektu, o Vyhledání subjektu, o Tisk do souboru.

•

Test 3 – Práce v modulu Smlouvy: o Vytvoření smlouvy, editace a odstranění smlouvy, o Navázání subjektu, odstranění subjektu u uložené smlouvy, o Přidání a odebrání přílohy u uložené smlouvy, o Vytvoření/Odstranění předpisu, Odeslání/Stažení předpisu do/z banky, o Vyhledávání mezi smlouvami, o Tisk do souboru.

•

Test 4 – Práce v modulu Banka: o Načtení bankovního výpisu, o Načtení seznamu předpisů a plateb, o Automatické párování, o Ruční párování vybraných položek, o Ruční odpárování předpisu.

63

8 Závěr V rámci práce se podařilo dosáhnout stanoveného cíle a vytvořit aplikace. V rámci aplikace byl vybudován mechanismus autentizace do systému, která probíhá formou ověření loginu a přihlašovacího hesla přiřazenému danému uživateli v databázi. Součástí aplikace jsou systémové moduly Nastavení a Dokumenty. V modulu Nastavení je možné vytvořit popis organizace využívající aplikaci, založit číselník tarifů, přiřadit systémové cesty a pracovat s přístupy uživatelů do systému. Modul Dokumenty vytváří společnou virtuální vrstvu, kde se ukládají elektronické dokumenty. Moduly Adresář, Smlouvy, Banka a Dokumenty tvoří komplexní

1

workflow vznikajících smluv

se smluvními partnery. Na těchto smlouvách je možné sledovat jednotlivé fakturační plnění. V modulu Banka je možné párovat fakturační plnění vůči bankovním transakcím, které jsou do systému nahrávány prostřednictvím bankovního výpisu dle bankovního standardu ABO-K. Seznamy disponují filtry, pomocí kterých je možné v jednotlivých agendách vyhledávat. Na vybraných seznamech je možné provést tisk dat do souboru (*.csv). Na úrovni banky jsou detailně rozpracovány algoritmy párování plateb a odpárování plateb. Algoritmy jsou implementovány do aplikace. Aplikace nebyla ještě uvedena do běžného provozu, je ve stádiu alfatestování, kde se budou ladit případné nesrovnalosti. Vzhledem k tomu, že je to můj první samostatně naprogramovaný projekt, tak jsem se pokoušel využít co nejširší možnosti programovacího jazyka C#. V průběhu realizace projektu jsem stále narážel na nové programovací techniky. V projektu jsem si stanovil přesnou strategii psaní kódu (rozdělení aplikace do vrstev). Tuto strategii jsem držel v průběhu psaní celého projektu. Pozitivním přínosem práce bylo, nahlédnutí do zákoutí objektově - orientovaného programování, a to návrhových vzorů v C# a to mi rozšířilo pohled na práci s objekty v různém pojetí návrhových vzrorů. V plánu rozvoje aplikace by měla být agenda Pošta. Agenda by spracovávala příchozí poštu včetně možnosti uložení elektronického obrazu dokumentu, termín vyřízení a přiřazení osoby jejího vyřízení.

1

Význam slova v tomto kontextu znamená: správu v čase evidovaných smluv

64

Dalším rozšířením aplikace je vypracování hromadných operací nad specifickými smluvními případy, kdy bude možné hromadně vygenerovat předpisy s přímým odesláním k párování do banky. Po úspěšném vygenerování předpisů a založení párování by mohlo dojít k hromadnému vygenerování elektronického obrazů předpisů, které by mohly být odeslána na e-mail smluvního partnera. Jedním

z

možných

rozšíření

by

mohlo

být

napojení

na

registry,

které je doporučené sledovat v rámci sjednávání smluvních vztahů a i následného odvádění DPH, např. Registru insolvencí, Registru DPH na kontrolu bankovních účtů, Registrů obyvatel, ARES atd. Zásadním bezpečnostním vylepšením je vybudování šifrovaného spojení s databází včetně šifrovaného uložení informací o uživateli systému a jeho autentizace. V bakalářské práci jsem si ověřit jak složité je vytvoření aplikace komplexnějšího malého ekonomického systému včetně jeho praktické realizace. Správně provedená analýza vede k jednoznačnému řešení. Pokud jsem zanedbal určité části návrhu, tak v části realizace (programování) se mi to vymstilo vícenásobnou ztrátou času či zpětného přeprogramování kódu.

65

Seznam použité literatury [1] MCCONNELL, Steve. Dokonalý kód: umění programování a techniky tvorby software. Vyd. 1. Brno: Computer Press, 2005, 894 s. ISBN 80-251-0849-X. [2]

SELLS,

Chris.

C#

a

Winforms:

programování

formulářů

windows.

Vyd. 1. Brno: Zoner Press, 2005, 648 s. ISBN 80-868-1525-0. [3] KADLEC, Václav. Agilní programování: metodiky efektivního vývoje softwaru. 1. vyd. Brno: Computer Press, 2004, 278 s. ISBN 80-251-0342-0. [4] RICHTA, Karel. Metodiky vývoje software, MDA: Metodiky vývoje software. 2011. vyd. Praha: ČVUT, 2011. [5] POPELKA, Vladimír. Srovnávací analýza metodik vývoje software: Bakalářská práce. Praha, 2009 [cit. 2015-02-03]. Bakalářská práce. Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb. Vedoucí práce PhDr. Helena Kučerová. [6] Wikipedie: Otevřená encyklopedie. Normalizace databáze [online]. [cit. 2015-0203]. Dostupné z: http://cs.wikipedia.org/wiki/Normalizace_datab%C3%A1ze [7] Wikipedie: Otevřená encyklopedie. MySQL

[online]. [cit. 2015-08-24].

Dostupné z:

https://cs.wikipedia.org/wiki/MySQL [8] BISHOP, J. C#: návrhové vzory. Vyd. 1. Brno: Zoner Press, 2010, 328 s. Encyklopedie Zoner Press. ISBN 978-80-7413-076-2. [9] WATSON, Ben. C# 4.0: řešení praktických programátorských úloh. Vyd. 1. Brno: Zoner Press, 2010, 656 s. Encyklopedie Zoner Press. ISBN 978-80-7413-094-6. [10] GOUSSET, Mickey. Řízení životního cyklu aplikací ve Visual Studiu 2010: řešení praktických programátorských úloh. Vyd. 1. Brno: Zoner Press, 2010, 671 s. Encyklopedie Zoner Press. ISBN 978-80-7413-102-8. [11]

SCHMULLER,

Joseph. Myslíme

v

jazyku

UML:

řešení

praktických

programátorských úloh. 1. vyd. Praha: Grada, 2001, 359 s. Knihovna programátora (Grada). ISBN 80-247-0029-8.

66

Seznam obrázků Obrázek 1 - Ukázka programu Pohoda ............................................................................. 9 Obrázek 2 - Ukázka programu ISP Servis ...................................................................... 10 Obrázek 3 – Ukázka programu ISP Admin .................................................................... 11 Obrázek 4 -Stavový diagram - Průběh pořízení dat ........................................................ 15 Obrázek 5 - Vývojový diagram - Párování plateb .......................................................... 20 Obrázek 6 - Diagram užití – Adresář .............................................................................. 22 Obrázek 7 - Diagram užití – Smlouvy ............................................................................ 23 Obrázek 8 - Diagram užití - Banka ................................................................................. 24 Obrázek 9 - Diagram užití - Nastavení ........................................................................... 25 Obrázek 10 - Datový model – Adresář ........................................................................... 27 Obrázek 11 - Datový model – Smlouvy ......................................................................... 28 Obrázek 12 - Datový model – Banka.............................................................................. 29 Obrázek 13 - Datový model – Nastavení ....................................................................... 30 Obrázek 14 - Datový model – Dokumenty .................................................................... 30 Obrázek 15 - Datová vrstva - Ukázka metody otevírající spojení s databází ................. 33 Obrázek 16 – Databázová vrstva – Ukázky operací nad databází .................................. 34 Obrázek 17 - Databázová vrstva - Zahájení transakce ................................................... 34 Obrázek 18 - Datová vrstva - Datový objekt Subjektu ................................................... 35 Obrázek 19 - Databázová vrstva - Insert ........................................................................ 36 Obrázek 20 - Datová vrstva – Dědění ............................................................................. 36 Obrázek 21 - Logická vrstva - Uložení jednotlivé položky v transakčním zpracování .. 37 Obrázek 22 - Logická vrstva - Získání hromadných dat z databáze ............................... 39 Obrázek 23 – Logická vrstva - Ukázka metody párování .............................................. 40 Obrázek 24 – Logická vrstva - Ukázka metody párování dle podmínky ....................... 40 Obrázek 25 - Logická vrstva - Inicializační metoda ....................................................... 40 Obrázek 26 - Prezentační vrstva – Kontrola znovu otevření seznamu .......................... 41 Obrázek 27 - Prezentační vrstva – Ukázka MDI aplikace .............................................. 42 Obrázek 28 - Prezentační vrstva – Ukázka filtrování ..................................................... 43 Obrázek 29 - Projekt – MES ........................................................................................... 44 Obrázek 30- Realizace projektu - Login ......................................................................... 46 Obrázek 31 - Realizace projektu – Přihlašovací okno .................................................... 46 Obrázek 32 - Realizace projektu - Nastaveni organizace Hlavní okno aplikace ............ 47 67

Obrázek 33 - Realizace projektu - Nastavení organizace ............................................... 48 Obrázek 34 - Realizace projektu - Nastavení číselníku tarifů ........................................ 48 Obrázek 35 - Realizace projektu - Nastavení systémových cest .................................... 49 Obrázek 36 - Realizace projektu - Nastavení správy uživatelů ...................................... 50 Obrázek 37 - Realizace projektu - Adresář ..................................................................... 51 Obrázek 38 - Realizace projektu – Smlouvy .................................................................. 53 Obrázek 39 - Realizace projektu - Detail smlouvy seznam faktur ................................. 55 Obrázek 40 - Realizace projektu - Smlouvy - Detail předpisu ....................................... 56 Obrázek 41 - Realizace projektu - Chyba při odeslání platby do banky ........................ 56 Obrázek 42 -Realizace projektu - Banka - Import souboru ............................................ 57 Obrázek 43-Realizace projektu - Banka ......................................................................... 58 Obrázek 44 - Vývojový diagram - Automatické párování plateb ................................... 59 Obrázek 45 - Vývojový diagram - Ruční párování......................................................... 61

68

Seznam tabulek Tabulka 1 - Srovnání software ........................................................................................ 12 Tabulka 2 - Transformační tabulka pro převod z *.GPC ................................................ 18

69

Seznam použitých zkratek C#

Vysokoúrovňový objektově orientovaný programovací jazyk

DIČ

Daňové identifikační číslo

DPH Daň z přidané hodnoty ERP

Komplexní informační systém k efektivnímu řízení firemních zdrojů

IČ

Identifikační číslo

KS

Konstantní symbol

MDI z anglického výrazu Multiple – Document Interface MES Malý ekonomický systém .Net

z anglického výrazu „dotnet“, soubor technologií v softwarových produktech

PHP

Hypertextový preprocesor

PSČ

Poštovní směrovací číslo

VS

Variabilní symbol

SS

Specifický symbol

70

Přílohy 1 Obsah přiloženého CD Na přiloženém CD se v kořenovém adresáři nachází tato bakalářská práce ve formátu bakalarska_prace.pdf s jednoduchým návodem MES_manual.pdf pro obsluhu programu a zakládacího SQL skriptu pro založení databáze mes.sql (založení databáze a založení administrátorského účtu). Součástí přiloženého CD jsou zdrojové kódy aplikace umístěné v kořenovém adresáři v souboru MES.

71

2 Uživatelský manuál aplikace MES

72

Manuál Malého ekonomického systému (MES) Obsah Nastavení aplikace ...................................................................................................................................3 Databázový server................................................................................................................................3 Nastavení aplikace MES .......................................................................................................................3 Adresář .....................................................................................................................................................4 Seznam ................................................................................................................................................. 4 Práce se seznamem ..........................................................................................................................4 Práce se subjektem ..........................................................................................................................5 Smlouvy ....................................................................................................................................................5 Seznam ................................................................................................................................................. 6 Práce se seznamem ..........................................................................................................................6 Práce se smlouvou ...........................................................................................................................6 Banka ........................................................................................................................................................8 Nahrání výpisu .....................................................................................................................................8 Párování plateb ....................................................................................................................................9 Automatické párování ....................................................................................................................10 Ruční párování platby ....................................................................................................................10 Ruční odpárování platby ................................................................................................................10

73

Nastavení aplikace Před spuštěním aplikace jen nutné provést nastavení aplikace MES. Nastavení se provádí dle následujících kroků: 1. Pomocí konfiguračního souboru zobrazeného na obrázku Obrázek 1 – Ukázka konfiguračního souboru. 2. Vlastní nastavení aplikace v modulu Nastavení.

Obrázek 1 - Ukázka konfiguračního souboru

Databázový server Nastavení databázového serveru se provede podle vzorového obrázku Obrázek 2 – Ukázka nastavení databázového serveru. Pokud toto nastavení není korektně založené, nebude možné se připojit do databáze.

Obrázek 2 - Ukázka nastavení databázového serveru

Heslo pro připojení je též nutné zadat.

Nastavení aplikace MES Pro prvotní spuštění aplikace je v databázi vytvořen jeden základní účet, pomocí kterého se vstoupí do aplikace. Účet je login = admin, heslo = admin. Po otevření aplikace je nastavení dostupné v menu: Aplikace: Nastavení: 1. Nastavení interních iniciálu organizace (menu: Aplikace - záložka Organizace), 2. Nastavení číselníků – definice základních Tarifů (menu: Aplikace - záložka Číselníky (Tarify)), 3. Systémové cesty (menu: Aplikace – záložka Systémové cesty): a. Nastavení cesty k dokumentaci, b. Nastavení cesty pro ukládání elektronických obrazů příloh.

74

Adresář V adresáři je možné evidovat partnerské subjekty a údaje o nich. Adresář je dostupný z menu: Adresář, kdy se otevře seznam evidovaných subjektů. Adresář se skládá ze seznamu a detailu subjektu.

Obrázek 1 - Ukázka seznamu a detailu subjektu v Adresáři

Seznam Adresář se skládá ze tří částí: • • • •

Tlačítka pro přidání / editaci / smazání položky v seznamu. Fulltextové vyhledávání (pod tlačítky), pomocí kterého je možné vyhledávat v seznamu. Vlastní seznam evidovaných položek v Adresáři. Tisk (tlačítko ).

Práce se seznamem Ovládání tlačítek Ovládání tlačítek je popsáno v kapitole Práce se subjektem. Vyhledávání Vyhledávání se provede zadáním políčka Fulltext hledaného výrazu a zmáčknutím tlačítka Hledat. Tisk

75

Práce se subjektem Přidání nového subjektu Po zmáčknutí tlačítka v seznamu Adresář se otevře prázdný detail subjektu. Minimální podmínkou pro uložení subjektu je vyplnění příjmení nebo názvu. Editace subjektu Pokud je subjekt uložen v databázi lze jej editovat. Editace se provede vybráním daného řádku kliknutím myši (řádek se potřeb podbarví) a poté se zmáčkne tlačítko , které otevře detail subjektu. Po provedení zamýšlené úpravy se zmáčkne tlačítko

, které uloží změny do databáze.

Smazání subjektu Aby bylo možné subjekt smazat, musí být uložený v databázi. Vlastní smazání subjektu se provede pomocí tlačítka na smlouvě.

v seznamu nebo detailu subjektu. Nelze smazat subjekt, na který je použit

Smlouvy V Smlouvách je možné evidovat partnerské vztahy a údaje o nich. Smlouvy jsou dostupné z menu: Smlouvy, kdy se otevře seznam evidovaných smluv. Smlouvy se skládá ze seznamu a detailu smlouvy.

Obrázek 1 - Ukázka modulu Smlouvy

76

Seznam Smlouvy se skládá ze tří částí: • • • •

Tlačítka pro přidání / editaci / smazání položky v seznamu. Fulltextové vyhledávání (pod tlačítky), pomocí kterého je možné vyhledávat v seznamu. Vlastní seznam evidovaných položek v Adresáři. Tisk (tlačítko ).

Práce se seznamem Ovládání tlačítek Ovládání tlačítek je popsáno v kapitole Práce se subjektem. Vyhledávání Vyhledávání se provede zadáním kriterií pro vyhledávání a zmáčknutím tlačítka Hledat. Tisk Tisk se provádí pomocí tlačítka . Tiskne vše, co je aktuálně zobrazeno v seznamu. Výstup je do souboru *.csv. Práce se smlouvou Po provedení základní evidence smlouvy, lze na smlouvě generovat předpisy (obdoba faktur), které se posléze odesílají do banky k párování. Založení nové smlouvy Po zmáčknutí tlačítka

v seznamu Smlouvy se otevře prázdný detail smlouvy. Po vyplnění atributů

smlouvy je provede uložení smlouvy (tlačítko ). Jediné pravidlo pro uložení smlouvy je, že datum „od“ nesmí být větší než datum „do“. Pokud tento případ nastane, uživatel je upozorněn při pokusu o uložení chybovým dialogem. Přidání subjektu - výběr subjektu je dostupný z tlačítka umístěné na záložce Smluvní partner. Po vybrání subjektu dvojklikem myši na vybraný subjekt v Adresáři se přenese do záložky Smluvní partner některé údaje o subjektu. Po provedení uložení (tlačítko do databáze.

), se uloží daná vazba

Odebrání subjektu – odebrání subjektu se provede pomocí tlačítka na záložce Smluvní partner. Tlačítko je dostupné, pokud je na smlouvě uložen subjekt. Políčko Id Subjektu obsahuje identifikátor smluvního partnera. Přidání a odebrání přílohy – je dostupné na záložce Přílohy v detailu smlouvy. Přidání přílohy se provede pomocí tlačítka „Přidat“ a „Odebrat“. Založení předpisu a odeslání do banky – založení předpisu je dostupné na záložce Faktury pomocí tlačítka „Nový“. Po zmáčknutí se zobrazí detail Přepisu, kde se vyplní atributy předpisu. Pro odeslání do banky k párování, musí být vyplněna částka větší jak 0, 00Kč.

77

Obrázek 1 - Ukázka založení předpisu

Předpis, který obsahuje částku, lze odeslat do k párování do banky pomocí tlačítka „K párování“ dostupné na záložce Platby v detailu Předpisu. Platbu lze vzít zpět z banky pomocí tlačítka „Stáhnout“ dostupné na záložce Platby v detailu předpisu za podmínky, že není spárovaná s platbou. Toto je indikuje sloupec ID platby v přehledu plateb. Pokud je hodnota 0. Není předpis párován. Pokud existuje ve sloupci nenulové ID platby, je předpis spárovaný s platbou. Editace smlouvy Pokud je smlouva uložena v databázi lze jej editovat. Editace se provede vybráním daného řádku kliknutím myši (řádek se potřeb podbarví) a poté se zmáčkne tlačítko , které otevře detail smlouvy. Po provedení zamýšlené úpravy se zmáčkne tlačítko pro uložení

, které uloží změny do databáze.

Smazání smlouvy Aby bylo možné subjekt smazat, musí být uložený v databázi. Vlastní smazání subjektu se provede pomocí tlačítka

v seznamu nebo detailu subjektu.

Nelze smazat smlouvu, na kterou jsou vygenerované předpisy. Musí se případně odvázat od platby a poté smazat.

78

Banka V modulu Banka dochází ke sledování a manipulaci dvou druhů dat. Předpisy k párování a platby. Předpisy k párování jsou do Banky generovány z modulu Předpisu evidovaného k dané smlouvě. Platby se do systému nahrávají z bankovního výpisu v přesně definovaném formátu bankovního institutu, který tyto bankovní výpisy vystavuje.

Obrázek 1 - Ukázka modulu Banka

Na výše uvedeném obrázku je vidět rozložený modulu. V levé spodní části okna je seznam předpisů k párování. V pravé spodní části jsou vidět platby nahrané ze souboru. V horní části okna se nachází individuální položky k ručnímu párování předpisu s platbou.

Nahrání výpisu Nahrání bankovní výpisu se prování pomocí volby v menu: Výpisy: Otevřít soubor (volba je dostupná, pokud je aktivní okno Banka). Po vybrání souboru se načtou data do Bankovní výpis, kde je vidět název souboru, velikost souboru a možnost vyhledávat v soboru, aniž by byl soubor importován do databáze. Vyhledaný obsah lze vytisknout do *.csv souboru pomocí tlačítka „Export to file“. Import do databáze se provede pomocí tlačítka „Import DB“. Náhled na importovaný výpis je vidět na obrázku Obrázek 7 – Ukázka načítání bankovního výpisu.

79

Obrázek 1 - Ukázka načítání bankovního výpisu

Párování plateb Párování plateb s předpisy pro nás znamená přiřazení danému předpisu identifikátor platby a vypočtení částky, která zbývá z dané platby uhradit.

Obrázek 2 - Ukázka párování plateb

80

Automatické párování Pro automatické spárování plateb s předpisy musí být splněny tyto podmínky: • •

Musí se rovnat variabilní symbol předpisu a variabilním symbolem platby, Musí se rovna částka přepisu a částka platby.

Automatické párování je provedeno pomocí tlačítka „Automat“, nacházející mezi seznamy předpisů a plateb. Po zmáčknutí se dohledají a spárují položky. Spárované položky jsou poté vyobrazeny v seznamu, který je možné vytisknout do *.csv. Ruční párování platby Ruční párování se provádí, pokud nejsou jednoznačně dohledány splněny podmínky pro automatické párování. Pomocí tlačítka „Načíst“ nad seznamem předpisů a plateb se aktualizují seznamy. Dvojím poklepáním myši na vybranou položku v seznamu předpisů se vybere položka k párování. Obdobný postup se provede u platby, která se bude párovat k předpisu. Přepis lze spárovat, pokud není již navázán na platbu. Toto se projeví aktivním tlačítkem Párovat v pravé části. Ruční odpárování platby Pokud je potřeba přepárovat platbu z důvodu chybného spárování, vyhledá se příslušný předpis obdobným postupem jako při párování. Rozdíl je, že v tomto případě je aktivní tlačítko „Odpárovat“ na straně předpisu. Pomocí tlačítka „Načíst“ nad seznamem předpisů a plateb se aktualizují seznamy. Dvojím poklepáním myši na vybranou položku v seznamu předpisů se vybere položka k odpárování. Přepis lze odpárovat, pokud je navázán na platbu. Toto se projeví aktivním tlačítkem „Odpárovat“ v levé části.

81