Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra Softwarového Inženýrství Bakalářská práce Aplikace pro vytváření pojišťovacích smluv a evidenci klientů a zákazníků David Kotalík Vedoucí práce: RNDr. Helena Wallenfelsová 13. května 2014

4

5 Poděkování Rád bych zde poděkoval své vedoucí bakalářské práce RNDr. Heleně Wallenfelsové za rady a pomoc při realizaci tohoto projektu.

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 13. května

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2014 David Kotalík. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Kotalík, David. Aplikace pro vytváření pojišťovacích smluv a evidenci klientů a zákazníků. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

9 Abstrakt Tato práce se zabývá analýzou, návrhem a implementací aplikace v prostředí MS Excel pro tvorbu pojišťovacích smluv. Vstupem aplikace budou data od klientů, která budou uživatelé do aplikace zadávat a výstupem bude návrh nabídek a smluv těmto klientům. Klíčová slova Pojistné smlouvy, Formuláře, MS Excel, VBA, XML, ARES Abstract This thesis deals with analysis, design and implementation of application in MS Excel for creating insurance contracts. The input for the aplication will be data from clients, entered by users and output will be proposal for contracts for these clients. Keywords Insurance contracts, Forms, MS Excel, VBA, XML, ARES ix

10

11 Obsah Úvod 1 1 Popis řešeného problému Představení zadavatelské společnosti Tvorba pojišťovacích smluv Pojišťovací zprostředkovatel Cíl projektu Využití Analýza a návrh Aktuální stav problému Podobná existující řešení Rozbor požadavků Uživatelské role Návrh případů užití Výběr technologií Návrh uživatelského rozhraní Práce s daty Implementace Architektura aplikace Výpočet pojistného Generování nabídek a výstup aplikace Export dat z aplikace Odchytávání událostí a znovupoužitelnost Přenos dat mezi instancemi aplikace Problémy řešené při implementaci Zabezpečení Testování 33 xi

12 4.1 Automatické testy Průběžné testování Závěrečné testy Závěr 35 Zhodnocení splněných požadavků Výhody aplikace Nevýhody aplikace Výhled do budoucna Literatura 37 A Seznam použitých zkratek 39 B Úvodní obrazovka 41 C Základní klient obrazovka 43 D Obsah přiloženého CD 45 xii

13 Seznam obrázků 1.1 Logo společnosti Allianz, a. s Diagram případu užití Ukázka jednoho místa pojištění s jedním předmětem pojištění B.1 Úvodní formulář dokumentu C.1 Základní formulář s údaji o zákazníkovi xiii

14

15 Seznam tabulek 2.1 Scénář pro návrh smlouvy Příklad tabulky v prostředí Excelu xv

16

17 Úvod Příprava pojišťovacích smluv je složitý proces sběru požadavků od klientů a jejich formování do realizovatelné nabídky. Vstupem k tomuto procesu je poměrně velké množství dat. Jde jednak o základní data a požadavky od klientů, ale také další parametry, které již nejsou tak lehce zpracovatelné. Jako příklad může sloužit třeba určení rizika přírodních nebezpečí v oblastech, které jsou předmětem pojištění. To je jen jeden z důvodů, proč je tendence postupy vytváření smluv co nejvíce sjednotit a zjednodušit. [1] Sběr dat od zákazníků probíhá nejen v prostředí sídel pojišťovací společnosti, ale především pomocí tzv. zprostředkovatelů. Zprostředkovately mohou být například pojišťovací makléř či výhradní pojišťovací agent. Ti samostatně sbírají data od klientů a posílají je ke zpracování pojišťovně, případně mohou sami vypracovat návrh smlouvy a tu odeslat ke zpracování. [2] Právě díky tomu je potřeba, aby všechny zainteresované osoby v tomto procesu používali co nejjednodušší a hlavně jednotné prostředky k tvorbě smluv. Tato práce má za úkol seznámit s vytvářením těchto prostředků. Nejprve bude představena analýza problému a rozbor stávajících materiálů, následně návrh a implementace materiálů nových. Ukážeme si, jakým způsobem aplikace vznikala a jakými prostředky se dospělo k výslednému produktu. Závěrečným bodem bude zhodnocení práce. 1

18

19 Kapitola 1 Popis řešeného problému 1.1 Představení zadavatelské společnosti Obrázek 1.1: Logo společnosti Allianz, a. s. Allianz pojišťovna, a. s. je nadnárodní pojišťovací společnost, která patří mezi nejznámější pojišťovny i v České republice. Tato společnost je součástí pojišťovacího koncernu Allianz Group, který působí ve více než 70 zemích světa. Společnost Allianz byla založena roku 1890 v Berlíně. Po třech letech již fungovala po celé Evropě. Právě Mnichov je v současné době hlavním sídlem společnosti. V České republice společnost působí od roku Působí zde dokonce ve více odvětvích. Jednou je samotná Allianz pojišťovna, druhou pak Allianz penzijní společnost, která nabízí důchodové a doplňkové penzijní spoření. [3] 3

20 1. Popis řešeného problému 1.2 Tvorba pojišťovacích smluv Pro lepší představu a orientaci si popíšeme některé aspekty pojišťovacích smluv. Konkrétně tedy smluv, kterými se bude zabývat tato práce. Typy pojištění, které bude tato aplikace pokrývat, jsou pojištění majetku, odpovědnosti a technických rizik. Většina informací k průběhu a vlastnostem jednotlivých typů a tvorbě pojištění byla čerpána především prostřednictvím konzultací se zadavatelem. Pojištění odpovědnosti, v tomto případě podnikatelů a právnických osob, slouží k pojištění škody na majetku či zdraví třetích osob nebo například škody způsobené vadným výrobkem. Pro tato pojištění je základ pojistného počítán z ročního obratu firmy a limitu plnění, které bude pojišťovna maximálně vyplácet v případě pojistné události. Následně na výši pojistného může mít vliv případné rozšíření rozsahu pojištění, kterým může být třeba poškození životního prostředí. [4] Pojištění technických rizik slouží pro pojištění strojů či elektroniky. Tato pojistka se vztahuje například na škody způsobené provozem zařízení nebo škody na strojích jako takových. Základ pojistného v tomto případě tvoří výše pojistné částky, tzn. v jaké hodnotě si chce klient stroje či elektroniku pojistit. Stejně tak jako u odpovědnosti mají na výši pojistného vliv další faktory. V tomto případě se jedná třeba i o místa pojištění či výši spoluúčasti, což je částka, kterou se klient podílí na případném plnění pojistné události. [5] Pojištění majetku je nesložitějším procesem z těchto tří oblastí. Na tuto oblast bude kladen největší důraz při návrhu a implementaci. Toto pojištění slouží k pojištění majetku jednak movitého, nemovitostí nebo třeba i peněz a cenností proti živelným pohromám, krádeži a dalším rizikům. Příkladem živelního pojištění může být například pojištění proti zničení požárem, povodní, vichřicí ale také třeba proti poškození spuštěnými sprinklery. Zde se již objevuje i pojištění přerušení provozu, které zaručuje podnikům náhrady škod vzniklé výše uvedenými událostmi. Jedná se zejména o ušlý zisk či stálé náklady, které musí firma platit i když nevyrábí. Vstupem k tomuto pojištění je seznam tzv. předmětů pojištění. Ty představují jednotlivé typy majetku jako třeba budovy, movité věci či soubor zásob v budově. Tyto předměty jsou rozděleny do jednotlivých míst, u kterých se evidují standardní údaje jako adresa a z té vyplývající povodňová zóna, která má také vliv na výši pojistného. Každý předmět je oceněný pojistnou částkou a poté je pojištěn na určitá rizika podle požadavků zákazníka. Zde mají velký vliv také limity plnění, které jsou dvou typů. Jednak limit plnění pro předmět samotný, který platí pro každý předmět samostatně, dále pak limity jednotlivých rizik, které platí pro celou smlouvu. [6] U všech typů pojištění dále existují doložky, které si může klient vyžádat. Tyto doložky poté většinou nějakým způsobem upravují rozsah pojištění a zpravidla mají vliv i na výši pojistného. Nakonec je možno aplikovat na celou 4

21 1.3. Pojišťovací zprostředkovatel smlouvu slevu či přirážku v určitém rozsahu, což slouží k finálnímu nastavení výše pojistného. Zmíněný proces slouží k tvorbě nabídky, kde se přehledně uspořádají všechny potřebné informace o pojištění a tato nabídka se předkládá klientovi. Pokud klient tuto nabídku schválí, připraví se na základě této nabídky smlouva, která je následně podepsána oběma stranami. Smlouva je velmi podobná nabídce a má více formální charakter. Některé prvky naopak z nabídky do smlouvy nepřechází, a to na základě schválení zákazníkem. Jedná se například o výběr z nabídnutých variant, o kterých budu psát později, kde se do smlouvy vkládá pouze vybraná varianta. 1.3 Pojišťovací zprostředkovatel Vzhledem k tomu, že největší skupinou cílových uživatelů budou pojišťovací zprostředkovatelé, popíšeme si je zde blíže. Uzavírání pojišťovacích smluv se zákazníky může pojišťovna provádět přímo prostřednictvím svých zaměstnanců nebo prostřednictvím pojišťovacích zprostředkovatelů. [2] Pojišťovna Alianz patří mezi několik pojišťoven, které mají povolení ČNB [7] provozovat vzdělávací činnost pro pojišťovací zprostředkovatele a samostatné likvidátory pojistných událostí. [8] Pro provozování činnosti pojišťovacího zprostředkovatele je potřeba mít oprávnění, které za poplatek a při splnění zákonem vymezených podmínek zprostředkovává právě Česká národní banka. Žádající osobě je vystaveno osvědčení a je zanesena do veřejně přístupného registru pojišťovacích zprostředkovatelů. Kdokoli si pak díky tomuto registru může ověřit registraci daného zprostředkovatele. [2] K přehledu o rozsahu oprávnění takového zprostředkovatele uvedu i rozsah činností podle [9]. předkládání návrhů na uzavření pojistných smluv nebo zajišťovacích smluv provádění přípravných prací směřujících k uzavření pojistných nebo zajišťovacích smluv uzavírání pojistných nebo zajišťovacích smluv jménem a na účet pojišťovny nebo zajišťovny, pro kterou je tato činnost vykonávána pomoci při správě pojištění a vyřizování nároků z pojistných nebo zajišťovacích smluv Pojišťovací zprostředkovatelé se dále dělí na několik typů, které jsou blíže popsány například v knize [10]. Pro každého z vyjmenovaných zprostředkovatelů platí, že musí být zapsán v registru. 5

22 1. Popis řešeného problému Vázaný pojišťovací zprostředkovatel má sjednanou písemnou smlouvu s pojišťovnou, řídí se jejími pokyny a jedná na její účet. Tím pádem pojišťovna také odpovídá za případnou škodu jím způsobenou. Takovýto zprostředkovatel může mít sjednanou smlouvu s více pojišťovnami najednou, avšak nemůže inkasovat pojistné ani vyplácet plnění. Pojišťovací agent stejně jako pojišťovací zprostředkovatel, může mít sjednánu smlouvu s více pojišťovnami najednou. Avšak v tomto případě může být oprávněn inkasovat pojistné a vyplácet plnění. Pojišťovna však za jeho jednání neručí, pokud nebylo ujednáno jinak, proto musí být po celou dobu výkonu pojištěn na odpovědnost za škodu při činnosti. Výhradní pojišťovací agent oproti pojišťovacímu agentu vykonává činnost jménem a na účet jediné pojišťovny. Pojišťovna v tomto případě za výhradního agenta ručí. Pojišťovací makléř může zpracovávat komplexní analýzy pojistných rizik, poskytovat poradenskou činnost nebo provádět správu pojistných smluv. Má pravomoci přijímat pojistné a vyplácet plnění. Musí být při činnosti pojištěn a odměňován je pojišťovnou. Podřízený pojišťovací zprostředkovatel spolupracuje s některým z výše uvedených na základě písemné smlouvy. Není oprávněn inkasovat pojistné ani vyplácet plnění. Jedná na účet nadřízeného zprostředkovatele a je jím také vyplácen. 1.4 Cíl projektu Cílem mé bakalářské práce je navrhnout a implementovat jednotné prostředí pro tvorbu pojišťovacích smluv zastřešující výše zmíněné odvětví pojišťovnictví v prostředí tabulkového procesoru MS Excel. Prostředí by mělo jednoduchým a logickým způsobem zaměstnance navigovat při návrhu smlouvy tak, aby byl pokud možno minimalizován zásah do struktury formulářů či dat a tím pádem menší šance na vytváření chybných nabídek. Aplikace by tedy měla většinu výpočtů a dalších funkcí vykonávat automaticky. Dále kromě samotného vytvoření smlouvy je nutné vyřešit jak logiku sdílení jednotlivých smluv a databází mezi zaměstnanci, tak samotné ukládání smluv v nějaké databázové formě. Jedním z cílů je také zajistit různé bezpečností požadavky. Aplikace by měla být odolná proti chybám lidského faktoru a poskytovat rozšířené možnosti užívání na základě zabezpečeného přístupu. 6

23 1.5. Využití 1.5 Využití Aplikace je zaměřena na poměrně malou cílovou skupinu. Jedná se především o zprostředkovatele pojišťovacích smluv, kteří sbírají data od zákazníků a poté buď přímo předkládají a vyřizují navrženou smlouvu se zákazníkem a nebo posílají data zaměstnancům pojišťovny ke zpracování. Další skupinou jsou potom samotní zaměstnanci, kteří dotváří nabídky, uzavírají smlouvy a poté je zadávají do systému.[2] Aplikace by měla zjednodušit proces tvorby pojišťovacích smluv odebráním zbytečných úkonů od uživatelů, které budou vykonávány automaticky. Bude se jednat o pomůcku k navrhování nabídek a smluv o pojištění z informací poskytnutých od zákazníků. Cílem je sjednotit některé úkony a rozhodování při vytváření těchto smluv, čímž budou z procesu odstraněny vlivy chyb lidského faktoru a bude dosaženo jednoznačného návrhu pojistného z poskytnutých informací. Dále by měla aplikace sloužit k lepšímu přehledu o historii smluv, případně zákazníků. Smlouvy bude možné ukládat v databázích a případně se k nim i zpětně vracet, pokud bude třeba smlouvu například přepracovat. Nebude tak nutné smlouvu vytvářet znovu. Databáze zákazníků bude také sloužit ke snadnějšímu vyplňování dat o klientovi. Pokud například pro daného klienta bude vytvářeno více smluv opakovaně, bude možné nechat vyplnit údaje u klientovi automaticky. Omezí se tím vnášení chyb do těchto informací. Dalším využitím bude možnost oddělit rozsah možností zadávání parametrů smluv pro různé skupiny uživatelů. Nebude tak nutné používat například více prostředí a nebo smlouvy dodatečně dotvářet nadřízenými poté, co byli zaměstnanci navrhnuty. Obě skupiny uživatelů budou upravovat smlouvy ve stejném prostředí, pouze s jinými možnostmi. 7

24

25 Kapitola 2 Analýza a návrh Před samotnou implementací je nutné analyzovat aktuální stav a navrhnout nové řešení. Po seznámení s aktuálním stavem problému rozeberu požadavky na základě specifikace zadání pojišťovny. Dále se již seznámíme s návrhem nového řešení. 2.1 Aktuální stav problému Zaměstnanci pojišťovny aktuálně používají několik oddělených Excelových souborů s předpřipravenými tabulkami, které plní daty. Ty mají také jistou funkcionalitu, avšak již nevyhovující potřebám pojišťovny. Důvodů k vytváření nových formulářů je hned několik. Jednak pro každé odvětví pojištění, jako například pojištění majetku či pojištění odpovědnosti, existuje v současné době několik různých formulářových dokumentů, přičemž jeden klient může být pojištěn na několik těchto druhů pojištění zároveň. Pro jednu smlouvu se tak musí udržovat několik souborů najednou. Dále je problém se samotným formátem formulářů. Tím jak se postupně formuláře upravovaly, přidávaly a odebíraly se položky, vznikly formuláře s opravdu nepřeberným množstvím informací, které musí zaměstnanci ručně vyplňovat. Některé položky se přitom vůbec nepoužívají a některé by mohl systém obstarávat automaticky. Některé soubory mají například až desítky listů, ve kterých se musí zaměstnanec orientovat. Především z těchto důvodů je tendence zaměstnanců tyto formuláře nepoužívat a zadávat data přímo do interního systému pojišťovny. K jednotlivým smlouvám pak nejsou skoro žádné podklady. Dalším problémem je sdílení dat mezi zaměstnanci. V tuto chvíli jeden Excel soubor představuje jeden návrh smlouvy. Pro každou další smlouvu je pak nutné zakládat nový soubor nebo přepisovat ten starý. Tím vznikají další problémy v uchovávání podkladů pro smlouvy. 9

26 2. Analýza a návrh 2.2 Podobná existující řešení Na začátku spolupráce s pojišťovnou jsem dostal jako přibližnou ukázku toho, jak by aplikace měla vypadat, několik dokumentů v Excelu s formuláři. Tyto formuláře, ačkoliv nebyly takového rozsahu jako aplikace, kterou jsem implementoval, sloužily jako přibližná předloha pro kýžený výsledek. Tyto dokumenty jsou v pojišťovně běžně používány. Jejich obsah se však týká jiných druhů pojištění, takže pro zde řešené typy pojištění nejsou použitelné, ani žádným jednoduchým způsobem pozměnitelné. Tyto soubory jsem měl také jako grafickou předlohu pro návrh formulářů. Pojišťovna měla zájem na tom, aby byl dokument alespoň přibližně stejně vypadající jako ty, které pojišťovna v současné době běžně používá. To by mělo usnadnit práci s dokumentem uživatelům, kteří například používají více těchto podobných dokumentů. Ačkoliv se tyto soubory skládaly většinou ze statických formulářů bez generace nabídek či jiných funkcionalit, posloužily k prvotní orientaci mezi produkty a požadavky pojišťovny. 2.3 Rozbor požadavků Sběr požadavků byl z větší části sestavován s vedoucím majetkového oddělení, od kterého jsem získával většinu úkolů a informací. Některé další funkční požadavky pak byly přidány i v průběhu návrhu či implementace tak, jak se postupně upřesňovalo zadání práce, především když se k testování průběžných výsledků přidávali i samotní zaměstnanci, kteří aplikaci následně budou používat. Ti některé požadavky dále upřesňovali. Následující seznam představuje aktuální podobu funkčních a nefunkčních požadavků po různých úpravách a aktualizacích Funkční požadavky F1: lokální databáze smluv Každý soubor bude vést lokální databázi smluv a zákazníků, do kterých bude možno smlouvy uložit a následně pak znovu vyvolat. Z důvodu zabezpečení a údržby byla zadavatelem zvolena tato možnost namísto nějaké možnosti sdílené databáze. F2: možnost upravovat dříve vzniklé smlouvy Po vyvolání smlouvy z databáze bude mít zaměstnanec možnost smlouvu upravit a znovu uložit místo staré verze smlouvy. F3: Automatické načítaní údajů o klientovi Prostřednictvím webové aplikace ARES bude možné po zadání čísla IČO automaticky vyhledat a doplnit do formuláře některé informace o klientovi, pokud jsou tedy na tomto webovém portále u daného klienta či firmy údaje vyplněny.[11] 10

27 2.3. Rozbor požadavků F4: zobrazení škodního průběhu Interní zaměstnanci firmy budou mít možnost zobrazení škodního průběhu, který se vztahuje k danému klientovi. Škodní průběh je zjednodušeně poměr mezi výší pojistného, které zákazník pojišťovně zaplatil, a výší náhrad, které byly zákazníkovi vyplacené. Sledování tohoto poměru je typicky omezeno na nějakou stanovenou dobu, například 5 let. Jedná se tedy v podstatě o určení rizikovosti daného zákazníka. V závislosti na tomto údaji je pak možné zhodnotit výhodnost smlouvy či případně smlouvu patřičně upravit. F5: Rozšířené administrační funkce a nastavení Prostřednictvím administrátorského hesla bude možné otevřít některé možnosti navíc oproti běžnému přístupu. Jedná se třeba o nastavení slev a přirážek k jednotlivým nabídkám, nebo třeba nastavování sazeb pro jednotlivá rizika a předměty pojištění. F6: Neomezené či zdánlivé neomezené přidávání položek pojištění V sekci pojištění majetku byl vznesen požadavek na neomezené přidávání míst a předmětů pojištění. Pokud by byl tento požadavek nerealizovatelný, pak alespoň simulovat přidávání položek v takovém měřítku, které pokryje většinu běžně vytvářených smluv. V tomto případě by se jednalo o předpřipravené formuláře s místy a předměty pojištění, které by se pouze postupně zobrazovaly. Vzhledem k tomu, že se nebude jednat o řádkové vkládání dat, ale o vyplňování připravených grafických formulářů, by pro tuto práci bylo vhodnější prostředí MS Accessu, který je více databázově orientován. F7: Varianty nabídek Některá předem určená data by mělo být možno vyplňovat v několika variantách, tyto varianty se poté zobrazí v nabídce, která je předkládána zákazníkovi. Podle výběru se poté bude generovat smlouva s danou variantou. F8: Výstup a přenos dat z lokální databáze Data bude možné nahrát jak z databáze do souboru, tak ze souboru do databáze, prostřednictvím jazyka XML [12]. Tímto způsobem budou zaměstnanci mezi sebou sdílet data z jednotlivých smluv. Zároveň tento formát bude v budoucnu použit pro přenos dat do interního systému pojišťovny Nefunkční požadavky N1: Prostřední MS Excelu Navzdory výhodám prostředí MS Accessu pro toto zadání je požadavek na použití výhradně prostředí MS Excelu. Důvod k tomu rozhodnutí byl jednak softwarového charakteru, a také z důvodu neznalosti prostředí Accessu ze strany zaměstnanců pojišťovny. Možnost čistě samostatné aplikace byla také zamítnuta. 11

28 2. Analýza a návrh N2: Rychlost generování nabídek Ačkoliv některé smlouvy mohou dosahovat poměrně velkého počtu dat, program by měl generovat nabídky v rozumném čase vzhledem k průměrnému hardwarovému vybavení. Jedná se zejména o počty míst a předmětů v sekci pojištění majetku, N3: Udržovatelnost aplikace Prostřednictvím administrátorského přístupu by měla být možnost nastavovat některé parametry smluv, jako jsou jednotlivé sazby apod. N4: Bezpečnost a soudržnost aplikace Mimo administrátorský přístup by nemělo být možné měnit nic kromě informací, ze kterých se nabídka generuje, tedy dat od zákazníka. Nemělo by tedy být možné upravovat například vzorce pro výpočty nebo struktury formulářů. 2.4 Uživatelské role Uživatelské role jsou předem určeny zadavatelem a budou sloužit k rozdílným možnostem při zadávání informací o připravovaných smlouvách a případně možnostem nastavení samotných parametrů programu. Jedná se o následující role. Zprostředkovatel: Zprostředkovatel bude mít možnost zakládat či vyvolávat smlouvy, vyplňovat informace poskytnuté klientem a následně vygenerovat nabídku a smlouvu. Zaměstnanec: Zaměstnanec, v tomto případě myšleno jako interní zaměstnanec pojišťovny, bude mít navíc přístup k internímu informačnímu systému pojišťovny. Konkrétně se pak jedná o možnost zobrazení škodního průběhu. Vedoucí: Vedoucí bude mít navíc k výše zmíněným možnostem ještě možnost dorovnávat výši pojistného pomocí dalších sazeb a informací. Administrátor: Kromě všech předchozích možností bude mít administrátor navíc možnost zasahovat i do nastavení samotné aplikace. jedná se například o nastavení sazeb či úpravu seznamu zaměstnanců. 2.5 Návrh případů užití S ohledem na funkční požadavky a uživatelské role, popsané výše, byly sestaveny případy užití, které z hlediska uživatele popisují fungování aplikace. S pomocí nich bude poté možno sestavit logický sled formulářů tak, aby kopíroval průchod tvorbou smlouvy. U některých komplexnějších funkcí bude rozebrán jak základní, tak i případně alternativní scénář. 12

29 2.5. Návrh případů užití Obrázek 2.1: Diagram případu užití Zalozeni smlouvy Vygenerovani Nabidky «extends» Uzivatel Vygenerovani smlouvy Ulozeni smlouvy Zamestnanec Nacteni smlouvy z databaze nebo ze souboru Exportovat smlouvy do souboru Vedouci Administrator Zobrazeni skodneho prubehu Zobrazeni rozsirenych moznosti formularu Nastaveni sazeb a parametru formularu Aktualizovat seznam zamestnancu «include» «include» «include» «include» Autorizovani uzivatele to, U1: Založení smlouvy Primární aktér: Uživatel Popis: Každý uživatel, který bude s programem pracovat, bude mít možnost založit novou smlouvu. Jedná se jednoduchý úkon, kde systém pouze na tuto reakci uživatele připraví vyčištěné formuláře. U2: Vygenerování nabídky Primární aktér: Uživatel Popis: Nabídka se bude na uživatelův podnět generovat z vložených dat. Tato funkce bude také dostupná všem uživatelům aplikace U3: Vygenerování smlouvy Primární aktér: Uživatel Popis: Pokud bude zákazník s nabídkou spokojen, vygeneruje aplikace na uživatelův příkaz také smlouvu. Vzhledem k tomu, že se jedná o v podstatě cílový bod procesu, ukážeme si i scénář průchodu při tvorbě takové smlouvy. Ten je nastíněn v tabulce

30 2. Analýza a návrh Tabulka 2.1: Scénář pro návrh smlouvy Krok Role Akce 1 Uživatel Zadá příkaz k vytvoření nové smlouvy 2 Systém Zkontroluje, zda-li je aktuálně upravovaná smlouva uložena 3 Systém Vyčistí a připraví formuláře pro novou smlouvu 4 Uživatel Vyplní údaje o zákazníkovi a parametry sjednávané smlouvy 5 Uživatel Zadá příkaz k vytvoření nabídky 6 Systém Zkontroluje konzistenci dat 7 Systém Vygeneruje a zobrazí nabídku 8 Uživatel Po domluvě se zákazníkem vybírá variantu dat a dává podnět k vygenerování smlouvy 8 Systém Vygeneruje a zobrazí nabídku Alternativní scénář: aktuálně upravovaná smlouva není uložena 3a1 Systém Vyzve uživatele k uložení smlouvy nebo odmítnutí uložení dat 3a2 Uživatel Zvolí zdali smlouvu uložit, nebo smazat bez uložení. 3a3 Systém Provede zvolenou akci a připraví prázdné formuláře Alternativní scénář: smlouva obsahuje nekonzistentní data 7b1 Systém Upozorní uživatele na chybná data, a vypíše o, která se jedná 7b2 Uživatel Opraví chybná či doplní chybějící data a znovu dává příkaz ke generování nabídky 7b3 Systém vygeneruje a zobrazí nabídku U4: Uložení smlouvy Primární aktér: Uživatel Popis: Smlouvu bude možné uložit jednak na reakci uživatele, kdy explicitně vyvolá funkci uložení smlouvy, za druhé bude aplikace upozorňovat na neuloženou smlouvu s možností uložení při hrozící ztrátě dat, která může být způsobená požadavkem na založení nové smlouvy, vyvolání staré a nebo ukončení programu. Data se budou ukládat do lokální databáze daného dokumentu. U5: Načtení smlouvy z databáze Primární aktér: Uživatel Popis: Uživatel má možnost vyvolat předchozí smlouvy vytvořené na lokálním souboru, případně načíst smlouvu ze souboru, který byl vygenerován ze stejné, nebo jiné instance souboru. Po načtení smlouvy ze souboru je možné uložit smlouvu na lokální úložiště. 14

31 2.6. Výběr technologií U6: Exportovat smlouvy do souboru Primární aktér: Uživatel Popis: Stejně tak jako má uživatel možnost smlouvy nahrávat do aplikace, tak je možné smlouvy z aplikace exportovat do souboru. Způsob ukládání dat do souborů bude probírán dále. U7: Zobrazení škodního průběhu Primární aktér: Zaměstnanec Popis: Interní zaměstnanci pojišťovny mají možnost zobrazit škodní průběh. Tato funkčnost není přístupná pro běžné uživatele, neboť k přístupu do interního informačního systému společnosti je nutné znát identifikační číslo některého ze zaměstnanců, kteří takový přístup mají. U8: Zobrazení rozšířených možností formulářů Primární aktér: Vedoucí Popis: Vedoucí každého oddělení bude mít možnost dále dotvářet smlouvy pomocí dalších parametrů, které běžným zaměstnancům nejsou přístupné. U9: Nastavení sazeb a parametrů formulářů Primární aktér: Administrátor Popis: Administrátor bude mít již v podstatě kontrolu nad jakýmkoliv nastavením formulářů. Ať už se jedná o sazby či například základní hodnoty limitů. Některé parametry, zejména pak vzorce či datová omezení, však budou neměnné. Takovýto zásah do souboru by mohl aplikaci naprosto zbavit provozuschopnosti. Zásah administrátorů, na druhou stranu, má vliv v podstatě jen na výši pojistného. Změnu vnitřní infrastruktury programu bude pak pravděpodobně obstarávat technické oddělení pojišťovny, které bude s návrhem a implementací programu obeznámeno. U10: Aktualizovat seznam zaměstnanců Primární aktér: Administrátor Popis: Administrátor má dále možnost upravovat seznam zaměstnanců. Tento seznam bude sloužit jednak k identifikaci zpracovatele smlouvy, a za druhé k přístupu ke škodnímu průběhu. Verze distribuované běžným uživatelům, míněno zprostředkovatelům, bude mít tento seznam prázdný, jelikož se nejedná o interní zaměstnance pojišťovny 2.6 Výběr technologií Dalším krokem při návrhu aplikace je zvolení vyhovujících technologií. Vzhledem k výhradnímu požadavku zadavatele na použití prostředí produktu MS Excel je volba technologií v podstatě určena. 15

32 2. Analýza a návrh Zvolenou verzí produktu MS Office, ve které se budou formuláře připravovat, je MS Office Je to tím pádem také nejstarší verze, na které bude zaručena funkčnost celé aplikace. Na novějších verzích bude aplikace také spuštěna a testována. Vzhledem k tomu, že novější verze produktu by měly být kompatibilní se staršími verzemi, neměl by být s funkčností problém. Formuláře budou vypracovány pomocí listů v Excelu a na pozadí budou obsluhovány makry v programovacím jazyku VBA, který je součástí tohoto produktu. [13] Zbývá tedy výběr technologie, která bude použita pro práci s daty, tedy jejich uchovávání a jejich přenos mezi zaměstnanci. Lokální uchovávání dat bude řešeno přímo pomocí tabulkového procesoru a je vysvětleno dále v sekci Práce s daty. Pro export dat z aplikace a sdílení smluv mezi zaměstnanci byl zvolen značkovací jazyk XML. Jedním z hlavních důvodů pro tento výběr je mimo jiné to, že Excel pro tento jazyk obsahuje několik zabudovaných funkcí. Jedná se například o mapování XML souboru do listu a nebo naopak export mapovaných dat do souboru. Pro kompletní výčet použitých technologií je pak třeba ještě zmínit webový informační systém ARES, ze kterého se prostřednictvím jazyka XML budou do tabulkového procesoru stahovat data o zákaznících a dále interní systém pojišťovny, ze kterého bude možné zobrazit škodní průběh k danému klientu. 2.7 Návrh uživatelského rozhraní Velmi důležitým faktorem při tvorbě programu je návrh uživatelského rozhraní. Původní formulářové soubory, které zaměstnanci používali, obsahovaly až příliš mnoho zbytečných informací a vyžadovaly velké množství dat k vyplnění. Logika formulářů v nové aplikaci musí být nastavena tak, aby zaměstnance provedla od založení nové smlouvy až po vygenerování finální smlouvy. Jednotlivé formuláře musí být přehledné, zaměstnanec by neměl být zahlcen příliš mnoha informacemi a položkami k vyplnění. Jednotlivé položky musí být řádně popsány, a pokud nastane v průběhu tvorby smlouvy nějaký problém, zaměstnanec o tomto faktu musí dostat varování. Formuláře by měly co možná nejvíce simulovat fungování klasického formulářového programu. Zaměstnanec nebude zahlcen nepřeberným množstvím listů v liště s listy, mezi kterými by musel vyhledávat. Namísto toho bude přímo v listech zavedeno menu, pomocí kterého se bude možno navigovat mezi formuláři. Tím pádem je možné mít zobrazen v seznamu listů pouze aktuálně prohlížený formulář, a zbytek formulářů mít pro přehlednost skryté. Úvodní obrazovka: Prvním formulářem, který se uživateli zobrazí, bude jednoduchý rozcestník. Zde bude možnost zvolit, zda-li chce uživatel vytvořit 16

33 2.8. Práce s daty novou smlouvu, zobrazit databázi starých smluv a nebo pokračovat ve vyplňování aktuální smlouvy, pokud je nějaká aktivní. Zároveň na této obrazovce budou umístěny různé informační prvky, které si pojišťovna přeje na tuto obrazovku dát. Dalším možností na této obrazovce pak bude zobrazení informací o samotném používání formulářů, jakým způsobem se mezi nimi naviguje či jak se vyplňují. Ukázku toho listu můžete vidět v příloze B Klient obrazovka: Jakýmkoliv způsobem se uživatel rozhodne k vyplňování smlouvy, ať už založením nové či úpravou některé z předchozích, Základní obrazovkou, již obsahující data, je obrazovka s informacemi o klientovi. Informace o klientovi jsou sdílené pro všechny typy pojištění. Z této obrazovky je poté možné pomocí menu vstoupit do některé ze sekcí pojištění, ze kterých je možné se vrátit na tuto obrazovku a poté začít vyplňovat jiný typ pojištění, a nebo se navrátit až na úvodní obrazovku. Vzhled této obrazovky je vidět v příloze C. Další formuláře jsou graficky v podobném stylu, tedy s horní navigační lištou a obsahem pod ní. Jednotlivé sekce obsahují své odlišné navigační lišty vzhledem k tomu, jaké informace se k danému typu pojištění vyplňují, data jsou rozdělená tak, aby se na každém formuláři vyplňoval pokud možno jen jeden provázaný typ informací. Uživatel se tak může soustředit na každou sekci zvlášť. Pokud je v některých místech například potřeba informací z jiných formulářů, uživatel je o tom informován. V každé sekci je možno vygenerovat nabídku ze zadaných dat. Výstupem programu mohou být tedy až tři nabídky či smlouvy, v závislosti na požadovaném typu pojištění. 2.8 Práce s daty Jedním z požadavků pojišťovny bylo ukládání dat o vytvořených smlouvách a zákaznících. Jak bylo zmíněno výše, pro lokální uchovávání dat byl zvolen jednoduchý princip ukládání dat přímo v tabulkovém procesoru v předpřipraveném listě formou databázového řádkového ukládání dat. Jedná se o jednoduché a lehce implementované řešení, zároveň ale i výkonné a bezpečné. Bezpečnostní aspekty tohoto řešení jsou vysvětleny v kapitole Implementace v sekci Zabezpečení. Toto řádkové ukládání dat bude výhodné také pro práci s XML soubory, do kterých se budou smlouvy exportovat. V práci jsou totiž využity vestavěné funkce pro práci s XML soubory, které, mimo jiné, umožňují mapovat nejen jednotlivá pole do příslušných míst v XML souboru, ale také celé sloupce. Ty potom představují parametry nějakého abstraktně určeného předmětu. Tyto předměty se potom opakovaně generují do souboru jako XML zápisy, kde každý předmět pak představuje jeden řádek v tabulce. 17

34

35 Kapitola 3 Implementace Práce na projektu probíhala formou iterativního a inkrementálního vývoje. Jednalo se tedy o jednoduchou verzí agilní techniky. V předem daných intervalech, přibližně v rozmezí jednoho až dvou týdnů, jsem vedoucímu majetkového oddělení, který mi práci zadával, posílal aktuální verzi dokumentu a případně se osobně dostavil do sídla firmy. Tam jsme poté řešili případné problémy a také další postup. Jakékoliv menší přírůstky aplikace byly s tímto vedoucím postupně diskutovány a odsouhlasovány. V určitých větších intervalech, kdy byly splněny některé z dalších požadavků, byla pak aktuální verze dokumentu distribuována i dalším zaměstnancům firmy. Od těchto zaměstnanců jsem pak jako zpětnou vazbu dostával hlášení o případných chybách či názorech a nápadech k úpravám a vylepšením. Tato technika byla zvolena především z důvodů poměrně velké složitosti pojišťovacích postupů. Tím spíše pro člověka zcela mimo tento obor jako jsem já. Bylo tedy nutné co nejčastěji řešit a upravovat jak postupy tak i vzhled a vlastnosti formulářů, aby těmto postupům vyhovovaly. Samozřejmě tato technika měla, alespoň v tomto případě, jisté nevýhody. Ty jsou mimo jiné diskutovány v sekci Problémy řešené při implementaci. 3.1 Architektura aplikace Vzhledem ke zvolenému prostředí, ve kterém budou formuláře připraveny, je architektura poměrně jednoznačná. V jednotlivých listech budou připraveny formuláře, mezi kterými se bude uživatel pohybovat pomocí navigačních lišt. V jednom okamžiku bude aktivní a viditelný pouze aktuálně používaný list. Tím pádem jiný způsob pohybu mezi formuláři než přes navigační lišty nebude možný. Tímto je zaručeno, že uživatel bude formuláři procházet postupně tak, jak jsou logicky poskládané. Zmenší se tím riziko že některé údaje budou přeskočeny a vynechány. 19

36 3. Implementace V některých případech budou použity i externí formuláře, které se budou při určitých interakcích otevírat. Například při zadávání údajů o klientovi bude možné otevřít tlačítkem formulářové okno, kde bude seznam klientů v databázi. Po vybrání řádku náležícímu určitému klientovi a potvrzení formuláře se externí formulář zavře a údaje o klientovi se nahrají do formuláře v listu. Funkce a události vyvolávané interakcí uživatele s formuláři budou obstarávat makra psané pomocí jazyka VBA. Tyto makra mohou být spuštěna nejenom na přímou žádost uživatele, jakou je třeba kliknutí na tlačítko, ale některá makra také reagují na vnitřní stavy samotného programu. Tato makra se spouštějí například při otevření čí zavření dokumentu, nebo při přechodu z jednoho listu na jiný. Zdrojové kódy budou ve většině případů rozděleny do modulů, které je možné v prostředí Excel vytvořit. Tyto moduly budou představovat různé skupiny funkcí. Jedná se hlavně o přehledné rozřazení kódu pro lepší orientaci. Formuláře a celkové chování obsluhuje přibližně přes sedmdesát funkcí, které byly po dobu implementace v podstatě neustále upravovány. Výhody tohoto roztřídění kódu se projeví jednak ve snadnější implementaci, a dále budou tyto moduly sloužit pro lepší orientaci zaměstnanců pojišťovny, pokud budou chtít aplikaci aktualizovat samostatně. Některá další makra, které přímo zachytávají chování listů nebo samotného Excel sešitu, jsou pak umístěny přímo v kódové části daných listů, kde je možné tyto interakce odposlouchávat a odchytávat. Jako příklad může sloužit funkce spouštějící se při aktivaci či deaktivaci listů, nebo při změně hodnot na daném listu. Další skupinou kódu jsou potom funkce, které obstarávají funkčnost externích formulářů, které jsou v některých listech využity. Tyto formuláře se skládají, stejně jako samotné listy sešitu, ze dvou částí, grafické a kódovou, kde se nachází makra pro obsluhu těchto formulářů nebo listů. Z kódové části formulářů i listů je sice možné volat funkce umístěné v samostatných modulech (tím by mohli funkce pro obsluhu pouze volat makra v modulech a celá implementace by tak mohla být umístěna přehledně v těchto modulech), nicméně z těchto modulů pak není možné například odkazovat na prvky umístěné v externích formulářích. Je tedy nutné některé implementace mít umístěné takto odděleně. 3.2 Výpočet pojistného Hlavním kvalitativním prvkem aplikace z pohledu zákazníka je v tomto případě samozřejmě výpočet pojistného ze zadaných informací. Použití prostředí Excelu je na tyto výpočty prakticky ideální. I tak je však příprava několika stovek výpočtů, v některých případech až s několika desítkami proměnných, velmi pracná a vysoce náchylná na chybovost. Výsledky výpočtů průběžných verzí aplikace byly tak nejsledovanější položkou. Průběžná kontrola výpočtů 20

37 3.2. Výpočet pojistného je blíže popsána v kapitole Testování. V úvodu zprávy již byl popsán přibližný postup při určování pojistného pro jednotlivé typy pojištění. Zde si tyto postupy upřesníme a popíšeme více z implementačního hlediska, neboli jakým způsobem se pojistné u jednotlivých druhů pojištění počítá, a jaké parametry do těchto výpočtů vstupují. Jelikož se jedná o základní stavební prvek této aplikace, podle které se navíc částečně uzpůsobují formuláře, poslouží tento přehled i obecné orientaci ve struktuře formulářů. Pojistné pro odpovědnost Výpočet pojistného pro pojištění odpovědnosti je nejsnadnější ze všech tří typů pojištění. Sazba pro výpočet pojistného je v tomto případě určena v závislosti na zadaném ročním obratu firmy a limitu plnění. Tyto hodnoty slouží k vyhledávání v řádku a sloupci v tabulce s pojistným pro odpovědnost, přičemž k tabulovému vyhledávání je použito integrovaných funkcí Excelu. Tato vyhledaná částka slouží jako základ pojistného. Na tento základ se poté aplikují různá rozšíření. Jednak se jedná o několik doložek, které si klient může k pojištění vyžádat, jako například pojištění odpovědnosti poškození životního prostředí nebo na pronajatých nemovitostech, dále je pak možné na takto upravené pojistné aplikovat slevu či přirážku v určité výši, která dotvoří konečné pojistné. Pojistné pro technická rizika Vstupem pro pojištění technických rizik je pojistná částka, kterou si přeje klient pojistit. Druhým parametrem je procentuální sazba, která je pevně určena pojišťovnou. Z těchto dvou parametrů se spočítá základ pojistného. Na tento základ pak opět mají vliv další parametry. Nejdříve výši pojistného ovlivňuje, zda jsou stroje či elektronika pojištěny na území České republiky, v Evropě či jinde ve světě. Zjednodušeně se dá říci, že čím větší územní rozsah, tím se pojistné zvětšuje. Pro některé případy však pojišťovna pojištění neposkytuje. Například pojištění stacionárních strojů je možné pouze na území České republiky. Dále, stejně jako u každého pojištění, mohou být sjednány další doložky upravující rozsah pojištění. Zde se jedná například o pojištění zaplavení nebo požáru strojů. Typicky doložky rozsah pojištění zvětšují, čímž také zvyšují i pojistné. Pojistné je také možné snížit sjednáním maximálního limitu pojistného plnění za jedno roční období. Jinými slovy maximální částku, jakou pojišťovna zákazníkovi vyplatí při pojistné události. Čím menší je tento limit, tím levnější je i celkové pojistné. Konečné pojistné je poté opět možno upravit přidáním slevy či přirážky v určité hodnotě. 21

38 3. Implementace Pojistné pro majetek Výpočet pojistného u pojištění majetku je na rozdíl od předchozích dvou typů pojištění poměrně složitým procesem. Do výpočtu zasahuje mnoho aspektů a dat. Celkové pojistné se v tomto případě skládá z několika dílčích částek. tyto částky jsou vypočítávány samostatně a na konci procesu jsou sečteny. Jedná se o následující skupiny pojistných částek: Pojistná částka za pojištění majetku Pojistná částka za pojištění přerušení provozu Pojistná částka za pojištění skla Pojištění majetku Pojištění majetku, jak již bylo řečeno, se skládá z jednotlivých míst a předmětů pojištění, které se postupně vyplňují do formuláře. Místo pojištění má pouze informativní hodnotu, k jakému místu daný předmět patří. U každého předmětu se pak zvlášť vyplňují následující informace: Typ předmět pojištění: Předmětů pojištění je v tomto případě přibližně patnáct. Na některé předměty mohou být aplikovány různé dodatečné sazby, jako například pojištění krmiva a sena v budově má násobně větší sazby díky riziku požáru. Toto pole je povinné. Pojistná částka: Pojistná částka, na kterou má být daný předmět pojištěn. Toto pole je taktéž povinné. Typ pojistné částky: Typy pojistných částek jsou nové, časové a 1. riziko limit plnění: Jedná se o limit plnění na daný předmět. Tento limit může, ale také nemusí být sjednán. Čím menší je limit plnění, tím menší je pojistné k danému předmětu za sjednaná rizika Výše spoluúčastí na sjednaná rizika: Pojištěnost rizika se určuje vyplněním spoluúčasti pro dané riziko. Čím vyšší spoluúčast si klient zvolí, tím bude pojistné levnější Pro jednotlivé předměty zvlášť se z těchto informací vypočítá pojistné. Pojistné se počítá navíc pro každé riziko zvlášť. Všechny rizika mají své, pojišťovnou stanovené rozpětí sazeb. Použitá velikost těchto sazeb se určuje v závislosti na celkové pojistné částce, tedy součtu pojistných částek všech zadaných předmětů pojištění. Tato sazba tvoří základ sazby pro výpočet pojistného u daného rizika. Na tuto sazbu mají poté vliv následující parametry 22

39 3.2. Výpočet pojistného Sleva za limit na daný předmět, pokud byl sjednán Násobek sazby, pokud je upraven pro daný typ předmětu pojištění Násobný koeficient za typ pojistné částky sleva za celkový limit na daný typ rizika Z těchto parametrů se vypočte konečná sazba pro každé riziko. Těmito sazbami se poté vynásobí pojistné částky u daného předmětu, čímž vzniknou základy pojistného pro daný předmět a sjednaná rizika. Na tyto základy pojistného se dále aplikuje sleva podle výše spoluúčasti na dané riziko. Tímto způsobem se samostatně vypočítají pojistné částky pro každý předmět. Výsledným pojistným z majetkové části je pak součet těchto částek. Celkové limity pojistných rizik, o kterých byla řeč, se zadávají zvlášť. Limit plnění se zadává pro každý typ rizika, a vzorcem je určeno, jaká sleva či přirážka bude na výpočty aplikována. Tato sazba pak platí pro všechny předměty pojištění. Jedním z rizik je také hrozba povodně. Pojistné za toto riziko je vypočítáváno speciálně odděleně. Pojistná částka je rozdělena do povodňových zón podle místa předmětu pojištění. Na tyto rozdělené částky je jsou uplatněny předem stanovené sazby a následně je součtem stanoveno pojistné. Pojištění přerušení provozu Pojistné pro přerušení provozu je možno chápat jako speciální případ předmětu pojištění z výše popisovaného majetku. Stejným způsobem je zadávána pojistná částka a sjednaná rizika. Ostatní parametry zde nefigurují. Částka je navíc rozdělena podle dalších specifik. jde například o pojištění přerušení provozu fotovoltaických zařízení a bioplynových stanic, které mají upravené sazby. Přerušení provozu, stejně jako pojištění majetku, má své limity na jednotlivá rizika. Výpočet pojistného pak probíhá stejným způsobem jako u majetku. Pojištění skla Pojistné u pojištění skla je již ve srovnání s předchozími postupy velmi jednoduché. Na zadanou pojistnou částku je aplikována pojišťovnou stanovená sazba a z té je určeno výsledné pojistné Výsledné pojistné Celkové pojistné je pak určeno součtem pojistného za pojištění majetku, pojištění přerušení provozu a pojištění skla. Na tuto celkovou částku je poté ještě možno aplikovat slevu či přirážku, čímž vznikne konečné pojistné, které se již přenáší do nabídky. 23

40 3. Implementace Jak je vidět z obrázku C.1, zadávat spoluúčasti lze pro každý předmět v několika variantách. Pojistné se tak počítá pro každou variantu zvlášť. V nabídce jsou zobrazeny součty pojistných částek pro každou variantu zvlášť. Z těchto konečných pojistných částek si pak klient vybere tu, která mu vyhovuje. 3.3 Generování nabídek a výstup aplikace Výstupem aplikace je návrh nabídky pojištění a případně smlouvy o pojištění. Tyto návrhy jsou generovány přímo v prostředí aplikace v příslušném listu z informací vložených uživatelem. Některé formální aspekty nabídek a smluv, jako jsou například smluvní podmínky či informace o pojišťovně, jsou již v návrzích přednastaveny. Zbytek proměnných informací je generován na příslušná místa. Některá data je dále nutno před vložením do nabídky vizuálně upravit. Příkladem mohou být místa a předměty. Místo a Předmět pojištění ve formuláři při zadávání informací si můžete prohlédnou na obrázku C.1. Ne všechna pole jsou však povinná. Například výběr pojištěných rizik závisí na požadavcích zákazníka. Dále každý předmět obsahuje několik variant, které se sice do nabídky mohou promítnout, avšak do smlouvy již ne. Předměty generované do nabídky jsou tedy upravené tak, aby obsahovaly pouze data, která byla vyplněna. Ostatní informace jsou vypuštěny. Každý předmět pojištění tak obsahuje pouze informace o pojištěných rizicích a žádných jiných. Další skupinou dat jsou informace, které jsou statické, avšak jejich generování do nabídky je podmíněné. Jedná se například o doložky, které si může zákazník sjednat, a které typicky upravují rozsah pojištění. V některých typech pojištění, konkrétně zde v pojištění majetku, je těchto doložek až několik desítek. Generování těchto doložek do nabídky je však řešeno poměrně jednoduchým způsobem. Položky díky neměnnosti svého obsahu jsou v nabídkách již předpřipraveny a při generování se pouze zkontroluje, jaké doložky byly vybrány uživatelem a zbytek informací se díky možnosti skrývání řádků z nabídky schová. Samotným opravdovým výstupem programu jsou pak vytištěné nabídky a smlouvy z vygenerovaných návrhů. Vytištění pouze žádaného obsahu z daného listu je docíleno nastavením tiskové oblasti u konkrétního listu. Z této tiskové oblasti pak mohou být snadno vynechány funkční prvky aplikace, jako navigační menu. Po vyvolání tisku je poté možnost vytisknout navrženou nabídku či smlouvu. 3.4 Export dat z aplikace Jak již bylo zmíněno v návrhu, data budou z aplikace exportována prostřednictvím integrovaných funkcí prostředí Excel do XML souboru. Toto exportování spočívá v přípravě XML šablony, která bude obsahovat všechna data, která 24

41 3.4. Export dat z aplikace chceme z programu exportovat. Tato šablona se následně nahraje do prostředí Excel, kde se z ní automaticky připraví schéma. Schéma obsahuje prvky, které je třeba mapovat na hodnoty buněk listů. Provede se to jednoduchým přetažením prvku ze zobrazeného schématu na příslušné buňky. Pokud se v šabloně vyskytují dva opakující se oddíly, Excel je rozezná a umožní prvky těchto oddílů namapovat jako sloupce místo jako pouze buňky. Jako ukázku použiji následující předpřipravenou XML šablonu. <smlouva> <predmetpoj> <predmet></ predmet> <castka></ castka> <l i m i t></ l i m i t> </ predmetpoj> <predmetpoj> <predmet></ predmet> <castka></ castka> <l i m i t></ l i m i t> </ predmetpoj> </ smlouva> Šablonu tedy po nahrání do prostředí namapuji na tabulku 3.1. Mapování je v prostředí Excel velmi jednoduché. Ze šablony, která se v programu objeví, se pouze přetahují prvky na žádané buňky. Pokud tedy prvek predmet namapuji na záhlaví sloupce Předmět pojištění, bude mapování pokračovat od prvního záznamu v daném sloupci dále. Stejným způsobem se namapuje i zbytek prvků. Tabulka 3.1: Příklad tabulky v prostředí Excelu Předmět pojištění Částka Limit pojištění predtest predtest predtest Pokud se poté v Excelu zadá export nahrané šablony, opakující se oddíly se nahradí záznamy v namapované tabulce, pokud nějaké obsahuje. Pokud ne, žádný záznam nevznikne. Stejně tak, pokud některým z řádků chybí některé hodnoty, do výstupu se jednoduše negenerují. Podobným způsobem je pak možné taktéž pomocí integrovaných funkcí prostředí Excel naopak nahrát data z XML souboru do tabulky v Excel dokumentu. Z naší ukázkové šablony pak vznikne následující výstup. 25

42 3. Implementace <smlouva> <predmetpoj> <predmet>predtest1</predmet> <castka>50000</ castka> <l i m i t>10000</ l i m i t> </ predmetpoj> <predmetpoj> <predmet>predtest2</predmet> <castka>20000</ castka> <l i m i t>5000</ l i m i t> </ predmetpoj> <predmetpoj>aky <predmet>predtest3</predmet> <castka>300000</ castka> </ predmetpoj> </ smlouva> 3.5 Odchytávání událostí a znovupoužitelnost Bylo samozřejmě nutné zajistit, aby bylo možno smlouvy vypracovávat opakovaně. Vzhledem k prostředí, ve kterém se implementuje, je však nutno předejít některým událostem. Konkrétně se jedná například o ukládání dokumentu. V běžném případě má uživatel produktů MS Office možnost uložit dokument ve stavu, v jakém se právě nachází. Tato vlastnost však byla pro tento projekt nežádoucí. Jelikož formuláře simulují funkci klasického programu, byla tato možnost ukládání dokumentu odstraněna, respektive byla nahrazena jinou funkcionalitou. Událost uložení, jak již bylo zmíněno výše, se v prostředí Excelu vyvolává dvěma způsoby. Jednak přímou žádostí uživatele o uložení souboru, a dále pak při zavírání dokumentu s neuloženým obsahem. Obě tyto události jsou v aplikaci odchytávány. Při pokusu o uložení dokumentu se dialogové okno s dotazem na uložení dokumentu zamění za dialogové okno s dotazem na uložení smlouvy. Při potvrzení je pak smlouva nahrána do databáze. V případě prvního uložení smlouvy je nahrána jako nový záznam, v opačném případě jsou data pouze aktualizována. Poté je sešit uložen, aby se uchovaly informace v lokální databázi. Další důležitá událost nastane při zavírání dokumentu. V tomto případě se nejprve ověří, zda je smlouva již uložena, nebo zda byla pozměněna. Pokud jsou některá data neuložena nebo změněna, opakuje se postup z předchozího odstavce. Zavírání dokumentu je možné, stejně jako v originále, zrušit tlačítkem Storno. V opačném případě se již spustí příslušná makra před samotným zavřením dokumentu. Tato makra slouží k vyčištění všech formulářů a nastavení úvodního listu jako aktivní. Tyto akce zaručí, že při opětovném otevření 26

43 3.6. Přenos dat mezi instancemi aplikace dokumentu bude aplikace ve výchozím stavu, s připravenými formuláři a na úvodní stránce. 3.6 Přenos dat mezi instancemi aplikace Sdílení smluv mezi zaměstnanci bude probíhat prostřednictvím generovaných XML souborů zmíněných výše. Vygenerovaný soubor v sobě bude obsahovat jak údaje o klientovi, tak i všechny tři typy smluv, pokud byly vyplněny. Nebude tedy nutné pro jednoho zákazníka, který si sjednal všechny tři typy smluv, generovat tři XML soubory. Na tomto systému jsme se se zadavatelem dohodli jako na alternativě k sdílené databázi nebo nějakému jinému způsobu automatického sdílení dat. Tyto alternativy byly zadavatelem odmítnuty z důvodů obav přístupu zvenčí do jejich vnitřní infrastruktury. Toto řešení má několik výhod. Jednou je například budoucí záměr, aby tyto formulářové aplikace přenášely data přímo do interního systému pojišťovny, nebo případně s nějaký prostředníkem, který jednoduchým způsobem exportuje data z formulářů a předá je systému ke zpracování. Aktuální problém spočívá v tom, že ačkoliv s pomocí této aplikace uživatel může vygenerovat nabídku a smlouvu k podepsání, do interního systému ji pak musí stejně zadávat ručně. Tento problém ale nebude v této práci řešen, jelikož byl vypuštěn i z požadavků pojišťovny. Pojišťovna by se na toto zpracování dat musela připravit, což by v tomto případě znamenalo implementovat modul pro zpracování XML souboru do interního systému a to podle pojišťovny nebude v nejbližší době reálné. Nicméně plán pojišťovny je takovýto modul do budoucna připravit, a tak jsme upravovali export dat z formulářů tak, aby v budoucnu přibližně vyhovoval podmínkám pro automatické zpracování. XML soubory jsou tedy poměrně výhodným řešením. Slouží jednak ke sdílení dat mezi zaměstnanci, tak v budoucnu také pro automatické nahrávání do systému pojišťovny. 3.7 Problémy řešené při implementaci Při implementaci se vyskytlo několik vážnějších problémů. Některé se týkaly přímo implementace, některé pak průběhu spolupráce s pojišťovnou. Uvedu zde ty nejproblematičtější. Nejprve budu psát o problémech týkajících se přímo spolupráce se zadavatelem, a poté popíši několik dalších z implementace formulářů. 27

44 3. Implementace Agilní technika implementace jak jsem již zmínil, vývoj probíhal pomocí jednoduché agilní techniky. To s sebou přineslo několik problémů. Jedním z nich je například nejasné a neúplné zadání a cíle práce. Zadavatel teprve v průběhu spolupráce zadání upřesňoval a také nebyli příliš specifičtí, jaké všechny prvky a rozsah má aplikace mít. Velký problém spočíval v intervalových kontrolách průběžného výsledku práce. Na začátku každé iterace byly dohodnuty určité body a cíle, ale ve chvíli kdy se tyto body na další schůzi testovaly, vyšly najevo nejasnosti například ve vazbách jednotlivých závislostí, čímž se již dokončené body a postupy neustále měnily. Více zainteresovaných osob Ačkoliv jsem po většinu času dostával instrukce od vedoucího majetkového oddělení, on nebyl přímo jedním z lidí, kdo samotné smlouvy vytváří a kdo bude aplikaci používat. Ve chvíli, kdy již aplikace měla určitou podobu a funkčnost, byla předána jiným zaměstnancům, kteří již smlouvy vytváří. V tu chvíli však vyšlo najevo poměrně dost nesrovnalostí. Jednak ze strany postupů při vytváření smluv, tak i ohledně výpočtů některých položek. Poměrně značnou část aplikace jsem pak musel upravovat znovu. Tento problém však poté přetrvával po celou dobu vývoje, jelikož názory jak na vzhled, postupy či výpočty se navzájem mezi těmito zaměstnanci lišily. Spolupráce se všemi současně pak byla poměrně náročná. Změna hlavního vedoucího Další nečekaný problém, který byl ovšem neovlivnitelný, vznikl ve chvíli, kdy byl hlavní vedoucí, který byl zástupce zadavatele pro tento projekt v rámci organizace, nečekaně odvolán z funkce. V tu chvíli převzal tento projekt druhý vedoucí. S tím ale také přišly další změny názorů a postupů, které se promítly do struktury aplikace. Možnosti prostředí Excel V několika případech jsem narazil na hranice možností samotného prostředí, ve kterém jsem implementoval. Jeden z největších těchto problému vznikl při původním návrhu zadávání majetkových položek, tedy míst a předmětů pojištění. Tento způsob fungoval na principu přidávání míst a předmětů, které se zobrazovaly pod sebe. Ukázka takového jednoho místa s jedním předmětem je pro představu vidět na obrázku C.1 Jak místa, tak předměty bylo možné zobrazovat a skrývat tak, že z nich byla vidět jen horní lišta, na které byla pro orientaci adresa resp. vybraný předmět pojištění spolu s tlačítky na zobrazení předmětu. 28

45 3.7. Problémy řešené při implementaci Obrázek 3.1: Ukázka jednoho místa pojištění s jedním předmětem pojištění Problém spočíval v tom, že každý takový předmět obsahoval přibližně devadesát, v některých případech poměrně dlouhých a složitých vzorců a asi desítku validačních podmínek. Tyto předměty pak obsluhovalo pět funkcí, vyjma těch obsluhující skrývání a zobrazování položek, které se spouštěly při různých příležitostech. Avšak při určitém počtu přidaných předmětů se začínala aplikace zpomalovat a po chvíli přestávala odpovídat. Při podrobném testování jsem zjistil, že počet vzorců, dosahujících i několik tisíc, aplikaci zpomaluje a stejnou měrou zpomalovalo běh aplikace samotné schovávání řádků formuláře. Po dalším testování tohoto řešení jsem zjistil, že při určitých změnách ve formulářích, jakými je například vkládání hodnot do buněk, Excel nastavuje zalomení řádků, které je pro schované řádky očividně velmi náročné. Celý tento systém byl tedy přepracován tak, že na obrazovce je vizuálně pouze jedno místo a jeden předmět tak, jak je vidět na obrázku C.1. K tomu jsou přidány dva seznamy, kterými si uživatel vybírá příslušné místo a předmět. Ty jsou pak nahrávány to předpřipraveného formuláře a je možné s nimi pracovat. Tato záležitost způsobila asi největší problémy, neboť skutečnost, jakým 29

46 3. Implementace způsobem tento návrh aplikace nezvládá, jsem zjistil v podstatě až ve chvíli, kdy byla aplikace již téměř hotová. Problém nastával přibližně při třiceti přidaných předmětech, což je poměrně dost výjimečná situace při tvorbě smlouvy. Tím pádem se tato skutečnost neprojevila při běžném testování. Jelikož se však nejednalo pouze o zpomalení běhu aplikace, ale i ke zkolabování a ukončení aplikace, musel jsem přepracovat celou logiku toho nejsložitějšího formuláře z celé aplikace. Další kuriozity prostředí Excel Pro zajímavost zde zmíním i některé méně pochopitelné chování produktu Excel. Nejvíce času, co se těchto menších problémů týče, jsem strávil řešením problému při použití dvou seznamových oken na jednom listě. Tzv. listboxy mají jako jeden z parametrů položku listfillrange, do které se zadá název předem pojmenované oblasti, která pak představuje tabulku v některém z listů. ListBox pak dokáže automaticky převést tuto oblast na záznamy v seznamu společně s jejich záhlavím. Je to velmi užitečná vlastnost, kterou jsem využíval do té doby, než jsem na stejný list přidal druhý listbox, který měl také vyplněn tento parametr. Problém nastal při interakci s kterýmkoliv z těchto dvou seznamů, jako například vybrání určitého řádku. V tu chvíli se z vlastností listboxů vymazaly parametry listfillrange, ale záznamy v samotných listech zůstaly. Avšak pokud pak chtěl uživatel znovu provést nějakou operaci se seznamem, aplikace se okamžitě zasekávala, a bez jakékoliv zprávy či logu padala. Musel jsem tedy přepracovat logiku tak, že obsah seznamů je přidáván i mazán programově pomocí maker. 3.8 Zabezpečení Na data a samotné formuláře bylo vzneseno několik následujících požadavků. Jedná se především o metody udržení konzistence ukládaných dat a samotných formulářů konzistence uložených dat: Data v lokální databázi nebudou přístupná žádnému uživateli přímo. Práce s databází bude probíhat prostřednictvím metod, které budou do databáze data ukládat, vyhledávat, případně z ní mazat. Pokud bude tedy zaměstnanec potřebovat některá data ve smlouvě z databáze upravit či aktualizovat, nehrozí, že by při této operaci data z této smlouvy, nebo z kterékoli jiné, znehodnotil například výběrem a smazáním více buněk najednou. Smlouvu bude nutné nejdříve nahrát do formulářů, v kterých poté uživatel upraví pole podle potřeby. 30

47 3.8. Zabezpečení funkčnost formulářů: Vzhledem k prostředí, ve kterém jsou formuláře upravovány, je nutné zajistit, aby samotná funkčnost formulářů nebyla narušena. Ve formulářích budou tedy přístupné pouze pole, která slouží k vyplnění dat. Vše ostatní bude uzamčeno, včetně možnosti editace samotného zdrojového kódu. Pokud některá makra potřebují pracovat se zamčeným obsahem, v rámci vykonávání daného bloku si list odemkne a následně ho opět zamkne. Po celou dobu vykonávání takového kódu však musí být zmrazeno vykreslování změn formulářů. Tuto možnost, mimo jiné, má již prostředí v sobě zabudováno. rozšířené možnosti formulářů: Jedním z požadavků bylo také rozšířené možnosti zadávání dat pro určitou skupinu zaměstnanců. Tento přístup bude řešen pomocí uzamčení daného obsahu, který bude možné zadáním příslušného hesla odemknout. Toto heslo si pak budou moci daní uživatelé sami měnit. 31

48

49 Kapitola 4 Testování Velmi důležitou součástí bylo testování aplikace. Vzhledem k tomu, s jakým obsahem se pracuje, byl vyvíjen velký tlak na správnost a plynulost formulářů. Vzhledem k prostředí, ve kterém se formuláře implementovaly, se jednalo o poměrně specifické testování. Bylo potřeba testovat nejen správnost výpočtů či funkcionalitu jednotlivých maker, ale také třeba samotné chování prostředí Excel při vykonávání nejrůznějších úkonů. Během implementace se vyskytlo i pár kuriózních problémů, kdy aplikace padala při zdánlivě jednoduchých operacích. Některé z těchto problémů byly popsány v kapitole Implementace. Na rozdíl od klasické implementace bylo nutné, aby některá rozhodnutí a úpravy byly přehodnocovány právě v závislosti na možnostech a chování produktů MS Office. 4.1 Automatické testy V některých případech bylo možné automaticky testovat funkcionalitu jednotlivých prvků. jednalo se tak v podstatě o testovaní maker makry. Tyto testy poté pomáhaly ověřovat celkovou funkčnost aplikace po každé iteraci, kde byla jednotlivá makra přidávána a upravována. Automatické testy jsem tedy spouštěl před každým podrobným testováním na konci každé iterace. Ověřoval jsem si tím, že základní prvky aplikace fungují a mohl jsem pak manuálně otestovat některé ze složitějších funkcionalit. V některých případech však nebylo možné testy provádět automaticky. Jednalo se pak především o testy maker, které se spouštěly interakcí uživatele s formulářem. Ačkoliv do jisté míry je možné simulovat činnost uživatele v prostředí maker, nejsou tyto možnosti dokonalé. 33

50 4. Testování 4.2 Průběžné testování Aplikace byla testována již v průběhu implementace. Jelikož se jedno o vývoj formou agilních technik, v určitých intervalech vznikaly samostatně funkční prototypy, které bylo možno testovat. Před samotným předáním, na konci každé iterace, byly mnou provedeny testy integrace celé aplikace. Jednalo se tak především o kontrolu funkčnosti všech prvků, které aplikace v danou chvíli nabízela, zda aplikace nepadá či není příliš zpomalována během užívání. Dále následovalo testování kvality jednotlivých částí aplikace, které probíhalo již v prostředí firmy samotné. Budoucí uživatelé, spolu se svým nadřízeným, znovu testovali nejen funkčnost realizovaných prvků aplikace, ale také další parametry. Především pak šlo o celkový dojem z používání aplikace jako je logická návaznost a forma jednotlivých formulářů. Jedním z nejdůležitějších parametrů, které se při každé iteraci kontrolovaly, byla správnost zpracování dat. Konkrétně pak vypočtené částky pro návrh smlouvy ze zadaných informací. 4.3 Závěrečné testy Po dokončení byla aplikace testována na celkovou funkčnost. Prováděl jsem testy jednotlivých funkcionálních prvků aplikace jakými byly například složitější funkce pro export smlouvy do XML souboru a další. Dále se testovala celková odolnost aplikace na možnost zanesení chyb či nekonzistentních výsledků, toto testování bylo prováděno ve spolupráci se zaměstnanci pojišťovny, kteří na aplikaci simulovali různé postupy při vytváření smluv. Posledním avšak pro pojišťovnu nejdůležitějším parametrem bylo testování výstupů z aplikace. Od pojišťovny jsem k testování dostal několik ukázkových smluv, které obsahovaly jak data poskytnutá zákazníkem, tak i nabídky či smlouvy, které byly těmto zákazníkům předloženy. Podle těchto ukázkových smluv jsem potom testoval správnost všech výpočtů. 34

51 Závěr Cílem mé bakalářské práce bylo zanalyzovat, navrhnout a implementovat formulářovou aplikaci pro zpracování dat poskytnutých zákazníkem, jejíž výstupem je návrh nabídky a smlouvy o pojištění pro daného zákazníka v několika odvětvích pojištění. Původním řešením a zároveň výchozími materiály bylo několik neudržovatelných oddělených tabulkových souborů z jednotlivých odvětví pojištění s prakticky nulovou funkcionalitou a kontrolou konzistence dat. Ve výsledném produktu se mi podařilo sjednotit všechny řešené typy pojištění do jedné formulářové aplikace v prostředí Excelových tabulek. Výsledné formuláře jsou opatřeny mnoha validacemi dat a funkcionalitou, která nahrazuje některé původně manuálně prováděné úkony. Tím se snížila pravděpodobnost chyb lidského faktoru. Zhodnocení splněných požadavků Výsledná aplikace splňuje prakticky všechny požadavky, které byly na začátku zadány. Jedním z bodů, který byl původně zvažován, ale bylo od něj upuštěno, bylo automatické nahrávání smluv do interního systému pojišťovny. Nicméně tento problém nebylo prozatím možno realizovat z důvodu chybějící funkcionality ze strany pojišťovny. V tuto chvíli se pak ještě dolaďuje a zdokonaluje sdílení dat mezi zaměstnanci pomocí XML souborů, které v sobě přináší i určitá úskalí a rizika. Historii smluv je možné ukládat přímo v prostředí daného souboru, kde je možné je znovu načíst a dále editovat. V minulosti bylo nutné uchovávat pro každou smlouvu samostatnou instanci Excelu. Podařilo se také implementovat speciální funkce, které využívají přístupu buď na webové stránky a nebo do interního systému pojištění. Tyto funkce pak pomáhají uživateli rychleji vyhledat a vyplnit žádané informace a navrhnout smlouvu. 35

52 Závěr Výhody aplikace Mezi hlavní výhody výsledné aplikace patří: Sjednocené formuláře několika typů pojištění Některá data jsou společná pro všechny typy pojištění Známé prostředí Excelu pro uživatele Mnoho opatření minimalizující možnost chyb Nevýhody aplikace Aplikace má pak i některé z následujících nevýhod Manuální sdílení dat mezi uživateli Zneužitelnost toho způsobu sdílení Nutnost i pro externí pracovníky vlastnit produkty MS Office (typicky ale pokryto pojišťovnou) Výhled do budoucna I po úspěšném odevzdání aplikace spolupráce s pojišťovnou na tomto projektu nekončí. Do budoucna je naplánováno dokončit připravený přenos dat z aplikace do interního systéme pojišťovny. To obnáší jednak přípravu informačního systému na zpracování XML souborů na formu dat, který již umí zpracovat, a dále upřesnění struktury XML podle toho modulu. V budoucnu bude pravděpodobně dále docházet k vývoji způsobu sdílení dat mezi instancemi tabulkového procesoru. V tuto chvíli je toto sdílení manuální. Pravděpodobně by se jednalo o formu centrální databáze smluv a zákazníků. Dalším bodem, který byl diskutován, je, zda-li případné aktualizace souboru budou řešeny prostřednictvím technického oddělení pojišťovny, nebo budu aplikaci průběžně aktualizovat sám podle jejich požadavků. Některé parametry jsou sice měnitelné po přihlášení vybraných uživatelů, pokud by se ale jednalo o větší zásah do systému, jako například struktury formulářů nebo úprava vzorců, je nutné celou aplikaci odemknout a upravit. Tato možnost není uživatelům přístupna, kvůli hrozbě znehodnocení celé aplikace. 36

53 Literatura [1] Asociace českých pojišťovacích makléřů: Parametry pro vypracování nabídky pojistné smlouvy [online]. 2005, [cit ]. Dostupné z: http: // [2] Česká národní banka: Pojišťovací zprostředkovatelé [online]. [cit ]. Dostupné z: finance/pojisteni/pojistovaci_zprostredkovatele.html [3] Allianz: O společnosti Allianz pojišťovna, a. s. [online]. 2003, [cit ]. Dostupné z: o-spolecnosti.html [4] Allianz: Pojištění odpovědnosti [online]. [cit ]. Dostupné z: [5] Allianz: Pojištění technických rizik [online]. [cit ]. Dostupné z: [6] Allianz: Pojištění majetku [online]. [cit ]. Dostupné z: [7] Česká národní banka: Česká národní banka [online]. 2014, [cit ]. Dostupné z: [8] Česká národní banka: Pojišťovny s povolením provozovat vzdělávací činnost [online]. [cit ]. Dostupné z: https: // schvalovaci_rizeni/poj_zprostredkovatele_likvidatori/seznam_ pojistoven_opravnenych_skolit.html 37

54 Literatura [9] Unie společností finančního zprostředkování a poradenství: zákon č. 38/2004 Sb., o pojišťovacích zprostředkovatelích a samostatných likvidátorech pojistných událostí [online]. [cit ]. Dostupné z: http: // [10] neuveden, A.: Pojišťovnictví. Sagit, 2011, ISBN [11] Ministerstvo financí ČR: Administrativní registr ekonomických subjektů [online]. 2013, [cit ]. Dostupné z: ares/ares.html.cz [12] W3C: Extensible Markup Language [online]. 2013, [cit ]. Dostupné z: [13] Pavel Kocich, O. S.: 1001 tipů a triků pro Visual Basic. Computer Press, a.s., 2010, ISBN

55 Příloha A Seznam použitých zkratek XML Extensible markup language VBA Visual Basic for Aplications ARES Administrativní registr ekonomických subjektů ČNB Česká národní banka 39

56

57 Příloha B Úvodní obrazovka Obrázek B.1: Úvodní formulář dokumentu 41

58

59 Příloha C Základní klient obrazovka Obrázek C.1: Základní formulář s údaji o zákazníkovi 43