ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická
Diplomová práce
Statistika clearingových platebních transakcí Zdeněk Kamlar
Vedoucí práce: Ing. Zdeněk Blažek, Csc.
Studijní program: Informatika a výpočetní technika Leden 2007
ii
iii
Poděkování Chtěl bych na tomto místě poděkovat vedoucímu své diplomové práce panu Ing. Zdeňku Blažkovi, Csc. za odbornou pomoc a podporu při práci na projektu.
iv
v
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 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ů (autorský zákon).
V Praze dne 14.1.2007
……..…………………………………….
vi
vii
Abstract The goal of the master thesis is proposal and implementation of the system supporting analysis of payments between finance institution and Czech National Bank. The analysis is based on incoming and out coming clearing files processing. The purpose of this analysis is set up foundation for customer marketing practical tool implementation. Simultaneously provide support for monitoring and evaluation of transaction with the objective to detect “money laundering”.
Abstrakt Cílem diplomové práce je návrh a implementace systému schopného analyzovat mezibankovní platební styk mezi finanční institucí a Českou národní bankou. Analýza je založena na zpracování příchozích a odchozích clearingových souborů. Účel analýzy je vytvořit základ pro implementaci praktického nástroje pro potřeby klientského marketingu. Současně umožnit sledování a vyhodnocování transakcí s cílem odhalit tzv. „praní špinavých peněz“.
viii
ix
Obsah 1.
Úvod................................................................................................................................... 1
2.
Popis problému................................................................................................................. 3 2.1.
3.
Analýza existujících řešení ............................................................................................ 10 3.1.
4.
Webový diagram ...................................................................................................... 47 Struktura stránek se statistikami............................................................................... 49 Popis implementace.................................................................................................. 52 Datový model ........................................................................................................... 58 Proces importu clearingových souborů .................................................................... 60 Požadavky na systém ............................................................................................... 62
Testování ......................................................................................................................... 63 7.1. 7.2.
8.
Architektura systému................................................................................................ 25 Webový Server......................................................................................................... 26 Databázový server .................................................................................................... 28 Značkovací jazyky.................................................................................................... 31 Technologie pro dynamické generování na straně klienta ....................................... 33 Technologie pro dynamické generování na straně serveru ...................................... 35 Odůvodnění zvolených technologií.......................................................................... 37 Bezpečnost systému ................................................................................................. 40 Návrh uživatelského rozhraní................................................................................... 41 Návrh databáze..................................................................................................... 44
Implementace.................................................................................................................. 47 6.1. 6.2. 6.3. 6.4. 6.5. 6.6.
7.
Obecné požadavky na systém .................................................................................. 12 Datový slovník ......................................................................................................... 13 Specifikace požadavků............................................................................................. 21 Uživatelé a uživatelské role...................................................................................... 22 Případy užití (use case diagram) .............................................................................. 22
Analýza a návrh řešení .................................................................................................. 25 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. 5.9. 5.10.
6.
Hlavní důvody pro vznik nového řešení .................................................................. 11
Požadavky ....................................................................................................................... 12 4.1. 4.2. 4.3. 4.4. 4.5.
5.
Platební systémy......................................................................................................... 3
Popis testovacích metod ........................................................................................... 63 Shrnutí výsledků testů .............................................................................................. 65
Závěr................................................................................................................................ 71 8.1. 8.2. 8.3.
Dosažené výsledky................................................................................................... 71 Možnosti využití diplomové práce........................................................................... 71 Další možnosti rozšiřování systému......................................................................... 71
x
9.
Seznam citované literatury............................................................................................ 73
Příloha A. Seznam použitých zkratek ................................................................................. 67 Příloha B. Uživatelská příručka .......................................................................................... 69 Příloha C. Instalační příručka ............................................................................................. 85 Příloha D. Ukázka clearingového souboru ......................................................................... 88 Příloha E. Obsah přiloženého CD ....................................................................................... 89
xi
Seznam obrázků Obrázek 1: Fáze toku peněžních prostředků – odesílatel a příjemce u stejné banky ................. 4 Obrázek 2: Fáze toku peněžních prostředků – odesílatel a příjemce u různých bank ............... 5 Obrázek 3:Příklad položky příchozího clearingového souboru ................................................. 6 Obrázek 4:Příklad položky odchozího clearingového souboru.................................................. 6 Obrázek 5: Struktura položky v clearingovém souboru............................................................. 6 Obrázek 6: Use case diagram (administrátor) .......................................................................... 23 Obrázek 7: Use case diagram (běžný uživatel) ........................................................................ 24 Obrázek 8: Architektura klient-server...................................................................................... 25 Obrázek 9: Ukázka nastavení zabezpečení na IIS 6.0.............................................................. 38 Obrázek 10: Návrh orientační struktury aplikace .................................................................... 43 Obrázek 11: Koncepční datový model ..................................................................................... 45 Obrázek 12: Webový diagram systému ................................................................................... 47 Obrázek 13: Hlavní menu ........................................................................................................ 49 Obrázek 14: Javascriptový kalendář ........................................................................................ 50 Obrázek 15: Posuvník hlavní tabulky ...................................................................................... 50 Obrázek 16: Přehledné zobrazení platebních transakcí............................................................ 51 Obrázek 17: Příklad sloupcového grafu ................................................................................... 57 Obrázek 18: Datový model ...................................................................................................... 58 Obrázek 19: Obecný popis SQL příkazu INSERT................................................................... 61 Obrázek 20: Ukázka řešení problému se špatně umístěným nadpisem ................................... 66 Obrázek 21: Ukázka záměny čísla a názvu účtu při testování ................................................. 67 Obrázek 22: Příklad řešení problému s načítáním grafu .......................................................... 68 Obrázek 23: Ukázka hlavní strany ........................................................................................... 77 Obrázek 24: Statistika clearingových platebních transakcí...................................................... 78 Obrázek 25: Účty s největším platebními transakcemi ............................................................ 80 Obrázek 26: Výpis účtů............................................................................................................ 81 Obrázek 27: Zobrazení detailu účtu ......................................................................................... 83 Obrázek 28: Ukázka editace účtů............................................................................................. 84 Obrázek 29: Ukázka grafu transakcí ........................................................................................ 86 Obrázek 30: Import - fáze 1 ..................................................................................................... 87 Obrázek 31: Import - fáze 2 ..................................................................................................... 88 Obrázek 32: Import - fáze 3 ..................................................................................................... 89 Obrázek 33: Import - fáze importu........................................................................................... 89 Obrázek 34: Ukázka importu účtů ........................................................................................... 90 Obrázek 35: Úkazka editaci s kódy bank ................................................................................. 91 Obrázek 36: Ukázka stránky s nápovědou ............................................................................... 92 Obrázek 37: Ukázka výběru webového serveru při instalaci PHP........................................... 94 Obrázek 38: Změna konfiguračních proměných v souboru php.ini......................................... 94 Obrázek 39: Obsah souboru config.ini..................................................................................... 95
xii
xiii
Seznam tabulek Tabulka 1: Formát clearingového souboru - hlavička položky.................................................. 8 Tabulka 2: Formát clearingového souboru – položka částka..................................................... 8 Tabulka 3: Formát clearingového souboru – položka účet debet............................................... 9 Tabulka 4: Formát clearingového souboru – položka účet kredit.............................................. 9 Tabulka 5: Datový slovník ....................................................................................................... 14
xiv
1
1. Úvod Tato diplomová práce analyzuje podmínky a požadavky finančních institucí na zpracování platebních transakcí, které se realizují v clearingovém platebním systému České národní banky. Cílem je vytvoření praktického nástroje pro marketingové účely nebo pro interní potřebu monitoringu finančních toků. Nástroj pro statistiku clearingových platebních transakcí byl pojmenován jako „CTStat“. Vytvoření
nástroje
napomáhajícího
analyzovat
finanční
operace
má
značné
opodstatnění z důvodu absence podobných prostředků v současné době na našem trhu. Tento deficit je způsoben úzkou specifikací tohoto problému. Tato úzká specifikace je způsobena pravidly pro formát a specifikaci clearingových souborů, které stanovuje Česká národní banka1. Z toho důvodu je nástroj na statistiku clearingových platebních transakcí zajímavý pro tuzemské finanční instituce. Tento nástroj se snaží splnit požadavky cílové skupiny uživatelů složený především z finančních poradců v batonkovních institucích. Další potenciál tohoto nástroje se skrývá v podpoře marketingu finančních institucích při získávání nových klientů. Nástroj je postaven na analýze interních clearingových souborů, které vycházejí z plateb stávajících klientů. Z těch plateb pak bude možné vysledovat finanční toky i u klientů konkurenčních společností. Například na základě získaných údajů, tj. kam a jaké částky potencionální klient zasílal či obdržel, lze sestavit vhodnou nabídku, která bude pro daného zákazníka výhodnější než u jeho stávajícího peněžního ústavu. Tímto způsobem získá finanční poradce pádný argument při vyjednávání s potencionálně novým klientem. Toto je jedna z možností využití systému při vyhodnocování vybraných transakcí finančními poradci. Praktickou zkušeností je, že nabídka na našem trhu je poměrně vyrovnaná, tudíž jsou ceny služeb u všech konkurenčních institucí vesměs podobné. Navíc většina zákazníků již má svoji banku, je tedy nutné nové klienty spíše zlákat od konkurence. Jedním ze způsobů získání takového zákazníka je nabídnout mu lepší nabídku než má u své nynější banky, nejlépe nabídku šitou na míru sestavenou podle pozorovaného modelu jeho finančního chovaní.
1
Úplná specifikace formátu clearingových souborů je dostupná v [1].
2
Konkrétní nabídka pak bude sestavená za pomoci informací o zákazníkových obvyklých peněžních transakcích a právě k tomu je vhodný nástroj nazvaný CTStat. Text diplomové práce je rozdělena do několika kapitol. V úvodní kapitole je uveden úvod do oblasti statistiky clearingových platebních transakcí. Kapitola 2 obsahuje krátký popis problému platebních systémů v České republice. Nejprve je uvedena obecná činnost platebních systémů, zejména pak clearingového platebního systému. V závěru kapitoly je podrobněji popsán formát clearingových souborů. Kapitola 3 se věnuje analýze existujících řešení. Kapitola 3 shrnuje požadavky na realizaci systému. Popisuje uživatelské role, specifikuje datový slovník a ukazuje případy užití systému. Kapitola 5 se věnuje analýze a návrhu řešení. Úvodní část kapitoly se věnuje přehledu technologií dílčích komponent. Následuje rozbor návrhu databáze a uživatelského rozhraní. Kapitola 6 se zabývá samotnou implementací tohoto systému. Jsou zde popsány zajímavé prostředky, které byly použity v této práci. Kapitola 7 popisuje způsoby testování systému včetně výsledků samotných testů.
3
2. Popis problému Základním problémem je mít přehled o fungování tuzemského platebního styku, jakožto hlavního nástroje mezibankovního vypořádaní plateb v České republice. Dále pak znát význam jednotlivých položek v clearingových souborech a způsob uchování těchto informací k pozdějšímu použití. Dalším problémem je převést data z clearingových souborů do databáze, ze které se budou později snáze zpracovávat.
2.1. Platební systémy Zabezpečení
platebního
styku
patří
k jednomu
z nejvýznamnějších
národohospodářských úkolů bank v tržní ekonomice. Pro samotné banky je platební styk zdrojem přímých a nepřímých výnosů a zároveň informace z něj banky využívají při posuzování bonity klientů. Tato kapitola se zaměří na objasnění principů clearingového platebního systému, prostřednictvím kterých banky provádí převody plateb. Nejdříve se ukáže v obecné rovině clearingový platební systém a poté je podrobněji rozebrán mezibankovní platební systém, který funguje v České republice. Mezibankovní platební systémy zahrnují ty platby, kdy plátce a příjemce jsou klienty jiných bank a samozřejmě i platby vyplývající ze vzájemných obchodů mezi bankami, které provádějí pro své potřeby a na svůj účet. K zabezpečení těchto plateb proto musí existovat určité propojení mezi bankami. Proces převodu platebních prostředků mezi dvěma bankami má vždy dva důležité aspekty. Přenos informace charakterizující prováděnou platbu v současné době je obvykle prováděn elektronickou cestou a zahrnuje i potřebnou ochranu. Zúčtování platby zahrnuje zatížení účtu plátce (banky plátce) a na druhé straně připsání částky ve prospěch účtu příjemce (přijímající banky).
4
2.1.1.
Clearingový platební systém
Platební systémy založené na zúčtování plateb prostřednictvím zúčtovací banky2 spočívají v tom, že jednotlivé banky zapojené do systému mají otevřen svůj účet u zúčtovací banky, přes který provádějí platby se všemi napojenými bankami.
2.1.2.
Tuzemský mezibankovní platební systém
Právo provádět bezhotovostní platební styk náleží pouze bankám s platnou bankovní licencí, což vyplývá ze zákona č. 21/1992, o bankách, protože pouze banky mohou přijímat vklady od veřejnosti. Banky provádějí platby na základě příkazů od svých klientů, předávaných formou písemného dokladu3 nebo technickými prostředky4. Pokud plátce i příjemce platby mají své účty u stejného peněžního ústavu, provede převod peněz (zúčtování na účtech) tato banka ve svém vlastním zúčtovacím centru5 v rámci jednoho dne (viz. Obrázek 1). V případě, že plátce a příjemce platby mají své účty u různých bank, musí banka plátce použít pro převod peněz „mezibankovní zúčtovací centrum“ prostřednictvím zúčtovací banky (viz. Obrázek 2).
Obrázek 1: Fáze toku peněžních prostředků – odesílatel a příjemce u stejné banky
2
Zúčtovací bankou se rozumí Česká národní banka, která provozuje mezibankovní zúčtovací centrum, ve kterém
se provádí vlastní vypořádání clearingových plateb. 3
Tiskopis příkazu k úhradě, šek apod.
4
Příkazy předávanými na datovém nosiči, elektronicky počítačem spojeným s bankou, běžným telefonem,
zvláštní bankovní aplikací prostřednictvím mobilního telefonu, příp. mohou být za elektronický příkaz k úhradě považovány i použití platební karty. 5
Zúčtovacím centrem se myslí bankovní systém, ve kterém se provádí vypořádání platebních transakcí. V tomto
textu je též označen pod pojmem clearingový platební systém.
5
$
Odesílatel
Česká národní banka
Příjemce
$
$
Banka odesílatele
Banka příjemce
Obrázek 2: Fáze toku peněžních prostředků – odesílatel a příjemce u různých bank
2.1.3. Popis činností clearingového systému České národní banky Clearingový systém ČNB zajišťuje veškerý mezibankovní platební styk v české měně na území České republiky. Za tímto účelem má každá banka v ČNB otevřen úročený účet v českých korunách (účet mezibankovního platebního styku), který používá k vyrovnání svých mezibankovních plateb. ČNB provádí příkazy k převedení finančních prostředků z těchto účtů na základě instrukcí banky - majitele účtu mezibankovního platebního styku. Clearingový systém ČNB zpracovává veškeré mezibankovní transakce bez ohledu na to, zda se jedná o zúčtování plateb banky nebo plateb jejích klientů. Příkazy k platbám z účtů mezibankovního platebního styku mohou dát též účastníci se statutem třetí strany, kteří nemají u ČNB účet, ale dostali k tomu od banky, která je majitelem účtu, předem písemný souhlas.
2.1.4.
Formát clearingových souborů
Jednotlivé soubory se předávají v textové podobě. Pro běžná média se používá kód ASCII6. Jednotlivé položky se skládají z polí. Každé z nich začíná identifikátorem pole a končí separátorem. Identifikátor pole je tvořen dvěma znaky, které určují typ pole, a ukončen znakem „dvojtečka“. Identifikátor pole je umístěn na začátku položky nebo za separátorem 6
ASCII je anglická zkratka pro standardní kód pro výměnu informací. V podstatě jde o kódovou tabulku, která
definuje znaky anglické abecedy, a jiné znaky používané v informatice. Tabulka obsahuje tisknutelné znaky: písmena, číslice, jiné znaky (+-*/% ...), interpunkční znaménka, speciální znaky(@$~ ...)), a řídící (netisknutelné) kódy, které byly původně určeny pro řízení periferních zařízení (např. tiskárny nebo dálnopisu).
6
předchozího pole. Jako separátor se používá dvojice znaků CRLF7. Jednotlivé platební položky začíná polem HD (hlavička položky, úplná specifikace tohoto pole bude uvedena v podkapitole věnované formátu clearingových souborů). Jednotlivá pole se dělí na podpole. Jako separátor mezi podpoli slouží mezera. Pro podpole typu x, kde může být mezera součástí pole, je separátorem dvojice znaků CRLF a tři mezery. Jednotlivá podpole v poli jsou povinná nebo nepovinná. HD:21 20060601 0004300 0000135 0006200 5000106 0000000 KC:000030000000000 20060601 CZK ID:20060601 6060120510001 UD:000000 0000010006 NOSTR U CNB UK:000000 0093002290 EC:0000000558 ZK:6060101751 Obrázek 3:Příklad položky příchozího clearingového souboru
HD:11 20060531 0006200 0014088 0000800 0000000 0000000 KC:000000003952200 20060531 CZK ID:20060531 053104745 UD: 11747548 SPOLEČNOST PRAHA S.R.O DI: SPOLEČNOST PRAHA S.R.O. UK:000000 441172 SPOLEČNOST BRNO S.R.O AK:0000000067 EC:308 ZK:0000702724 AV:702724 Obrázek 4:Příklad položky odchozího clearingového souboru
1. pole
HD: xxxxxxxx
2. pole CRLF
XY: podpole1
Začátek položek
Podpole2
CRLF
Konec položky
Konec 1. pole
Mezera nebo CRLF a tří mezery, je-li podpole typu x Obrázek 5: Struktura položky v clearingovém souboru
7
CRLF je zkratka anglického termínu „Carriage Return Line Feed“. Je to speciální znak, nebo sekvence znaků
v počítačovém souboru, které znamenají konec řádku.
7
2.1.5.
Význam jednotlivých polí
V této kapitole je blíže vysvětlen formát jednotlivých polí. Jsou zde vysvětleny jednotlivé významy důležitých položek v clearingových souborech. Jednotlivé položky jsou sestaveny z určitých znaků. Tyto skupiny znaků jsou označeny podle jejich charakteru: • •
n - pouze numerické (0-9) a - alfanumerické (A-Z, a-z (znaky anglické abecedy bez háčků a čárek), 0-9, u alfanumerických kódů bank i mezera
Dále pro formát jednotlivých polí se uvádí jejich délka, která se vyjadřuje pomocí dvojice čísel: • •
nn - maximální délka (nn) - fixní délka
Pro označení povinnosti podpole se používá toto označení: • •
M - povinné O - nepovinné
Pro označení banky se v clearingovém formátu používá tzv. identifikační kód banky. Výše uvedený kód je numerický kód nebo alfanumerický kód banky, který je označen v číselníku [10] jako „Aktivní účastník mezibankovního platebního styku“. V případě, že identifikační kód v alfanumerické formě, podpole se doplňuje zprava mezerami. V případě, že identifikační kód je v numerické podobě, podpole se doplňuje zleva nulami. Podpole identifikační kód, které není využito (v závislosti na typu položky), se vyplní mezerami nebo nulami. V níže uvedených tabulkách jsou popsány jednotlivé významy podpolí clearingového formátu. V první tabulce je popsaná tzv. hlavička položky (viz. Tabulka 1). Hlavička položky je první podpole jedné platby. Začíná klíčovým slovem „HD“. Identifikuje, o jaký typ platby se jedná, datum vytvoření této položky, identifikační kód banky odesílatele platby a příjemce platby. Pro konkrétní představu se jedná o první řádek na obrázku 3 nebo 4. V další tabulce je popsán formát položky částka (viz. Tabulka 2). Položka částka začíná klíčovým slovem „KC“ a zakládá se na třech podpolích. Prvním podpolem je hodnota částky, která má délku 15 znaků a je zleva doplněna nulami. Potom to je datum, kdy byla částka
8
odečtena z účtu plátce a poslední podpole je alfanumerický kód měny. Tímto kódem je v současné době „CZK“, což označuje české koruny.Pro konkrétní představu tato položka je druhý řádek v obrázku 3 nebo 4. Povinné pole M
Formát Poznámky podpole
(2)n
Typ položky. Určuje význam platby. Seznam všech typů položek a jejich významů je rozebrán v [1]. Datum vytvoření položky v tvaru RRRRMMDD. Nesmí být novější ani starší než 10 dní v porovnání s datem nastaveným v mezibankovním zúčtovacím centru (dále jen MZC). Všechny položky v jednom clearingovém souboru musí mít stejné datum.
M
(8)n
M
7a
Identifikační kód první banky. Tento identifikační kód má význam banky odesílatele platby.
M
7n
M
7a
M
7n
O
7a
Vstupní identifikační pořadové číslo položky (určuje předávající banka). Je založené na identifikaci položky v databázích banky odesílatele. V kontrolních položkách typu 51 může mít hodnotu 0. V rámci jednoho účtovacího dne se nesmí vyskytovat dvakrát ty stejné čísla, každé číslo musí být jedinečné. V jednom vstupním logickém bloku musí být položky seřazené podle tohoto čísla vzestupně a postupnost nesmí být porušená, což se kontroluje po dobu zpracování. Identifikační kód druhé banky. V tomto systému má význam jako banka příjemce platby. Výstupní identifikační pořadové číslo položky (přiděluje MZC). Identifikační kód třetí banky. Toto podpole je pro banky zakázané vyplnit. Pro MZC je povinné jen v případě vrácení položky, kdy se sem ukládá identifikátor banky, do které byla původní položka směrovaná.
Tabulka 1: Formát clearingového souboru - hlavička položky Povinné Formát Poznámky pole podpole M 15 n Částka. Suma se uvádí bez znaků jeho odlišení (desetinné
tečky). Poslední dvě místa jsou desetinná místa příslušné měnové jednotky. Například číslo 000000003952200 představuje částku 39 522,00 Kč. M
(8) n
M
(3) a
Datum v tvaru RRRRMMDD, odpovídající dnu, kdy byly finanční prostředky odepsané z účtu klienta v bance – odesílatel. Kód měny. Do podpole se uvádí kód měny, o kterou se jedná, v podpoli “částka”. Zpravidla je tímto kódem „CZK“, což je označena česká koruna.
Tabulka 2: Formát clearingového souboru – položka částka
9
Ve třetí a čtvrté tabulce (viz. Tabulka 3 a Tabulka 4) jsou popsány formáty položek účtů debet (plátce) a účet kredit (příjemce). Oba tyto účty mají podobné formáty. První podpole je předčíslí účtu, druhé je číslo účtu a poslední je zkrácený název účtu. Tento zkrácený název účtu má pro celý systém velký význam, protože obyčejně identifikuje majitele těchto účtů. Položka účtu debet začíná klíčovým slovem „UD“ a pro položku účet kredit je tímto slovem „UK“. Položka účet debet zobrazuje čtvrtý řádek na obrázku 3. Položka účet kredit je vyobrazena na třetím řádku obrázku 3.
Povinné Formát Poznámky pole podpole O První část účtu (obyčejně předčíslí ). Když není uvedené 6n
konkrétní číslo, musí být uvedený znak „mezera“. Je určené na uvedení předčíslí čísla účtu banky odesílatele nebo účtu jeho klienta, z kterého byly finanční prostředky odepsané. M
10 n
Druhá část čísla účtu (obyčejně číslo účtu). Pole je určené na uvedení čísla účtu banky ,na které mají být finanční prostředky provedené.
O
20 x
Zkrácený název účtu banky odesílatele nebo jeho klienta, z kterého byly finanční prostředky odepsané
Tabulka 3: Formát clearingového souboru – položka účet debet
Povinné Formát Poznámky pole podpole O 6n První část účtu (obyčejně předčíslí). Když není uvedené
konkrétně číslo, musí být uvedený znak „mezera“. Je určené na uvedení předčíslí čísla účtu banky příjemce nebo jeho klienta, na který mají být finanční prostředky převedené. M
10 n
O
20 x
Druhá část čísla účtu (obyčejně číslo účtu). Pole je určené na uvedení čísla účtu banky ,na které mají být finanční prostředky provedené. Zkrácený název účtu banky příjemce nebo jeho klienta, na který mají být finanční prostředky převedené.
Tabulka 4: Formát clearingového souboru – položka účet kredit
10
3. Analýza existujících řešení V současné době nejsou běžně dostupné na českém trhu speciální programové produkty, které by umožňovaly bližší analýzu clearingových platebních transakcí. Několik málo systémů se zabývá vlastní realizací mezibankovních plateb. Tyto programové produkty jsou určené pro kompletní správu finančních operací bankovní instituce. Jako pevnou nebo volitelnou součástí těchto aplikací jsou moduly se statistikami platebních transakcí. Tyto nástroje nejsou sice primárně určeny k analýze plateb, ale dají se z nich určité rozbory transakcí také vytvořit. V následujícím odstavci jsou v krátkosti blíže popsány dva produkty, které je možné k dané problematice nalézt na českém internetu. AXA DBS - Transakční bankovní informační systém Autorem prvního produktu je společnost AXA, spol. s r. o [19]. Skládá se z několika specializovaných modulů, jako například Modul Core, který je základním kamenem bankovního informačního systému AXA DBS. Realizuje podporu každodenních procesů probíhající v bance a je velmi široce automatizován. Dalšími moduly jsou Retail modul (Vkladové účty a depozitní činnosti, Úvěrové účty), Modul Wholesale (Poskytuje širokou podporu pro peněžní i devizový trh, zajišťuje automatické kontroly a automatické provádění operací. Stejně tak i v oblasti kapitálových trhů zajišťuje napojení na burzy a realizaci obchodů). Z pohledu statistiky platebních transakcí je zajímavější Modul Interface produkty (Mezibankovní platební styk, Styk s uživateli SIPO, Home-banking, Styk s Autorizačním centrem PK, Styk s BCP a SCP, Styk s mzdovým systémem a systémem vnitřní ekonomiky, Telebanking, GSM, INTERNET, SWIFT) BankStat a BankArch Autorem produktu BankStat je společnost EDITEL CZ a.s. [20]. Tento produkt umožňuje bankám snadnou přípravu, zpracování a pravidelné zasílání povinných statistických údajů České národní bance. Aplikace BankArch zajišťuje zpřehlednění stavů výkazů a jednoduchou a rychlou orientaci ve veškerých statistických dokumentech. Dále usnadňuje orientaci v oblasti historie platebních transakcí.
11
3.1. Hlavní důvody pro vznik nového řešení V předchozí kapitole se rozebírají dvě stávající řešení mezibankovních platebních systémů. Tyto produkty ovšem nejsou primárně určeny ke statistice clearingových platebních transakcí, které by mohli být s nově navrhovaným systémem srovnávány. Vzhledem k dynamickému rozvoji platebních systémů, vyvstal požadavek na návrh moderního řešení, které by umožnilo efektivní zpracování údajů z clearingových platebních transakcí. Hlavním impulsem pro realizaci nového řešení byla snaha nalézt nové metody v oblasti klientského marketingu, dále pak z oblasti kontroly podezřelých transakcí se zaměřením na problematiku tzv. „praní špinavých peněz“.
12
4. Požadavky V zahajovací fázi každého projektu je důležité jednoznačně vymezit a specifikovat požadavky na funkčnost realizovaného systému. Prvním krokem při návrhu systému je deklarovat záměr projektu, případně upřesnit nároky na výsledný produkt. Podrobněji o záměru projektu a jeho uživatelských nárocích je věnována podkapitola o obecných požadavcích na systém. V základním popisu problému a při vymezení požadavků na systém se objevují pojmy, které jsou důležité v další práci při tvorbě systému. Tyto pojmy jsou pak jednoznačně definovány v datovém slovníku. Dalším krokem je přesné formulování nároků na systém v podobě funkčních a nefunkčních požadavků. Funkční požadavky jsou dále upřesněny v diagramech případů užití.
4.1. Obecné požadavky na systém Obecné požadavky na nový systém lze rozdělit do několika hlavních bodů. Tyto body by měly mít strategický význam při monitorování platebních transakcí. •
Přehled odchozích a příchozích plateb – tento přehled poskytuje základní informace o příchozích a odchozích platebních transakcích. V uživatelsky přijatelné formě8 zobrazuje obsah clearingových souborů, ve kterých evidují základní informace o realizovaných platebních transakcích, jako například odesílatel, příjemce, částka nebo datum platby.
•
Přehled velkých částek v platbách – zobrazuje přehled plateb, ve kterých jsou převáděny částky velkého objemu9. Výpis platebních transakcí je seřazen od největších částek až po ty nejmenší. Tento seznam usnadňuje výběr nových klientů, protože ukazuje na ty, kteří realizují velké platby.
•
Přehled velkého počtu platebních transakcí – poskytuje přehled o účtech, ze kterých bylo posíláno velké množství různých transakcí, zejména drobných nebo
8
Uživatelsky přijatelná forma je například přehledná tabulka, která může byt členěna do více stránek.
9
Za částky velkého objemu lze požadovat platby od jednoho milionu a výš.
13
pravidelných plateb. Tato skupina účtů je rovněž zajímavá z marketingového hlediska, poněvadž se zde realizují časté nebo dokonce pravidelné platby.
•
Detailní statistiky jednotlivých účtů – podrobně interpretují uskutečněné transakce jednotlivých účtů. Jedná se především o účty svých stávajících klientů, ale i pohyby na účtech klientů u ostatních peněžních ústavů. Je zřejmé, že platební transakce od cizích klientů jsou zaznamenány, pouze pokud byly realizovány pomocí plateb stávajících klientů.
•
Získání obecných informací o účtech nebo klientech – ve většině plateb, které jsou později transponovány do clearingových souborů, jsou jako nepovinné údaje napsány informace o příjemci nebo odesílateli. Díky těmto údajům lze vypátrat název účtu odesílatele, název účtu příjemce, jméno společnosti, která disponuje tímto účtem, nebo účel platby. Shromáždění těchto údajů slouží k identifikaci klienta a usnadňuje jeho případné pozdější oslovení s nabídkou lepších bankovních služeb.
•
Odhalení praní „špinavých“ peněz – tento výpis upozorňuje na finanční operace, které by mohly být podezřelé z tzv. praní „špinavých“ peněz. Bližší specifikace podezřelých transakcí bude zařazena do další kapitoly, která bude věnována analýze.
4.2. Datový slovník Datový slovník jednoznačně charakterizuje důležité pojmy z oblasti řešeného problému. Každé odvětví má svůj vlastní slang, jazyk či terminologii. Jeho hlavní přínos spočívá v pochopení a zachycení klíčových termínů a definicí. Výsledkem by mělo být zefektivnění komunikace mezi zadavatelem projektu a řešitelským týmem.
14
Termín
Definice
Platba, platební transakce, finanční transakce Clearingový soubor Účet Účet kredit Účet debet Servisní účet Clearingový systém, mezibankovní zúčtovací systém Podezřelá transakce tzv. „praní špinavých peněz“ Kód banky
Převod peněžních prostředků mezi účty. Soubor, ve kterém jsou zaznamenány platební transakce. Běžný účet je účet, který vede banka pro klienta, jehož hlavní funkcí je provádění platebního styku. Označuje účet příjemce platební transakce. Označuje účet plátce platební transakce. Označuje účet, jehož vlastníkem je samotná bankovní instituce, slouží zejména k vlastním potřebám banky. Bankovní systém pro realizaci bankovní převodů. Transakce, která splňuje rysy podezřelé transakce podle definice podezřelých plateb. Číselný identifikátor banky
Tabulka 5: Datový slovník
Datový slovník se vytváří na základě popisu problému a průběžně se během analýzy podle potřeby doplňuje. Tabulce 5 znázorňuje výsledný datový slovník. Definice transakcí podezřelých z praní „špinavých“ peněz: •
Jeden subjekt realizuje několik transakcí těsně pod zákonnou hranicí „povinnosti identifikace účastníků plateb“10 stejnému příjemci v relativně krátké době se opakující.
10
Podle zákona č. 61/1996 Sb. o některých opatřeních proti legalizaci výnosů z trestné činnosti. Jestliže povinná
osoba je účastníkem obchodu v hodnotě převyšující částku 15 000 EUR, vždy identifikuje účastníky obchodu, pokud tento zákon dále nestanoví jinak. Hodnotou obchodu nebo podezřelého obchodu v měně euro se rozumí odpovídající hodnota jakékoliv měny stanovená na základě kurzu vyhlášeného Českou národní bankou pro den, ve kterém je plněna povinnost podle tohoto zákona
15
•
Jeden subjekt provádí více transakcí těsně pod zákonnou hranici „povinnosti identifikace účastníků palateb“ více příjemcům do stejného peněžního ústavu
16
17
• Několik různých subjektů zasílá velké množství malých plateb jednomu
18
19
•
20
21
• Mohou to být převody velkých celých částek. Npříklad podezřele vypadají transakce, ve kterých jsou částky 10 000 000,- Kč či 100 000 000,- Kč.
4.3. Specifikace požadavků Nároky na systém jsou rozděleny na „Funkční požadavky“ a „Nefunkční požadavky“. Funkční požadavky definují funkce, které bude systém poskytovat uživatelům. Nefunkční požadavky určují technické parametry systému, které jsou pro uživatele neviditelné. Požadavky budou definovány v přirozeném jazyce v následujícím formátu:
: bude
4.3.1.
Funkční požadavky
•
RQ1: CTStat bude přehledně zobrazovat uskutečněné platební transakce.
•
RQ2: CTStat bude umožňovat vyhledávání určitých subjektů.
•
RQ3: CTStat bude zobrazovat přehled všech účtů.
•
RQ4: CTStat bude zobrazovat podezřelé transakce.
•
RQ5: CTStat bude umožňovat řazení transakcí podle data.
•
RQ6: CTStat bude umožňovat import clearingových souborů ve formátu stanoveném Českou národní bankou.
•
RQ7: CTStat bude zobrazovat grafy statistiky jednotlivých platebních bilancí na účtu.
•
RQ8: CTStat bude umožňovat označit platební transakce realizované pomocí servisních účtů nebo nostro účtů jako neaktivní.
4.3.2. •
Nefunkční požadavky
RQ9: CTStat bude nasazena do stávajícího bankovního prostředí.
22
•
RQ10: Pro CTStat bude zvolena vhodná technologie, která nebude mít složité nároky při implementaci do stávajícího bankovního prostředí.
4.4. Uživatelé a uživatelské role Systém podporuje dvě uživatelské role, které jsou definovány takto: •
Běžný uživatel používá systém k analýze dat, hledání informací o transakcích nebo o účtech a vytváření grafů. Vyhodnocuje informace o podezřelých transakcí. Předpokládá se, že ovládá běžné kancelářské aplikace a práci s internetem.
•
Administrátor systému se stará o běžný provoz celé aplikace. Pomocí administračního rozhraní pro správu webového serveru přidává nebo odebírá oprávnění běžným uživatelům k užívání aplikace. Dále importuje nové clearingové soubory. Předpokládaná úroveň znalostí administrátora je základní orientace ve správě webového serveru (IIS) a uživatelská znalost clearingových souborů.
Přístup ke zdrojům a informacím je založen na rolích a odpovědnostech každého uživatele v rámci organizace nebo uživatelské základny. O přidělení práv rozhoduje administrátor aplikace. Ten musí být schopen správně rozlišit potřeby jednotlivých uživatelů.
4.5. Případy užití (use case diagram) Modelování případů užití (use cases) je jeden z mnoha způsobů, jak vytvořit specifikaci systémových požadavků na nový systém. Zobrazuje služby, které bude systém nabízet aktérovi (uživateli) a popisuje interakci aktéra se systémem pomocí scénářů. Důležité je přesné a úplné vymezení funkčnosti pro návrh budoucího systému. Pro modelování případů užití se používá modelovací jazyk UML [2].
23
Obecný výstup z modelu případu užití obsahuje čtyři základní komponenty: •
Účastníky (actors). Jsou to role, přidělené osobám nebo předmětům používajícím daný proces. Rozdělení uživatelských rolí popisuje předchozí podkapitola.
•
Případy užití (use cases). Činnosti, které mohou účastníci se systémem vykonávat.
•
Relace (relationships). Definuje smysluplné vztahy mezi účastníky a případy užití.
•
Hranice systému (system boundary). Ohraničení zobrazované kolem případů užití, jež je vyznačením území nebo hranic modelovaného systému
Obrázek 6: Use case diagram (administrátor)
24
Obrázek 6 zobrazuje Use case diagram z pohledu administrátora systému. Obrázek 7 zachycuje možnosti běžného uživatele a administrátora při práci se systémem.
Obrázek 7: Use case diagram (běžný uživatel)
25
5. Analýza a návrh řešení 5.1. Architektura systému Vytvářený systém bude nasazen ve finančním sektoru, tudíž bude mít většinu rovnocenných uživatelů, kteří budou pracovat se stejnými daty. Z této základní podmínky nejvíce vyhovuje architektura klient-server. Architektura klient-server znamená, že existují dva druhy programů. Jeden běží na serveru a druhý na počítači klienta. Výhodou tohoto řešení je stálá dostupnost aktuálních dat pro všechny uživatele. Další výhoda vznikne při změnách dat, kde stačí aktualizovat data pouze na straně serveru. Databázový server
Webový server
Klient Klient
Klient Obrázek 8: Architektura klient-server
Z obrázku (Obrázek 8) je vidět, že na straně serveru bude potřeba webový a databázový server, na straně klienta pouze webový prohlížeč. Kromě těchto požadavků je předpokladem správné funkce také odpovídající hardware. Webový a databázový server mohou být umístěny na jednom počítači. Za účelem rovnoměrné rozložení zátěže nebo kvůli primární bezpečnosti dat, je mnohem lepší, pokud tyto dva servery budou umístěny na sobě nezávislých počítačích.
26
5.1.1.
Klient
Pro práci na klientské straně musí být odpovídající software. Tímto softwarem může být jakýkoliv webový prohlížeč, například Microsoft Internet Explorer nebo Netscape Navigator. Tyto internetové prohlížeče jsou používány ve většině finančních institucích, ve kterých by mohla být případně nasazena tato aplikace. Tak odpadá problém s instalací jakéhokoliv klientského programu na straně klienta, což má za následek snížení nákladů na zavádění toho systému.
5.2. Webový Server Webový server je program, který neustále běží na počítači a je pro uživatele neviditelný. Komunikuje s okolním světem pomocí protokolu HTTP11. HTTP protokol vychází z architektury klient-server. Klient se prostřednictvím webového prohlížeče spojí se serverem a pošle mu požadavek na zobrazení konkrétní stránky. Server na klientův požadavek zareaguje zasláním požadované stránky. Přesný formát požadavku a odpovědi je definován v specifikaci protokolu HTTP.
5.2.1.
Windows NTLM autentifikace
Windows NTLM (NT12 LAN13 Manager) je autentizační protokol provozován na platformách Microsoft Windows. NTLM je síťový bezpečnostní protokol, který spolupracuje s dalšími síťovými protokoly Microsoft Windows za účelem ověření uživatele. Tato autentifikace se dnes používá ve většině velkých společností. To znamená, že se uživatele přihlásí do svého počítače a při další potřebě ověřování se už používají jeho přihlašovací údaje. Odpadá potřeba jiného autentifikační mechanismu, což velice usnadňuje práci uživateli, jelikož si nemusí pamatovat žádné přihlašovací údaje navíc. Tím se snižují náklady na implementaci a následně při zavádění tohoto systému.
11
HTTP protokol popisuje norma RFC 2109 dostupná na [26].
12
Zkratka NT znamená „new technology“, což je obchodní označení společnosti Microsoft pro operační systémy
založené na Windows. 13
LAN je zkratka z anglického „Local Area Network“ a ve volném překladu znamená „místní síť“, často se
používá také termín „lokální síť“.
27
5.2.2.
Apache
Apache HTTP Server [22] je softwarový webový server s otevřeným kódem pro Linux, BSD, Microsoft Windows a další platformy. Celý projekt je dílem sdružení The Apache Software Foundation, které se skládá z tisíců návrhářů a programátorů. The Apache Software Foundation je sdružení, které celý projekt spravuje od návrhu přes implementaci až po údržbu programových kódů. Všichni tito pracovníci zastávají svoje pozice jako dobrovolníci, bez peněžních náhrad proto je HTTP Server Apache šířen zcela zdarma a to i se zdrojovými kódy. Proto lze bez nadsázky říci, že je k němu možno vytvořit jakékoliv další možné rozšíření. Oficiální distribuce zahrnuje nemalé množství modulů, které postačují k velké většině implementací webových serverů. Vzhledem k faktu, že je Apache již celou řadu let poměrně široce využívaný webovým serverem, je řada aplikací uzpůsobena k použití v rámci tohoto produktu. Nejčastěji je takto spojován se skriptovacím jazykem PHP, který má internet implementovánu podporu použití jako modulu serveru Apache. Jako jeho nevýhodu se může označit právě otevřenost zdrojových kódů. Každý vidí jak je naprogramovaný a díky tomu se snáze dají hledat bezpečnostní slabiny, které se později mohou zneužít.
5.2.3.
Microsoft Internet Information Server (IIS)
Tento server pochází z dílny společnosti Microsoft. Jedná se o výkonný, velice konfigurovatelný a spolehlivý server. Vždy je využíván společně s operačním systémem Microsoft Windows a skriptovacím jazykem ASP [13]. Jak bylo uvedeno, první probraný HTTP server Apache je dodáván zdarma a je vyvíjen pro většinu používaných platforem. Je tedy možné provozovat jej na libovolném operačním systému, který může zákazníkovi vyhovovat ze zcela jiných důvodů, než si vybírá konkrétní HTTP server. Vlastnost nezávislosti na platformě a operačním systému je tedy velice důležitý fakt stejně tak jako cena. IIS je ovšem aplikace běžící pouze na platformě Windows, která není primárně určena pro funkci webového serveru. Všechny aplikace, které zpřístupňují tyto služby, musí být instalovány zvlášť a tak není zaručena jejich přímá kompatibilita mezi nimi. Konfiguraci serveru lze provádět přes terminál Microsoft Management Console nebo přes webové rozhraní. Bližší informace lze nalézt v [3].
28
5.3. Databázový server Databázové systémy obecně slouží jako permanentí úložiště dat, která jsou různými programy zpracovávána. Pro tyto účely jsou členěny nejprve do databází, které potom obsahují tabulky. V definici je možné nastavit libovolný počet sloupců, který muže každá tabulka obsahovat. Práce s tabulkami probíhá pomocí speciálního jazyka SQL [8], kterým jsou prováděny potřebné operace. Mezi hlavní výhody databází patří: •
Struktura - Celý systém je členem na neomezený počet databází, tabulek a sloupců a to vše na jednom serveru.
•
Jednoduchost - Propracované a složité systémy obsahují vždy rozhraní pro komunikaci s okolím a většinou je snaha mít tyto spojovací body co nejjednodušší.
•
Dotazovací jazyk SQL - Používání uložených dat probíhá pomocí jednoduchého leč komplexního dotazovacího jazyka SQL, jehož příkazy odpovídají uzákoněným standardům. Každý ze systému má určité možnosti navíc a tak se jazyky mohou od sebe mírně lišit.
•
Odladěnost - Databázové systémy mají za sebou mnoho let vývoje a jsou tak postaveny přímo pro svou funkci uchovávání dat. Jsou optimalizovány pro dotazovací jazyk a rychlou práci s daty.
•
Velký počet datových typů - Jazyk SQL obsahuje velké množství datových typů, které lze zvolit pro sloupce tabulek.
•
Přístupová práva - Lze definovat uživatele a jejich možnosti práce s databází. Tyto uživatele lze radit do skupin a tem také nastavovat práva. Lze definovat jak okruhy dat tak i úrovně přístupu k nim.
•
Vícenásobný přístup k datům - Vzhledem k architektuře databázových systému typu klient-server, je nutnost implementace vícenásobného přístupu k
29
datům. Je také třeba vytvořit určitý systém zámku, aby byla možnost data pro jiné uživatele zamknout, aby nedošlo k nežádoucímu přepisu. •
Rychlost - Všechny systémy jsou za dobu provozu vyladěny. Oproti jednoduchému ukládání dat do souboru v místě aplikace jsou databázové systémy řádově rychlejší.
•
Konzistence dat - Většina systému dovoluje vytvářet zachytávací body, mezi nimiž musí být všechny kroky práce s databází vykonány, aby došlo ke skutečnému uložení dat do databáze.
V následujících podkapitolách jsou uvedeny příklady a krátké popisy databázových serverů, které jsou vhodné pro systém CTStat.
5.3.1.
MySQL
MySQL [8] je databázový systém vytvořený švédskou firmou MYSQL AB. Každá databáze je uložena ve vlastním adresáři v datové složce systému, veškeré tabulky jsou v samostatném binárním souboru. Ty mají sloupce se jménem a vlastním datovým typem. MySQL je distribuován zdarma a existuje pro většinu operačních systémů, proto se teší veliké oblibě. Je poměrně široce rozšířeným databázovým systémem používaným zejména pro webové aplikace. Ovladače sloužící k přístupu k databázím jsou podporované v mnoho programovacích jazycích, například C, C++, PHP, .NET a mnoho dalších. MySQL byla od počátku optimalizována především na rychlost, proto donedávna nepodporovala pokročilejší operace jako pohledy, triggery, a uložené procedury. Současná stabilní verze MySQL 5 dovoluje úplné využití cizích klíčů, podporuje objekty, triggery [8], pohledy nebo transakcí. Z těchto důvodů se MySQL stává plnohodnotnou databázi, která je srovnatelná s konkurenčními produkty.
5.3.2.
PostgreSQL
PostgreSQL [24] je plnohodnotným relačním databázovým systémem s otevřeným zdrojovým kódem. Předností systému PostgreSQL je rozšiřitelnost. Systém může být bezproblémově rozšiřován o nové datové typy, funkce operátory, agregační funkce,
30
procedurální jazyky. Dotazovací jazyk vyhovuje standardům SQL92 a SQL99. Tento systém je vyvíjen na Berkeleyoho katedře počítačů kalifornské univerzity. PostgreSQL je výkonný a komplexní systém vedený pod licencí open source. Je distribuován zdarma a se zdrojovými kódy. Kromě základních vlastností, které obsahují všechny databázové systémy, má implementovánu podporu cizích klíčů v tabulkách, triggery nad tabulkami, pohledy mezi více objekty a v neposlední řade také transakce.
5.3.3.
Oracle
Tento databázový systém je nejznámější zástupce komerčně dodávaných databází. Jedná se o komplexní produkt určený pro malé a střední podniky ale i pro velice rozsáhlé databáze. Jeho značnou výhodou je podpora veškerých standardu včetně nejnovějších specifikací jazyka SQL. V něm jsou zařazeny jak triggery, tak transakce nebo práce s objekty. Oracle [23] není pouze čistý databázový systém. Disponuje velkým množstvím přídavného programového vybavení například administrační programy, podpora XML [16] vstupu i výstupu nebo webové rozhraní pro správu. Oracle je také podporován v mnohých programech a některé další software mají implementovány rozhraní pro práci s ním. Tato vlastnost je k vidění většinou u komplexních ekonomických programů pro práci nebo vedení podniku. Celkově se jedná o velice propracovaný, rychlý, ale také značně drahý databázový systém, který je primárně určen především pro rozsáhlá databázová řešení. Pro webové aplikace je tento produkt zbytečně výkonný, velký a drahý.
5.3.4.
Microsoft SQL Server
Microsoft SQL Server je velice komplexní systém pro řešení rozsáhlých databázových aplikací. Obsahuje podporu značného množství standardu, jako XML, Xpath a XSL. K datům lze přistupovat kromě XML a XSL i pomocí URL zadávaných dotazu. Samozřejmostí je aplikace dotazovacího jazyka SQL v poslední normě. V rámci jedné aplikace tohoto serveru může běžet pro zákazníky několik virtuálních serverů, Microsoft SQL Server také podporuje běh na SMP systémech až s dvaatřiceti procesory, nebo jednoduchou propracovanou zálohu dat a spoustu dalších hodnotných funkcí
31
a aplikací. Opět se jedná, stejně tak jako u systému Oracle, o komplexní databázový systém, který je určen pro složitější systémy.
5.4. Značkovací jazyky Každý jazyk se skládá z určitých symbolů. Když se smysluplně sestaví, mohou vyjadřovat a předávat různé informace. Existují jistá pravidla, která nám říkají, jak dané symboly poskládat do slov, vět či odstavců tak, aby informace byla srozumitelná i ostatním. Podobně je tomu i s počítačovými jazyky. Nadefinuje se jeden speciální jazyk, metajazyk, který vymezuje pravidla a symboly jiných jazyků. Pomocí metajazyka jsou přesně určena obecná pravidla pro definici jazyků a podle nich je pak jeden či více konkrétních jazyků nadefinován.
5.4.1.
Jazyk HTML
HTML (Hypertext Markup Language) byl vytvořen v roce 1991 Timem BernersemLee. HTML jazyk se velmi rychle rozšířil a stal se jeden z nejpoužívanějších formátů pro internetové stránky. Na jeho rozšíření se výraznou měrou podílely i samotné prohlížeče. V HTML se používají speciální značky – tagy. Tagy jsou tvořeny znaky „<” a „>” mezi nimiž je název tagu (například: ). Vše ostatní, co není mezi těmito znaky, se zobrazuje jako výsledný text na stránce. Tagy určují, jaký má text význam (např. jestli se jedná o nadpis, tabulku, či hypertextový odkaz). Pokud prohlížeč příslušnému tagu rozumí, provede ho, v opačném případě ho ignoruje. Toto platí i o atributech. Pokud někde chybí koncový tag, prohlížeč se jej snaží odhadnout. Tyto skutečnosti ulehčovaly amatérským tvůrcům webových stránek jejich práci a přispěly k masovému rozšíření jazyka HTML. Na druhou stranu rychlý nástup jazyka HTML měl za následek jeho nekonzistentnost. Mnoho programátorů vytvářelo své stránky a jazyk HTML je nijak neomezoval. Takto zapsaná data jsou proto nevhodná pro strojové zpracování a není ani žádný jednotný algoritmus pomocí kterého by bylo možno takováto data analyzovat (v mnoha případech nejsou použitelná vůbec). Jazyk HTML původně sloužil jako nástroj pro psaní velmi strohých dokumentů a praxi tudíž příliš nevyhovoval. Umožňoval použití pouze několika druhů zvýrazněného textu,
32
vkládání odkazů a obrázků. Byl využíván převážně pro vědecké dokumenty. Chybělo mu totiž jakékoli zkrášlení, které dnes známe. Mnoho tagů tohoto jazyka bylo v rámci konkurenčního boje navrženo výrobci jednotlivých prohlížečů a pouze následně byly některé z nich zahrnuty do doporučení organizace W3C [26] o struktuře HTML. Důsledkem je nekompatibilita některých tagů v prohlížečích různých výrobců. Ještě dnes lze nalézt tagy, které jsou správně zobrazeny jen v určitých prohlížečích a v jiných jsou ignorovány.
5.4.2.
Jazyk XHTML
Jazyk XML (více informací například v [16]) nám nabízí velice lákavou možnost vytvářet si svoje vlastní sady tagů. Avšak u většiny dokumentů zobrazovaných na WWW je to zbytečné. Proč dělat vše od začátku a nevyužít tagy již existující v HTML a prověřené časem? Nabízí se tedy jiná možnost využití jazyka XML. Dále využívat tagy z jazyka HTML a pouze je doplnit o pár dalších tagů, které budou označovat místa důležitá pro vyhledávací roboty. Tuto možnost nám nabízí značkovací jazyk – XHTML (eXtensible HyperText Markup Language – rozšiřitelný hypertextový značkovací jazyk). Je syntézou jazyků HTML 4.0 a XML 1.0 a upravených typových definic dokumentu [16], které určují strukturu, elementy a atributy daného dokumentu. V podstatě se jedná o „přidání inteligence“ do jazyka HTML a zpřísnění syntaktických pravidel. Vývojářům se tedy naskytuje příležitost
využívat
v
rámci
jednoho
dokumentu
možnosti HTML i XML, což začíná být v dnešní době čím dál více oblíbenější. Tak mohou tvůrci webových stránek snadněji přecházet se svými projekty z formátu HTML do XHTML. Jazyk XHTML je zpětně kompatibilní s HTML. Striktnější pravidla mají umožnit použití jednodušších a efektivnějších parserů14. Doba, kterou prohlížeč tráví rozebíráním kódu, je zanedbatelná. Samozřejmě, že jsou i jiná, méně výkonná, „chytrá“ zařízení. Ovšem takový chytrý topinkovač má už dnes v sobě výkonnější procesor, než měly stolní počítače v 14
Slovo „parser“ pochází z anglického slovesa „to parse“ – rozebrat, oddělovat, udělat větný rozbor.
V počítačové terminologii má význam tzv. „syntaktického analyzátoru“. Úkolem syntaktického analyzátoru je například rozpoznat, zda je program zapsán správným způsobem, respektive podle gramatiky daného jazyka.
33
době schválení XHTML. Organizace W3C v roce 2000 vydala doporučení „XHTML 1.0 Recommendation“ definující tento jazyk.
5.5. Technologie pro dynamické generování na straně klienta 5.5.1.
Interpret jazyka
Obecným interpretem jazyka se nazývá program, který umožňuje provedení určitého zdrojového kódu. Tento kód musí podléhat dohodnutým konvencím a pravidlům jazyka. Na rozdíl od překladače interpret nepřekládá kód do formy binárního souboru, ale tento text přímo provádí. Překladače fungují na principu několikanásobného procházení a kompilaci kódu, průběžného ukládání výsledných hodnot, na konci běhu opětovného složení do binární podoby. Ta je většinou ve strojovém jazyce a je přímo spustitelná. Výsledkem je tedy samostatné spustitelný soubor, který nepotřebuje pro svůj běh žádný další nástroj či program. Pravým opakem tohoto principu jsou interprety jazyka. Programový kód je tímto procházen a logický blok od bloku prováděn. Program interpretu nevytváří žádný výsledný spustitelný soubor, pouze vykonává programovým jazykem předepsanou funkční činnost. Zdrojový soubor tohoto jazyka vyžaduje vždy pro svoje spuštění příslušný interpret. Nejedná se tedy o samostatně spustitelný a funkční program, pro jeho běh je nutné použít dalších externích programů, interpretu. Z uvedených vlastností plyne hned několik logických závěrů, výhod a nevýhod. Prvním rozdílem mezi uvedenými principy je rychlost aplikace. V prvním případě překladače je zdrojový kód často optimalizován při překladu na úrovni logických prvků textu. Výsledkem jsou binární data, která jsou určená pro daný systém. U interpreta jazyka je při každém spuštění zdrojového kódu nutnost tento kód procházet, zpracovávat a kontrolovat. Dalším nedostatkem je nutnost instalace externích programů, které zdrojový kód jazyka provedou. Spouštění je realizováno vždy interpretem, který tedy musí být instalován. Probíraný způsob má ovšem oproti kompilaci do binárních souborů i své neodmyslitelné výhody. První výhoda je nezávislost na platformě. Zdrojový kód programu je stále stejný a není nutné jej ladit pro žádný operační systém či platformu. Odpadá tedy problémová část vývoje aplikace, kterou bylo optimalizování pro určité systémy. Vše při spouštění závisí na programu interpretu a jeho sladění s daným systémem. Druhou výhodou je otevřenost zdrojových kódů a možnost jejich úpravy. Všechny programy, které jsou prováděny interpretem, jsou dodávány jako
34
zdrojové kódy. Lze je tedy v případě nutnosti opravit či změnit. Tyto operace nejsou nijak časově ani funkčně náročné.
5.5.2.
CSS
CSS je ta zkratka Cascading Style Sheets [11], česky „kaskádové styly“. Kaskádové, protože se na sebe mohou vrstvit definice stylu, ale platí jenom ta poslední. Mnoho lidí se domnívá, že CSS je skriptovací jazyk. Není tomu tak. CSS je pouze souhrn značek a metod pro grafickou úpravu stránek. Tyto vlastnosti a metody se vpisují přímo do HTML nebo do externího souboru, který je volán z vlastního HTML souboru. CSS je jazyk obsahující sadu vlastností pro definování vzhledu dokumentu. Specifikace vlastností CSS definuje organizace W3C [26]. Proč vlastně jazyk CSS vznikl? Původní definice HTML byla vytvářena pro tvorbu jednoduchých stránek s poměrně malým počtem formátových změn (ty jsou v HTML zajišťovány pomocí tzv. tagů, př. , , atd.). S postupem času však vznikaly stránky ze stále větším počtem formátových změn a to vyžadovalo mnohdy použití mnoha do sebe vnořených tagů. Tím docházelo ke vzniku nepřehledných kódů, které postrádaly jakoukoli strukturu. Navíc jejich byť drobná modifikace byla mnohdy velice složitá a časově náročná. Právě tyto problémy řeší kaskádové styly. Jejich úkolem a účelem je oddělit deklaraci formátového vzhledu od vlastního obsahu, čímž dojde k zpřehlednění HTML dokumentu a popřípadě jeho snazší modifikaci. Co tedy vlastně lze očekávat od CSS? Protože se jedná o popis vzhledu dokumentu je vcelku jasné, že kaskádové styly nejsou náhradou HTML. Jejich použitím se pouze HTML kód doplní a při vhodném aplikováním se též zjednoduší a zefektivní další práce. Kaskádové styly si lze představit jako oddělený popis jednotlivých struktur od místa jejich použití. Od těchto technologií se také odvíjí efektivita výsledného kódu. Výraz kaskádový v CSS vyjadřuje schopnost slučovat jednotlivé styly k vytvoření podrobné definice stylu pro prvek či naopak vytvoření obecných pravidel pro prvky celého dokumentu. Více informací je k dispozici například v [11]
35
5.5.3.
Javascript
Javascript je klientský skriptovací jazyk. Příkazy tohoto jazyka jsou pak provedeny na straně klienta. Tento systém má výhody i nevýhody. Výhodou je mnohem menší zatěžování serveru, na kterém jsou stránky umístěny, a prostředí klienta, které je odlišné od prostředí serveru a lze na něm provádět i věci, které na straně serveru nelze. Velkou nevýhodou je viditelnost kódu v HTML, zdrojový kód si může každý snadno zobrazit a tak vlastně „opsat” pracně vymyšlené skripty. Další informace jsou k dispozici v [4]. Javascript v sobě skrývá určité bezpečnostní problémy. Na straně klienta neumožňuje čtení a zapisování souborů z důvodů, které jsou zřejmé. Nebyl by potom problém jednoduchým programem naprosto znehodnotit obsah pevného disku. Rovněž nepodporuje práci se sítí, až na jednu důležitou výjimku: může donutit webovský prohlížeč k načtení libovolného URL. Další bezpečnostní problémy jsou popsány v [6].
5.6. Technologie pro dynamické generování na serveru 5.6.1.
PHP
PHP [12] (rekurzivní zkratka PHP: Hypertext Preprocessor, „PHP: Hypertextový preprocesor“, původně „Personal Home Page“) je skriptovací programovací jazyk, určený především pro programování dynamických internetových stránek. Nejčastěji se začleňuje přímo do struktury jazyka HTML, ovšem k této práci je výhodnější oddělit skriptovací programovací jazyk od HTML dokumentů, což lze snadno docílit použitím vhodných prostředků, které budou popsány v kapitole o implementaci aplikace. PHP skripty jsou prováděny na straně serveru, k uživateli je přenášen až výsledek jejich činnosti. Syntaxe jazyka kombinuje hned několik programovacích jazyků (Perl, C, Pascal a Java). PHP je nezávislý na platformě, skripty fungují bez úprav na mnoha různých operačních systémech. Obsahuje rozsáhlé knihovny funkcí pro zpracování textu, grafiky, práci se soubory, přístup k většině databázových serverů (mj. MySQL, ODBC, Oracle, PostgreSQL), podporu celé řady internetových protokolů (HTTP, SMTP, SNMP, FTP, IMAP, POP3, LDAP, …) [5]. PHP si automaticky přejímá veškeré proměnné (považuje je za globální) poslané jakoukoliv metodou (POST, GET, COOKIE (pokud administrátor serveru tuto funkci
36
nevypne), ale i SESSION) a umožňuje s nimi dále pracovat. Hodnotu lze ale také získat ze superglobálních proměnných s garancí původu informace (je zaručeno, že data byla odeslána požadovanou metodou). Používání globálních proměnný se z bezpečnostních důvodů nedoporučuje. S verzí PHP 5 se výrazně zlepšil přístup k objektově orientovanému programování tzv. OOP (Object-oriented programming). Přístup je velmi podobný jako v jazyce Java [14]. Hypertext Preprocessor je vyvíjen pro radu platforem a je také k dispozici jeho zdrojový kód. Není tedy přímo svázán s žádným operačním systémem, což je pro tento typ jazyku značná výhoda. Prováděcí program je využíván především ve spojení s http servery. Pro úspěšnost jazyka je nutné, aby podporoval nejvíce užívané servery, tedy Apache a IIS. Celková koncepce PHP je podobná jako u jazyka C. Jedná se o procedurální programování, ve kterém se nerozlišují základní typy proměnných.
5.6.2.
ASP
Active Server Pages (ASP) [13] je technologií firmy Microsoft a tudíž její provoz funguje s IIS (web server od stejné společnosti). Lze ji, ale provozovat i v kombinaci s webovým serverem Apache ovšem jen za podmínky použití speciálního modulu. Využívá se především pro složitější a robustnější aplikace. Jako programovací jazyk slouží Visual Basic, Scripting Edition (VB-Script) nebo v dnešní době ASP.NET [13]. Podpora dalších jazyků je implementována formou modulu. Cílem vývojářů tohoto produktu byla snaha spojit již hotové programovací jazyky, s jazykem HTML a dalšími komponentami, aby byla možnost vytvářet webové aplikace nově používaným způsobem. Obalit znovu použitelný kód do tříd či komponent a v kombinaci s výstupním webovým jazykem HTML skládat dohromady jednoduchým způsobem aplikace. Active Server Pages je založena na objektové technologii COM firmy Microsoft, která je využívaná výhradně na operačním systému Windows. Existují sice modifikace jazyka ASP pro jiné platformy, přesto tato podpora není v současné době dostačující [13]. Velkou výhodou ASP je podpora více programovacích jazyků na této platformě. Není nutné vyvíjet výsledný produkt pouze v jednom jazyce. Interpretované jazyky mají několik
37
značných nevýhod. Byla vytvořena novější verze ASP+, která již obsahuje podporu pro jazyky vyšších tříd C++ a C#. Základní informace o programování v ASP jsou v [13].
5.6.3.
JSP
Java Server Pages [14] jsou částí balíku J2EE (Java 2 Platform, Enterprise Edition), který byl vytvořen s cílem nabídnout vývojářům platformu, která obsahuje široké pole použitelných prvků. Jako programovací jazyk je použita Java. Jedná se o relativně nový a moderní jazyk, který si díky svojí novodobé koncepci nepřináší mnoho neduhů z funkčního programování. Výsledné zdrojové soubory jsou kombinací příkazů jazyka Java a HTML, jedná se tedy o podobnou technologii jako již probírané ASP i PHP. Java Server Pages mají několik značných výhod. Systém postaven na běžném jazyku, který se používá pro vývoj standardních aplikací. Není tedy třeba vyvíjet různé úpravy jazyka pro použití v JSP. Tato výhoda v sobě nese ještě další zjednodušení pro programátory. Nemusí se totiž učit další syntaxi jiného jazyka. Kvůli značné rozšířenosti tohoto jazyka mají Java Server Pages podobnou oblibu. JDBC je samostatné databázové rozhraní, které podporuje drtivou většinu dostupných databází. Není tedy třeba psát kód speciálně pro různé databáze, vše je zprostředkováno pomocí Java Database Connectivity. JSP obsahuje množství vytvořeného kódu pro vývoj webových aplikací, a tak díky vlastnostem jazyka Java není problém si tyto komponenty doplnit o vlastní požadovanou funkčnost. Výsledný programovací kód tímto získává na přehlednosti a jednoduchosti.
5.7. Odůvodnění zvolených technologií Veškeré technologie jsou vybrány s důrazem na snadnou integraci se stávajícím bankovními systémy. Respektive na maximální
5.7.1.
Typ aplikace
Jako typ aplikace byla zvolena webová aplikace. Webová aplikace oproti desktopové má několik výhod. Za prvé se nemusí instalovat žádný klientský program pro přístup do aplikace. Webová aplikace bude umístěna na intranetu dané instituce. Další výhodou je
38
centrální správa celé aplikace. Například při změně dat nebo konfigurace systému se to projeví u všech klientů najednou.
5.7.2.
Webový server
Primárním požadavkem na webový server, na které bude provozován systém CTStat, je podpora PHP skriptů, případně Windows NTLM autentifikace.
Obrázek 9: Ukázka nastavení zabezpečení na IIS 6.0
Pro webový server byl vybrán Microsoft Internet Information Services 6.0, protože již je přímou součástí Windows 2003 Serveru, nemusí se tedy žádný nový program instalovat na tento server. Další velkou výhodou je, že nativně podporuje autentifikaci uživatelů na základě Windows NTLM autentifikace. Odpadá problém se zaváděním nového autorizačního mechanismu, či dalších jiných problémů s vytvořením alternativního autorizačního systému, jako je správa, vytváření nových uživatelských účtů a jeho údržba během provozu.
39
5.7.3.
Databázový server
Pro databázový server byla zvolena MySQL databáze, kvůli její nenáročnosti na systémové prostředky, rychlost a univerzálnost.
5.7.4.
Skriptovací jazyk
Pro tuto aplikaci jsou vhodné prakticky dva skriptovací jazyky ASP.NET a PHP. Při volbě vhodného jazyka se vycházelo z následující poznatků. ASP.NET přináší zajímavý programovací model založený na serverových ovládacích prvcích. Ty mají několik specifických vlastností. ASP serverové prvky reagují na události a umožňují tedy událostmi řízené programování. Dále poskytuje oddělení skriptu od HTML kódu; „skript“ se tak stává spíše plnohodnotným objektově orientovaným programem než skriptem v tradičním slova smyslu. Pokud není stanoveno jinak, automaticky si pamatují svůj stav mezi požadavky. PHP naproti tomu používá model „spaghetti code“, tedy míchání HTML kódu se serverovými vsuvkami. Hlavní výhodou tohoto přístupu je dokonalá kontrola nad generovaným výstupem, což může být v některých scénářích užitečné. Obecně je ale tento model považován spíše za problém, především kvůli obtížné čitelnosti a udržovatelnosti. PHP je skriptováním v pravém slova smyslu, najdou se zde tedy přímočaré funkce pro řešení problémů, výstup je možno generovat pomocí jednoduchého příkazu echo atd. Syntaxi PHP a základní úkony se lze přiměřeně zvládnout v relativně krátké době. Do verze 5 byla navíc přidána široká podpora objektově orientovaného programování (OOP). Vývojář má tedy na výběr, zda použít klasické procedurální nebo objektové programování. Tato jazyková flexibilita je silnou devizou při volbě vhodného jazyka. ASP.NET je naopak „opravdovým“ objektově orientovaným programováním. Dobré zvládnutí ASP.NET je tak otázkou výrazně delšího času, už jen proto, že je potřeba se nejdříve seznámit s .NET Frameworkem jako takovým. PHP má ale i své silné stránky. Především se jedná o otevřenou technologii (PHP je vyvíjeno jako Open Source), což má automaticky několik příjemných důsledků (je možno pozměnit funkčnost, snadno lze opravit nalezenou bezpečnostní chybu, PHP může být vyvíjeno, i kdyby projekt všichni současní vývojáři opustili atd. atd.). Především má však
40
PHP skvělou podporu různých platforem – prakticky lze říct, že ho lze zprovoznit v různých prostředích. Ačkoliv tedy PHP v celé řadě věcí za ASP.NET zaostává, daří se mu nabízet dvě naprosto klíčové vlastnosti platformovou nezávislost a jednoduchost. Velkou výhodou je možnost využít hotové komponenty, jako například Jgraph, FastTemplates, Export to Excel a další. Proto pro tento systém je zvolen PHP jako hlavní skriptovací jazyk.
5.8. Bezpečnost systému Při popisování zabezpečení aplikace se lze setkat se třemi následujícími pojmy, které je nutné nejprve objasnit. •
Authentication (Autentizace) – toto slovo v sobě skrývá proces, který slouží ke zjištění a ověření identity uživatele. Uživatel musí věrohodným způsobem dokázat, že je skutečně ten, za koho se vydává. Nejčastějším způsobem autentizace je zadání uživatelského jména a hesla. Výsledkem procesu je potvrzení nebo vyvrácení identity uživatele.
•
Authorization (Autorizace) – autorizace je proces, při kterém dochází k ověření, zda autentizovaný uživatel má povolen přístup k požadovanému zdroji. Výstupní informací z tohoto procesu je rozhodnutí, zda má uživatel právo přistupovat ke zvolenému zdroji způsobem, který požaduje (čtení, zápis a podobně).
•
Impersonation (Zosobnění) – při použití zosobnění operace, které klient v aplikaci provádí, jsou vykonávány s jinou identitou, než je identita autentizovaného a autorizovaného uživatele.
Autentizace bude prováděna pomocí NTLM Authentication. Metoda Windows autentizace NTLM Authentization nebo též Integrated Windows Authentization pracuje následovně. Při potřebě autentizace odesílá nejprve server webovému klientovi, jako reakci na žádost o přístup k chráněnému zdroji, hlavičku „401 Unauthorized“. Na tuto žádost systém zareaguje odesláním přihlašovacích údajů právě přihlášeného uživatele. Přihlašovací údaje spolu se stejným požadavkem pošle klientský systém zpět serveru. Webový server data ověří
41
a pokud jsou platná, vrátí prohlížeči požadovaný dokument. Pokud data platná nejsou, odpovědí serveru opět bude hlavička „401 Unauthorized“. Odesílány jsou tedy přihlašovací informace, které uživatel zadal při přihlášení k systému na svém lokálním počítači. Celý proces odeslání přihlašovacích dat a následné autorizace na serveru se proto uživateli jeví zcela transparentně. Podmínkou pro bezchybnou funkci této metody však je, aby na obou stranách komunikace byl nainstalován a provozován operační systém typu Windows. Současně je dobré si uvědomit i to, že člověk vlastnící počítač k němu obvykle disponuje i administrátorskými právy a není tudíž pro něj problém přihlásit se k jakémukoliv typu přihlašovací identity. Výhoda metody NTLM Authentization je tedy především pro aplikace, u kterých nejsou běžní uživatelé lokálních počítačů schopni ovlivnit typ přihlašovacího účtu, který využívají a který je jim přiřazen. Pro autorizaci se využívá tzv. „souborová autorizace“. V případě souborové autorizace aplikace spolupracuje s operačním systémem Windows a snaží se usoudit podle typu přihlášeného uživatele, zda má či nemá právo k přístupu k danému zdroji. Při ověřování přístupu jsou využívány tzv. „seznamy řízení přístupu“, ve kterých jsou pro každý soubor uložena jeho přístupová práva, neboli je v nich napsáno, kteří uživatelé mohou který soubor využívat.
5.9. Návrh uživatelského rozhraní Při návrhu uživatelského rozhraní je kladen důraz na maximální jednoduchost a funkčnost všech komponent. Každý prvek v uživatelském rozhraní by měl plnit určitou funkci. Na první pohled by mělo být zřejmé, k čemu tento prvek slouží nebo co představuje. Kvalita návrhu uživatelského rozhraní značně ovlivňuje funkčnost celého systému. Nejčastějších chyb, které se většina uživatelů dopustí při práci s programem, je způsobeno špatným pochopením komponent systému nebo neefektivností používání uživatelského rozhraní. Tímto vším však může být celý systém znehodnocen. Proto by se mělo uživatelské rozhraní vyvíjet jako samostatná část (navíc metody návrhu a testování se značně liší od metod realizace vlastní logiky systému).
42
Při návrhu webových aplikací se často používá velké množství obrázků, jejichž funkce je ze značné části pouze dekorativní. Nepřiměřený počet grafických prvků zbytečně plýtvá místem. Výsledkem je uživatelské rozhraní, které má minimálně grafických prvků, ale zůstává esteticky úhledné a přehledné. Vytvořit dobré rozhraní bývá velmi složitý úkol, protože vývoj je hodně ovlivňován následujícími skutečnostmi. •
Optimální vlastnosti se stěží odhadují, závisí především na psychologii, dovednostech a znalostech uživatelů.
•
Testovat mohou pouze budoucí uživatelé a to ještě omezený počet.
•
Vlastnosti uživatelů se během používání systému mohou změnit.
•
Je třeba počítat s lidmi, kteří jsou na užívání podobných aplikacích zvyklí nebo naopak uživatelé, kteří na podobné systémy přistupují zřídka
Návrh uživatelského rozhraní byl zaměřen především na barvu, styl a velikost jednotlivých komponent. Grafické rozhraní (Obrázek 10) systému CTStat vypadá jako klasická webová stránka s některými specifickými funkcemi (např. filtr zobrazení dat, tisk dat apod.).
43
CTStat Statistika clearingových transakcí
Hlavní menu Filtr
Zobrazená data
Obrázek 10: Návrh orientační struktury aplikace
Z důvodu lehčí uživatelské orientace se zvolilo jednotné barevné schéma celé aplikace znázorněné na obrázku (viz. Obrázek 10). Pomocí stejného barevného schématu bude reprezentována většina součástí realizované aplikace. Až do doby ukončení práce v systému bude dané barevné schéma zachované. Jednotné barevné schéma má svůj velký význam při zavádění systému do povědomí uživatelů a zároveň ovlivňuje úspěšné uchycení ve společnosti. Všechny komponenty celého systému budou zobrazeny pomocí základních barev: •
barva písma (modrá) – barva všech nápisů
•
barva písma tlačítek (černá) – barva písma použitého na tlačítkách
•
barva komponent (světle šedá) – barva pozadí komponenty
•
barva obrazců (šedá) – barva podkladu logicky seskupených komponent
•
barva pozadí (světle šedá) – barva pozadí celé aplikace
44
5.10. Návrh databáze Při návrhu aplikace, která načítá nebo ukládá informace, je jedním z nejdůležitějších prvních kroků správná volba datových struktur, ve kterých budou tato data uchována. Pro ukládání dat se doporučuje zásadně používat pouze databáze. K aplikacím totiž může přistupovat více uživatelů najednou a např. při ukládání dat do souborů se nelze vyhnout nutnosti tyto soubory např. správně zamykat nebo jiné, na první pohled, skryté problémy. Databáze navíc nabízí nesrovnatelně větší komfort při jakékoliv manipulaci s daty. Optimálnímu návrhu databáze se věnuje [4], obvykle ale stačí používat běžný pohled na data a dodržovat několik pravidel: •
Hodnoty v jednotlivých sloupcích tabulek by měly být vnitřně nedělitelné. Je tedy např. lepší ukládat samostatně křestní jméno a příjmení než oba tyto údaje jako celkové jméno.
•
Data by měla být ukládána do sloupců správných typů. Pokud pro některá data neexistuje odpovídající databázový typ (např. telefonní číslo), lze použít pro něj jednotný formát (nejlépe podle již existující normy).
•
Jednotlivé řádky by měly mít jednoznačný identifikátor (primární klíč) nezávislý na uložených datech. Nezávislost na datech je důležitá kvůli možnosti libovolná data změnit, skutečných jednoznačných identifikátorů navíc ve skutečném životě není moc (nelze se spolehnout např. ani na rodné číslo). Tento identifikátor se nikde nemusí zobrazovat, ale použije se při aktualizaci nebo mazání záznamů, při odkazování na záznam z jiných tabulek a podobně.
•
Veškerá data kromě odkazů na primární klíče by v databázi měla být uložena právě jednou.
•
Návrh databáze by měl být pevný a aplikace by ani neměla mít právo modifikovat strukturu existujících tabulek nebo vytvářet tabulky nové.
•
Dobrou zásadou je také ukládat opravdu všechna data do databáze a ne např. přímo do zdrojového kódu. Při vytvoření vhodného administračního rozhraní lze
45
pak změnit zdánlivě neměnnou položku, jako např. cenu poštovného a balného nebo výši DPH. Základní analýzou požadavků na systém byl navržen fundamentální datový model viz. Obrázek 11. Tento datový model je znázorněn v Chenově notaci [7]. Při konzultaci s budoucími uživateli a lidmi znalými procesu zpracování a tvorby clearingových souborů se dospělo k názoru, že tento koncepční datový model bude plně respektovat datové nároky navazujícího systému pro statistiku clearingových platebních transakcí. Jednoduchost tohoto modelu zabezpečuje přehlednost a rychlou orientaci a plní požadavky pro budoucí rozšíření.
Obrázek 11: Koncepční datový model
46
Centrem celého systému je tabulka platebních příkazů. Při návrhu modelu je potřeba zvážit zda-li použít jednu tabulku na platební příkazy nebo mít dvě separátní tabulky pro příchozí a odchozí transakce. Tyto dva scénáře jsou si rovnocenné avšak liší se zatížením modelu duplicitními atributy. Naproti tomu, dvě tabulky by poskytovaly rozložení zátěže. Po testování obou variant se přistoupilo k první variantě, protože narůst výkonnosti druhé varianty nevyvažoval její nedostatky. Podrobnosti datového modelu jsou popsány v kapitole věnované implementaci.
47
6. Implementace 6.1. Webový diagram Základní koncept hierarchie systému CTStat má následující charakter. Existuje jedna centrální domovská stránka, červená položka viz. Obrázek 12. V základním menu na hlavní stránce jsou zobrazené globální sekce tzv. „druhá úroveň“, modré položky. Na třetí úrovni se nachází už konkrétní sekce tohoto systému, zelené a fialové položky na obrázku (viz. Obrázek 12). Do zelených položek má přístup běžný uživatel a do fialových položek má přístup pouze administrátor systému. Modré položky webového diagramu tvoří základní navigační menu. Platby
Příchozí platby Odchozí platby
Statistiky účtů
Účty nejvetšími příchozími transakcemi Účty nejvetšími odchozími transakcemi
Účty
Výpis účtů Editace účtů
Home
Import účtů Přehled
Denní přehled Podezřelé transakce příchozí Podezřelé transakce odchozí
Import
Import clearingových souborů Import účtů
Nastavení
Kódy bank Základní nastavení
Obrázek 12: Webový diagram systému
48
Na úvodní straně (Home) se vyskytují především odkazy k důležitým částem nástroje. Je zde uvedena krátká charakteristika nástroje, případné aktuální informace o systému. Ostatní stránky jsou již zařazeny do jednotlivých kategorií. Druhá úroveň stránek se rozčleňuje do šesti kategorií: •
Platby – hlavní stránka se statistikou odchozích a příchozích plateb. Statistiky jsou diferencovány do dvou samostatných stránek. Zobrazení všech statistik lze přehledně vytisknout pomocí ikony tiskárny, která je umístěna vpravo nahoře nebo vyexportovat do formátu Microsoft Office Excel.
•
Statistiky účtů - slouží k prohlížení účtů, které realizovaly větší počet platebních transakcí přes tento systém. Statistiky jsou rozděleny do dvou samostatných stránek příchozí a odchozí platby podobně jako u plateb.
•
Účty - zobrazení účtů, které někdy realizovaly platbu přes clearing a byly importovány do systému. Vhodné k rychlému hledání informacích o účtech v systému.
•
Přehled - stránka s grafickým denním přehledem platebních transakcí. Je zobrazena jako sloupcový graf. U každého dne jsou dva sloupce, jeden je pro příchozí platby a druhý pro odchozí. Zároveň jsou do přehledu zařazeny i podezřelé transakce, jak příchozí tak odchozí.
•
Import - slouží k importu clearingových souborů do systému. Systém rozeznává příchozí a odchozí clearingové soubory podle předpony souborů a příjme clearingové soubory pouze podle zadané přípony.
•
Nastavení - globální nastavení programu. K tomuto nastavení mají přístup jen administrátoři systému.
49
6.2. Struktura stránek se statistikami Hlavní struktura stránek systému CTStat se rozčleňuje do tří výchozích bloků. Prvním blokem je základní menu, které je situováno vlevo nahoře. Pod první blok je alokován blok s filtrem, který slouží k filtraci zobrazovaných dat. Poslední blok tvoří zobrazená data v přehledné tabulce. Pokud je položek více jak na jednu stránku, potom jsou interpretovaná data rozdělena do více stránek kvůli přehlednosti vypsaných údajů. Mezi těmito stránkami lze listovat pomocí posuvníku, který je umístěn pod tabulkou s daty.
6.2.1.
Hlavní navigační menu
Poskytuje primární navigaci v programu. Je použito tzv. horizontální dvouúrovňové hover15 menu (menu reagující na kurzor). Výchozí položky reprezentují jeden řádek. Při každém najetí myši nad položkou v hlavním menu se zobrazí příslušné podmenu. Tímto je dosaženo maximální přehlednosti a strukturovanosti celého menu (viz. Obrázek 13).
Obrázek 13: Hlavní menu
6.2.2.
Filtr dat
Filtr primárně slouží k selekci požadovaných dat. Jelikož systém obsahuje velké množství dat, která budou vypisována, je lepší tento výpis zkrátit na minimální délku. Jako položky filtru byly zvoleny následující: • • • • • • • •
15
„datum od“ ve formátu „dd.mm.rrrr“ „datum do“ ve formátu „dd.mm.rrrr“ počet zobrazených položek na jednu stránku celková částka vetší než celková částka menší než název účtu / klienta číslo účtu zobrazovat platby pouze vybrané banky
Anglický termín hover má význam „vznášet se, potulovat se“, ve smyslu návrhu webového vzhledu to je
„přejíždět myší“.
50
Toto jsou základní položky většiny použitých filtrů v systému. U výpisu všech účtů jsou použity jen filtry týkající se přímo účtů (název účtu, číslo účtu, název banky). U položek filtru typu datum je navíc zobrazen ikona kalendáře s odkazem na vysouvací javascriptový kalendář (viz. Obrázek 14) Tento kalendář usnadňuje výběr požadovaného časového rozmezí.
Obrázek 14: Javascriptový kalendář
Specifické položky filtru jsou nastavené na určité výchozí hodnoty. Například hodnota filtru „počet položek na stránku“ je 25 záznamů na stránku. Ve výpisu transakcí je nastavena hodnota „Datum od“ přesně o měsíc méně, jak je dnešní datum a hodnota „Datum do“ je právě dnešní datum. Tímto jsou pouze zobrazeny záznamy za poslední měsíc, což urychluje prvotní vypsání stránek se statistikami plateb. Všechny zmíněné hodnoty lze jednoduše změnit editací souboru config.ini.
6.2.3.
Zobrazená data
Data jsou interpretována v přehledné tabulce (viz. Obrázek 16). Pokud je záznamů více jako je hodnota filtru „počet položek na stránku“, potom jsou data rozdělena do více samostatných stránek. Přesuny v těchto stránkách zajišťuje tzv. „posuvník“ (viz. Obrázek 15), který je umístěn pod zobrazovanou tabulkou. První hodnota posuvníku je číslo aktuálně zobrazené strany a další je celkový počet stran.
Obrázek 15: Posuvník hlavní tabulky
51
Obrázek 16: Přehledné zobrazení platebních transakcí
52
6.3. Popis implementace Implementaci systému je realizována ve skriptovacím jazyce PHP maximálním využitím objektově orientovaného programování, které nabízí poslední verze 5.1. Jako podpůrný prostředek pro práci s PHP byl použit šablonovací systém FastTemplate 1.1.0 [18].
6.3.1.
Šablonovací systém (FastTemplate)
Jedním z důvodu výběru programovacího jazyka byla výhoda oddělení HTML kódu od samotného PHP a právě z jednou možností, jak lze tohoto docílit, je použití šablonovacího systému. Hlavním posláním šablonovacího systému FastTemplates je oddělení PHP kódu od HTML a tím celý zdrojový kód zpřehlednit. Hlavní argument FastTemplates je fakt, že rozsáhlé PHP projekty ztrácejí přehlednost, která se jim dá vrátit jedině oddělením PHP od HTML. U větších projektů je k výhodné mít důsledně oddělenou aplikační vrstvu aplikace od prezentační. Další velkou výhodou šablonovacího systému je to, že pokud se nedefinuje jinak, tak jsou všechna vypisovaná data automaticky escapovaná16, takže nehrozí nebezpečí XSS (Cross-Site Scripting). Další informace k problematice XSS lze najít v [6]. Oddělením PHP (vlastní kód a logika aplikace) od HTML (design), je možné snadno měnit vzhled aplikace bez zásahu do programu a tudíž bez znalosti PHP. Může být rovněž vytvořeno několik různých šablon a mít vlastně k jedné aplikaci několik designů nebo odlišných jazykových verzí. I když se nevyužije žádná ze jmenovaných možností, stále lze získat daleko přehlednější PHP kód, než když se bude PHP s HTML prokládat. Šablona ve FastTemplates je textový soubor s HTML formátem, který může navíc obsahovat proměnné, které jsou ve výsledku nahrazeny skutečnými hodnotami. Proměnná se do šablony vkládá pomocí složených závorek, např. {PROMENNA}.
16
Escapovat v tomto slova smyslu znamená použití speciálních funkcí k odstranění nežádoucích znaků.
Nežádoucími znaky jsou například „/“ nebo ,,<”, ty je potřeba nahradit jinou sekvencí. V PHP jsou tři základní escapovací funkce, které se používají v různých situacích: addslashes, htmlspecialchars a urlencode. Více informací lze nalézt v [12].
53
Příklad jednoduché šablony může vypadat takto:
Už z názvu vyplývá, že FastTemplates by měly být rychlé. Autor systému FastTemplates [18] tvrdí, že k interpolaci proměnné používá pouze jeden regulární výraz. Ze zdrojového kódu [18] však vyplývá, že pokud je potřeba nahradit více proměnných, interpolace se provede vícekrát. Určitá ztráta rychlosti oproti klasickému „bez šablonovému“ přístupu tedy pochopitelně nastává. Postup při používání FastTemplates FastTemplates je PHP třída, jejíž základní použití sestává ze čtyř kroků: •
Definice šablon
•
Přiřazení šablon k souborům
•
Zpracování (parse) = nahrazení proměnných hodnotami
•
Tisk nebo jiné užití výsledků
Příklad na pochopení celého principu: Například šablona je nazvaná jako „stranka.html“ s následujícím obsahem: {TITULEK} {TEXT}
54
Použití této šablony názorně ilustruje následující PHP kód: define( array( stranka => "stranka.tpl" )); $tpl->assign(TITLE, "Titulek stránky"); $tpl->assign(TEXT, "Text, který se zobrazí na stránce..."); $tpl->parse(VYSLEDEK, "stranka"); $tpl->FastPrint(VYSLEDEK); ?>
Příkaz funkce define() má jako parametr pole. Proto lze jedním voláním funkce definovat více šablon. Toto volání je výhodné umístit do samostatného souboru, který pak bude použit ve všech PHP skriptech. Tím se značně zjednoduší práce s šablonovací systémem FastTemplates. Funkce define() tedy pouze přiřazuje jména šablon, se kterými se operuje, ke skutečným souborům. Funkce assign() vlastně zavádí vnitřní proměnné v třídě FastTemplates. Kdyby se totiž měly interpolovat veškeré proměnné definované ve skriptu, což by bylo také možné, trvalo by to podstatně déle. Proto ta nutnost zavádění vnitřních proměnných. Funkce assign() využívá možnosti přetěžování operátorů v PHP, díky čemuž jí lze volat dvěma způsoby. První je ten, který je aplikován výše, druhý způsob se vyplatí, pokud se přiřazuje více proměnných na jednou, je použit jako parametr pole. Výše uvedené přiřazení by bylo možné udělat pomocí jednoho volání funkce assign() následovně:
$tpl->assign( array( TITLE => 'Titulek stránky', TEXT => 'Text, který se zobrazí na stránce.'));
Výstupy parsování šablon nemusí být nutně ihned posílat na výstup. Může se totiž elegantně spojovat s dalšími. Následující kód k proměnné VYSLEDEK přidá výstup další šablony (díky tečce před jménem šablony). $tpl->parse(VYSLEDEK, ".dalsi"); $tpl->FastPrint(VYSLEDEK);
55
Další možností je vnořovat šablony do sebe. Zde lze využít toho, že výstup šablony je automaticky uložen ve FastTemplates jako vnitřní proměnná (např. výše vznikne proměnná VYSLEDEK, která obsahuje výstup šablony). Tato proměnná je pak jednoduše použita v jiné šabloně, která se bude generovat následně. Takto se vytvoří poměrně složitá struktura vnořených šablon. Například bude šablona s hlavní stránkou, v ní bude další šablona obsahující tabulku a v ní se několikrát zopakuje šablona s jednotlivými řádky tabulky. Šablony neobsahují nic, než holé proměnné. Nemají v sobě žádnou logiku. Veškerá logika zůstává na straně PHP. V šablonách je pouze design. Účelem FastTemplates je, ale eliminovat HTML z PHP kódu, nikoli hledat nové cesty, jak ho tam zase dostat. Jediné rozšíření šablony, které je možné je tzv. dynamický blok, což je vlastně šablona definovaná uvnitř jiné šablony. Na závěr lze konstatovat, že FastTemplates pochopitelně nejsou jediným exemplářem tohoto druhu, nicméně pro tento systém jsou dostačující. Zdrojový kód FastTemplates je k dispozici na [18].
6.3.2.
Generování grafů
Generování obrázkových grafů v PHP tak, aby vypadaly atraktivně, je relativně náročné. K usnadnění tohoto úkolu je použito souboru knihoven pod označením JpGraph [21]. JpGraph je přídavná knihovna do PHP, která není standardní součástí distribuce PHP. Je plně objektově orientovaná a naprogramována v PHP. Pomocí JpGraph lze kreslit, resp. generovat následující grafy: • • • • • •
sloupcové bodové linkové plošné 3D koláčové aj.
Výše jmenované typy grafů lze vykreslovat v mnoha podobách. Pro konkrétnější představu použití a nastínění nepřeberných možností této knihovny poslouží uvedený příklad grafu, který je použit v tomto systému.
56
Ukázka PHP kódu použitého při generování sloupcového grafu při statistiky plateb: query(get_sql_graph($_VAR,$cfg["type"]["outcoming"])); $y2data = parse_array2_to_array1($s->getfetcharray()); $s->query(get_sql_graph($_VAR,$cfg["type"]["incoming"])); $ydata = parse_array2_to_array1($s->getfetcharray()); $s->query(get_sql_graph_label_x($_VAR)); // Setup labels $xdata = parse_array2_to_array1($s->getfetcharray()); // Create the graph. These two calls are always required $graph = new Graph(800,500,"auto"); //výška, šírka, automaticky cachovat $graph->img->SetMargin(80,40,40,80);//left, right, top , bottom $graph->SetScale("textlin"); //set scale for x,y $graph->SetShadow(); $graph->title->Set("Denní přehled objemu transakcí"); $graph->xaxis->SetTickLabels($xdata); $graph->xaxis->SetFont(FF_ARIAL,FS_NORMAL,8); $graph->xaxis->SetLabelAngle(45); $graph->xaxis->title->Set("Dny"); $graph->yaxis->title->Set("Částka"); $graph->yaxis->SetColor("blue"); // Create the linear plot $lineplot=new BarPlot($ydata); //zakreselni dat do grafu $lineplot->SetFillColor("blue"); $lineplot->SetWeight(2); $lineplot->SetLegend("příchozí"); $lineplot2=new BarPlot($y2data); $lineplot2->SetFillColor("orange"); $lineplot2->SetWeight(2); $lineplot2->SetLegend("odchozí"); $gbplot = new GroupBarPlot(array($lineplot2,$lineplot)); $graph->Add($gbplot);// přidání sloupců do grafu $graph->Stroke(); //výsledné zobrazení grafu ?>
57
Obrázek 17: Příklad sloupcového grafu
Příklad výstupu sloupcového grafu při generování statistiky přehledu objemu transakcí (viz. Obrázek 17).
58
6.4. Datový model Na obrázku níže (Obrázek 18) je zobrazen datový diagram tzv. „E-R diagram“ v notaci James Martin [9]. ER diagramy, zkráceně ERD, jsou z anglického spojení „Entity-relationship diagram“. Objekty, kterou jsou charakterizovány skupinou k sobě náležících údajů, se nazývají datové entity. ER diagramy tedy popisují vzájemné vztahy mezi jednotlivými entitami datového modelu. K zobrazení vztahů je použita notace James Martin popsaná v [9]. Notace je rozšířena o vyjádření jednotlivých atributů: • • • • •
NOT NULL – atribut je povinný NULL – atribut je nepovinný IDENTITY – atribut je unikátní PK – primární klíč (PRIMARY KEY) FK – cizí klíč (FOREIGN KEY)
Obrázek 18: Datový model
59
Popis tabulek •
C01_TRANSACTION – v této tabulce jsou uchovány informace o provedených platebních transakcí. Primární klíč je C01_ID. Atribut C01_TYPE určuje, jestli se jedná o příchozí nebo odchozí platební transakci, zatímco atribut C01_HD_TYPE obsahuje typ clearingové platby. Přehled všech typů clearingových plateb lze nalézt v [1]. Slovo DEBET v názvech atributů znamená příjemce a slovo KREDIT představuje plátce. Atribut C01_SERVICE určuje, zda-li transakce není pouze servisní transakcí. Servisní transakce nejsou zahrnuty do běžného výpisu, jelikož se nejedná o platby provedené klienty, ale samotnými finančními institucemi. Atribut C01_HD_BANKA_ID_1 představuje kód
banky
odesílatele
C01_HD_BANKA_ID_2
v příchozím představuje
clearingovém kód
banky
souboru příjemce
a
atribut
v příchozím
clearingovém souboru. V odchozí clearingovém souboru je tomu přesně naopak. U ostatních atributů je jejich funkce shodná s názvem. •
C02_BANK_CODE – zde jsou uloženy informace o finančních institucích mající oprávnění k mezibankovním platbám k datu 19.11.2006. Atribut C02_ID je nejen primárním klíčem, ale zároveň představuje identifikační číslo banky (BANIS) podle číselníku AP0001 [10].
•
C03_CONFIG – tato tabulka obsahuje konfigurační proměnné.
•
C04_ACCOUNT - zde se uchovávají informace o účtech, které někdy realizovaly platbu přes clearingový systém. Jsou zde uloženy následující údaje o účtech jako jsou jméno, číslo, id banky, u které je veden tento účet.
•
C05_DATE – v této tabulce jsou uloženy čísla představující datum od 1.1.2000 do 1.1.2011. Například číslo 20000101 představuje datum 1.1.2000.
60
6.5. Proces importu clearingových souborů Import clearingových souborů do systému probíhá ve 4 navazujících fázích, které jsou podrobněji popsány v následujících 4 podkapitolách.
6.5.1.
Fáze 1 – specifikace importovaných souborů
V prvním kroku se specifikuje adresář, ve kterém jsou uloženy clearingové soubory určené k importu. Pro určení zdrojového adresáře stačí specifikovat pouze jeden soubor, který se v něm nachází. (Toto je nedostatek HTML, protože políčko „Select file“ umí vybrat pouze soubor, nikoliv celý adresář.). Navíc jsou v prvním kroku další políčka pro bližší specifikaci předpony odchozích a příchozích clearingových souborů. Tyto políčka jsou důležitá tím, že tento systém rozlišuje příchozí a odchozí clearingové soubory na základě jejich předpony. Je tedy nezbytné, aby všechny clearingové soubory měli specifickou předponu jinou pro odchozí a odlišnou pro příchozí. Pro snazší orientaci je zde specifikována i přípona souborů.
6.5.2.
Fáze 2 – import souborů
Ve druhém kroku importu se načtou soubory, které se nacházejí ve zvoleném adresáři. V levém sloupci jsou umístěny příchozí clearingové soubory a v pravém jsou odchozí clearingové soubory. U každého souboru je zaškrtávací políčko, kde lze zvolit zda-li daný clearingový soubor má být importován či nikoliv. Pro snazší import celého adresáře je zde buton „označit vše“ a „odznačit vše“. Při implementaci toho nástroje se při importu clearingových souborů vyskytl výkonnostní problém, který se projevil pří testování prototypu. Jelikož tento nástroj je vhodný pro jednorázové použití je nezbytné, aby uměl najednou importovat velké množství clearingových souborů. V první verzi prototypu bylo importování řešeno pouze klasickými SQL inserty. Tudíž toto řešení vyžadovalo delší spojení webového a databázového serveru. Toto spojení je vzhledem k bezpečnosti a stálosti obou serverů omezeno. A už při importování 30 clearingových souborů s řádově 10 000 položkami docházelo předčasnému ukončení spojení mezi databázovým a webovým serverem ze strany PHP.
61
INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [(col_name,...)] VALUES ({expr | DEFAULT},...),(...),... [ ON DUPLICATE KEY UPDATE col_name=expr, ... ] Obrázek 19: Obecný popis SQL příkazu INSERT
Po bližším prostudování dokumentace k MySQL databázi [8] bylo nalezeno jiné řešení, které odstranilo výše uvedený problém. Toto řešení spočívalo použití příkazu „LOAD DATA INFILE“. Příkaz „LOAD DATA INFILE“ čte data po řádcích z textového souboru a zapisuje je přímo do příslušné tabulky. Toto vkládaní do tabulky je velice rychlé. Název importovaného souboru musí být zadán, jako absolutní cesta k souboru v textové podobě ohraničený jednoduchými uvozovkami. Formát importovaného souboru je obyčejný CSV (Comma Separated Values) soubor. LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name' [REPLACE | IGNORE] INTO TABLE tbl_name [FIELDS [TERMINATED BY 'string'] [[OPTIONALLY] ENCLOSED BY 'char'] [ESCAPED BY 'char'] ] [LINES [STARTING BY 'string'] [TERMINATED BY 'string'] ] [IGNORE number LINES] [(col_name_or_user_var,...)] [SET col_name = expr,...)] Obrázek 13: Obecný popis příkazu LOAD DATA INFILE
Pomocí vícenásobného vkládání dat přímo z textového souboru lze dosáhnout bezproblémového importování 500 000 položek najednou.
6.5.3.
Fáze 3 – výsledek importu
Ve třetím kroku se zobrazí právě importované soubory v přehledné tabulce. Ve výsledné tabulce jsou údaje o názvu souboru, datum vytvoření souboru, velikosti souboru, počet importovaných plateb a počet importovaných účtů. V této fázi importu jsou importovány i duplicitní účty, které je nutné v dalším kroku odstranit.
62
6.5.4.
Fáze 4 – odstranění duplicitních účtů
Ve čtvrtém a posledním kroku dojde k odstranění duplicitních účtů. Jelikož se pro rychlost aplikace vytváří pomocná tabulka účtů a v té je až 75% účtů duplicitních je potřeba z tohoto systému odstranit. Odstranění účtů probíhá pomocí několika SQL příkazů. Jako prvním řešení mě napadlo, byl složitý SQL příkaz, který vybere všechny rozdílné řádky a poté udělá množinový rozdíl z původní tabulky. Tento výsledný rozdíl jsou tedy účty, které jsou duplicitní a je nutné je odstranit. Tento způsob řešení také narazil na výkonnostní problémy s vypršením spojením mezi databázovým a webovým serverem. Proto bylo posléze přistoupeno k jinému jednoduššímu řešení. Toto řešení spočívá ve vytvoření dočasné tabulky, která bude vytvářena jako výběr z původní tabulky, ale pouze těch neduplicitních řádků. Následně se provede zrušení původní tabulky a přejmenování dočasné tabulky na jméno té původní. Jelikož při vytváření nové tabulky jako výběr, dojde ke ztrátě údajů o vlastnosti databázové tabulky, například který sloupec je primární a další. Je nutné tyto ztracené údaje doplnit pomocí příkazu „ALTER TABLE“. DROP TABLE IF EXISTS c000_view_account; CREATE table c000_view_account AS SELECT * FROM `c04_account` GROUP BY `C04_NUMBER`, `C04_BC`; DROP TABLE IF EXISTS c04_account; ALTER TABLE c000_view_account RENAME c04_account; ALTER TABLE `c04_account` ADD PRIMARY KEY ( `C04_ID` ); ALTER TABLE `c04_account` CHANGE `C04_ID` `C04_ID` BIGINT( 20 ) NOT NULL AUTO_INCREMENT; ALTER TABLE `c04_account` CHANGE `C04_NAME` `C04_NAME` VARCHAR( 255 ); DROP TABLE IF EXISTS c000_view_account; Obrázek 14: SQL příkazy pro odstranění duplicitních účtů
6.6. Požadavky na systém Při vývoji systému CTStat byly použity následující verze softwarových prostředků: • • • •
Webový server: Microsoft Internet Information Server 6.0 Skriptovací jazyk: PHP 5.1.0 Databázový server: MySQL 5.0 Webový prohlížeč: Microsoft Internet Explorer 6.0 nebo Mozilla Firefox 1.5.0.8
Většina konfigurací softwarových prostředků jsou ve výchozím stavu, který se nastaví při jejich instalaci. Konfiguraci skriptovacího jazyka PHP popisuje příloha C (instalační příručka). Pro zavedení tohoto systému je tedy nutné použít tyto verze nebo kompatibilní vyšší těchto prostředků.
63
7. Testování Testování je důležitým krokem k odstranění chyb, které obsahuje nově vyvíjený systém. Nutnou součástí vývoje je testování, kterým se ověřuje správná funkčnost nebo umožňuje nalézt případné chyby. Testování použité v této práci je založeno na dvou metodách, které jsou popsány níže. Testování se zúčastnilo celkem 5 osob (testerů). Dvě osoby zastávaly roli administrátora systému či pokročilejšího uživatele. Zbylé tři osoby plnily funkci běžného uživatele. Běžní uživatelé pro toto testování byli vybráni z finančních oddělení společností, zatímco administrátoři systému byly vybrání z oblasti technické podpory bankovní instituce. Tento výběr zabezpečil testování systému z uživatelského i provozního hlediska. Před testováním byli všichni stručně seznámeni s účelem této aplikace. První část testu byla metoda Cardsorting. V další části se uživatelé v krátkosti seznámili s používáním nástroje a poté se přistoupilo k druhé testovací metodě Usability testu.
7.1. Popis testovacích metod 7.1.1.
Card-sorting metoda
Informace o metodě jsou uvedené v literatuře [15]. Pro tento test byly připraveny malé papírové kartičky s následujícími jmény aktivit, které byly zamýšleny dát do jednotlivých menu: • • • • • • • • • • • •
„statistika příchozích plateb“ „statistika odchozích plateb“ „účty s největšími příchozími transakcemi“ „účty s největšími odchozími transakcemi“ „výpis účtů“ „editace účtů“ „import účtů“ „grafický denní přehled platebních transakcí“ „podezřelé transakce“ „podezřelé transakce odchozí“ „import clearingových souborů“ „import účtů“
64
Po testerech bylo požadováno, aby kartičky seřadili do určitých celků tak, aby pojmy, o kterých si myslí, že patří k sobě, byly ve stejné skupině. Dále jim byly rozdány prázdné kartičky, na které měli napsat název dané skupiny. Pokud nevěděli kam daný pojem zařadit, museli to písemně poznamenat, že takto nemohli udělat.
7.1.2.
Testování použitelnosti (Usability test)
Použitelnost (usability) je velice obsáhlý obor, o kterém se lze dovědět více například v [25]. Dobře použitelné aplikace jsou takové, na kterých se uživatel rychle a intuitivně dostane k hledané informaci a lehce se zorientuje. Základem dobře použitelných aplikací je především kvalitní informační architektura a propracovaná navigace. Použitelnost aplikací lze odborně odhadnout jen do určité míry. Některé zásady sice platí vždy, ale rozhodující je především testování s věrohodným vzorkem potenciálních uživatelů (tzv. user testing). I ty nejmenší detaily hrají svou roli - volba slov v navigačním menu, grafické odlišení odkazů, rozmístění obsahu na stránce, velikost písma a desítky dalších. Každý uživatel je jiný, a proto se nelze spoléhat jen na osobní zkušenosti autora aplikace. Základem testování použitelnosti je detailní scénář navržený na míru konkrétní aplikaci a jejich hlavním přínosům. Vybranému vzorku 5-15 uživatelů předložit testovanou aplikaci (případně jejich grafický návrh) spolu s konkrétními úkoly, které mají v testované aplikaci splnit. Při plnění úkolů je nutné, uživatele pečlivě pozorovat a zaznamenávat všechny jejich reakce, úspěchy i neúspěchy.
65
Seznam testovacích scénářů •
Zobrazit všechny příchozí platební transakce za období minulého týdne, které přišly od Komerční banky.
•
Zobrazit všechny odchozí platby z čísla účtu 11111111/0800 za minulý kalendářní měsíc.
•
Vypsat všechny účty v systému, které jsou vedeny u Komerční banky.
•
Najít účty, které by mohly mít spojitost se společností „Firma Praha“.
•
Zobrazit graf se statistikou platebních transakcí účtů společnosti „Firma Praha“ za poslední kalendářní měsíc.
•
Najít minimálně jednu skupinu podezřelých příchozí transakci za předminulý kalendářní měsíc.
7.2. Shrnutí výsledků testů 7.2.1.
Card-sorting metoda
Výsledky této metody mohou být zařazeny do dvou skupin. Jedna skupina testovaných uživatelů seřadila karty do tří kategorií. První kategorie byla převážně nazvána „účty“. V této kategorii pak byly všechny položky, které se týkali účtů. Druhá kategorie byla pojmenována „platby“ a byly do ní zařazeny všechny položky týkající se plateb. Jako třetí skupina byla samostatně položka „import clearingových souborů“. Lze si to vysvětlit tím, že v jejím názvu nebylo žádné ze slov „platba“ nebo „účet“. Druhá skupina testerů seřadila kartičky do více kategorií. V první kategorii byly všechny kartičky, s odchozími transakcemi a ve druhé položky s příchozími transakcemi. V další kategorii byly položky určené k importu dat. Samostatná kategorie byla správa účtů. Dále pak jako samostatnou kategorii tvořila položka „denní přehled platebních transakcí“. Celkem byly kartičky rozděleny do pěti seskupení. Některým
uživatelům,
kteří
pracovali
s
touto
aplikací
poprvé,
respektive
s problematikou platebních transakcí, dělal problém zorientovat se v použitých názvech.
66
7.2.2.
Testování použitelnosti
Většina testovaných uživatelů neměla žádné závažné problémy při splnění testovacích úkolů. Výsledky jednotlivých úkolů: •
V prvním úkolu se měly zobrazit platební transakce za období minulého týdne, které přišly od Komerční banky. Průběhu plnění úkole se skoro u všech osob projevilo, že se systémem pracovali poprvé a mnohým trvalo přiměřenou dobu, než se správně zorientovali v základním menu, při práci s javascriptový kalendářem atd. Zajímavým poznatkem bylo, že několik testerů nevědělo, kde se právě v systému nacházejí. Očekávali, že hlavní název sekce bude umístěn na prvním místě nahoře. Tento nadpis se však nachází až pod hlavním menu, kde ho mnoho uživatelů ze začátku nehledalo. Ale posléze tento úkol všichni zdárně zvládli. Tento poznatek napovídá, že v budoucnu bude potřeba jemné úpravy vzhledu stránek. Řešením by bylo tento nadpis přemístit na první místo ve stránce, což by usnadnilo orientaci většině uživatelů.
Obrázek 20: Ukázka řešení problému se špatně umístěným nadpisem
67
•
U druhého úkolu bylo zadáno najít všechny odchozí platby z čísla účtu 11111111/0800 za minulý kalendářní měsíc. Dva testeři si spletli políčko číslo účtu a název účtu (viz. Obrázek 21), takže požadované číslo účtu omylem napsali do kolonky pro název účtu, což ale není chybou v systému. U ostatních pozornějších respondentů nebyl žádný problém s tímto úkolem. Toto by se mohlo částečně vyřešit zvýrazněním slova „název“ a „číslo“. Protože tito lidé hledali slovo účet a už se nezaměřili na to, že jsou zde dvě položky "název účtu" a "číslo účtu".
Obrázek 21: Ukázka záměny čísla a názvu účtu při testování
•
Ve třetí úloze se mělo vypsat všechny účty v systému, které jsou vedeny u Komerční banky. Tento úkol se podařil všem zvládnout relativně rychle a bez patrných obtíží. Zřejmě to bylo tím, že uživatelé byly v této fázi relativně dobře seznámeni s běžným ovládáním programu, takže jim tento úkol nečinil potíže.
•
Najít účty, které by mohly mít spojitost se společností „Firma Praha“ bylo zadáno u čtvrtého úkolů. Tato část testování se podobně jako u předchozího úkolu podařilo zvládnout všem bez obtíží.
68
•
V pátém úkolu bylo v zadání zobrazit určitý graf. Mnoho lidí na základě této informace hledalo v menu klíčové slovo graf. Bohužel toto klíčové slovo většina nenašla. Takže většině osobám se muselo poradit, kde se příslušná položka v menu nachází. Dalším problémem, který nastal, bylo to, že hledali slovním spojení měsíční přehled. Ale v programu je pouze položka denní přehled. Znamená, že se zobrazují jednotlivé dny, ne celé měsíce. Dalším problémem byla rychlost aplikace při zobrazování grafu. Když testeři zadali požadované údaje a dali příslušný graf zobrazit, tak museli chvíli čekat, než se požadovaný graf vykreslí. Během této doby však se nezobrazilo nic a někteří si mysleli, že udělali něco špatně. Zde by byl vhodný obrázek informací o průběhu načítaní požadovaného grafu. Z toho testu vyplývá, že v budoucnu bude vhodné zakomponovat slovo "graf/grafický" do základního menu.
Obrázek 22: Příklad řešení problému s načítáním grafu
69
•
U posledního úkolu se mělo najít minimálně jednu skupinu podezřelých příchozí transakci za předminulý kalendářní měsíc. Kromě jednoho dělalo všem problém pochopit co je to vlastně podezřelá transakce. Zde by pomohlo, kdyby uživatelé nejdříve přečetli definici podezřelých transakcí a potom se je snažili v příslušném výpisu najít. Po krátkém vysvětlení co vlastně mají hledat i tento úkol všichni dokončili. Užitečné by zde bylo přidat odkaz na definici podezřelých transakcí, případně krátký úvod, co tento systém v této problematice umožňuje a co naopak ne.
Celé testování proběhlo bez závažnějších problémů. Testování přineslo nové pohledy na celou koncepci aplikace. Projevily se drobné nedostatky, jako ne úplně dobře umístěný hlavní nadpis sekce nebo absence prvku, který ukazuje průběh načítání grafu. Na druhou stranu mnoho uživatelů ocenilo javascriptový kalendář, přehlednou grafickou úpravu zobrazovaných tabulek a podobné drobnosti.
70
71
8. Závěr 8.1. Dosažené výsledky Cílem předkládané diplomové práce byla realizace praktického nástroje pro analýzu clearingových platebních transakcí. Výsledkem je nástroj nazvaný CTStat , který je poměrně uživatelsky přívětivý a splňuje všechny požadavky citované v zadaní diplomové práce. Výsledky testování produktu mohou být považovány za uspokojivé. Navrhované řešení se v praktickém použití osvědčilo. Jsou používány známé a osvědčené technologie. Správa systému z administrátorského hlediska proto není ničím novým pro běžné bankovní správce systémů. Správa uživatelských přístupů jsou řešeny na bázi webového serveru IIS 6.0. Tento server implicitně podporuje NTML Autentifikaci, což je elementární báze administrace uživatelů ve Windows. Případné rozšíření systému se nestává velkým problémem. Používají se známé programovací technologie jako je PHP nebo XHTML.
8.2. Možnosti využití diplomové práce Systém CTStat je prostředek, který podstatně napomáhá při analýze platebních transakcí jednotlivých účtů. Rozbor platebních transakcí otevírá moderní příležitosti při přilákání nových klientů. Současně analyzuje platby stávajících klientů, kde může upozornit na problematiku tzv. „praní špinavých peněz“. Díky obecnosti aplikovaných technologiích lze lehce nasadit tento systém prakticky v jakékoliv finanční instituci, která využívá clearingového systému České národní banky.
8.3. Další možnosti rozšiřování systému Nástroj lze samozřejmě dále vylepšovat podle požadavků a zkušeností uživatelů, kteří s ním budou pracovat. Toto je standardní způsob vývoje softwarových produktů, kdy se daný artikl uvede do provozu a zpětnou vazbou mezi uživateli a softwarovou firmou vznikají další nové verze, které reflektují požadavky uživatelů a odstraňují případné chyby objevené při běžném používání. V této fázi vývoje aplikace zatím není řešena otázka automatického zpracování nových clearingových souborů.
72
73
9. Seznam citované literatury [1] Česká národní banka: Podmínky České národní banky, kterými se stanový náležitosti, formát a struktura položek v mezibankovním platebním styku v České republice, 2002 [2] Jim Arlow,Ila Neustadt:UML a unifikovaný proces vývoje aplikací, Computer Press, 2003, ISBN 80-7226-947-X [3] Netne Henrickson, Scott Hoffmann: IIS 6 Kompletní průvodce, Computer Press, 200 [4] Hugh E. Williams; David Lane: PHP a MySQL - Vytváříme webové databázové aplikace, Computer Press, 2002, ISBN 80-7226-760-4 [5] Request for Comments (webový portál věnovaný standardů), [online], 2006, Dostupný na www: http://www.ietf.org/rfc.html [6] Start McClure, Joel Scambray, Georgie Kurtz: Hacking bez tajemství, Computer Press, 2003, ISBN 80-7226-948-8 [7] Karel Richta, Jiří Sochor: Softwarové inženýrství I, Vydavatelství ČVUT, 1998, ISBN 80-01-01428-2 [8] MySQL
5.1
Reference
Manual,
[online],
2006,
Dostupný
na
www:
http://www.mysql.com/ [9] Martin James, Odell James J.: Object-Oriented Methods - A Foundation, Prentice Hall , 1995, ISBN 0-13-63856-2 [10] Česká národní banka: Číselník identifikačních kódů bank AP0001, 2006, Dostupný na www: http://www.cnb.cz/ [11] Prokop, M.: CSS pro webdesignéry. 1. vyd. Praha, Mobil Media, 2003, ISBN 8086593-35-5 [12] Kosek, J.: PHP – tvorba interaktivních internetových aplikací. 1. vyd. Praha, Grada Publishing, 1999, ISBN 80-7169-373-1
74
[13] Martin Štrimpfl: Active Server Pages : pro úplné začátečníky, Computer Press, 2000, ISBN 80-7226-347-1 [14] Bollinger, Gary: JSP - Java Server Pages: podrobný průvodce začínajícího tvůrce, Grada, 2003, ISBN 80-247-0340-8 [15] Metoda
Card-Sorting,
[online],
2000,
Dostupná
na
www:
http://www.infodesign.com.au/usabilityresources/design/cardsorting.asp [16] Žák, Miroslav: XML : začínáme programovat : podrobný průvodce začínajícího uživatele, Grada, 2003, ISBN 80-247-0565-6 [17] Ron Patton: Testování softwaru, Computer Press, 2002, ISBN: 80-722-6636-5 [18] Projekt
FastTemplates,
[online],
2002,
Dostupný
na
www:
http://www.thewebmasters.net [19] AXA DBS - Transakční bankovní informační systém, [online], 2006, Popis dostupný na www: http://www.axa-sw.cz/dps.php [20] BankStat a BankArch, [online], 2006, Popis dostupný na www: http://www.editel.cz [21] Projekt JpGraph, [online], 2006, Dostupný na www: http://www.aditus.nu/jpgraph/ [22] Webový server Apache, [online], 2006, Dostupný na www: http://www.apache.org [23] Databázový server Oracle, [online], 2006, Dostupný na www: http://www.oracle.com [24] Databázový
server
PostgreSQL,
[online],
2006,
Dostupný
na
www:
http://www.postgresql.org [25] Jakob Nielsen: Usability Engineering, Morgan Kaufmann,1994, ISBN 0-12-518406-9 [26] The World Wide Web Consortium (W3C),[online], 2006, Dostupný na www: http://www.w3.org/
Příloha A. Seznam použitých zkratek
A Seznam použitých zkratek ASCII American Standard Code for Information Interchange ASP Active Server Pages API Application Programming Interface CGI Common Gateway Interface CRLF Carriage Return Line Feed CSS Cascading Style Sheets CSV Comma Separated Values ČNB Česká národní banka HTML Hyper Text Markup Language HW Hardware IT Informační Technologie JS JavaScript JSP Java Server Pages MSIE Microsoft Internet Explorer MZC Mezibankovní zúčtovací centrum OOP Objektově orientované programování OS Operační systém PHP Professional Home Pages SQL Structured Query Language SW Software UML Unified Modeling Language URL Uniform Resource Locator W3C World Wide Web consortium XML Extensible Markup Language XHTML Extensible Hypertext Markup Language ZC Zúčtovací centrum (ekvivalent k clearingovému platebnímu systému)
75
76
Příloha A. Seznam použitých zkratek
Příloha B. Uživatelská příručka
77
B Uživatelská příručka 1. Hlavní strana Hlavní strana obsahuje úvodní informace o programu. Dále je na hlavní straně umístěno několik často používaných odkazů pro rychlejší navigaci v systému.
Obrázek 23: Ukázka hlavní strany
2. Statistika platebních transakcí Tato sekce tvoří hlavní část se statistikou odchozích a příchozích platebních transakcí. Statistiky jsou rozděleny do dvou samostatných stránek. Zobrazení všech statistik lze přehledně vytisknout pomocí ikony tiskárny, která je umístěna vpravo nahoře nebo vyexportovat do formátu Microsoft Office Excel.
Příloha B. Uživatelská příručka
78
Obrázek 24: Statistika clearingových platebních transakcí
2.1.
Filtr
Vzhledem k velkému objemu dat lze vyfiltrovat pouze ta data, která jsou pro uživatele zajímavá. Filtr obsahuje položky: • • • • • • • •
„datum od“ ve formátu „DD.MM.RRRR“ „datum do“ ve formátu „DD.MM.RRRR“ počet zobrazených položek na jednu stránku částky větší než částky menší než název účtu / klienta číslo účtu zobrazovat platby pouze vybrané banky
Příloha B. Uživatelská příručka
2.2.
79
Zobrazení dat
Každá tabulka s výpisem obsahuje následující sloupce: • • • • • • • •
datum ve formátu „DD.MM.RRRR“ částka číslo účtu debet název účtu debet ID banky debetního účtu číslo účtu kredit název účtu kredit ID banky kreditního účtu
2.3. • •
Export
tisk Microsoft Office Excel
Kliknutím na účet debet nebo na účet kredit se program přepne na stránku s detailem účtu, ve kterém se zobrazí detail daného účtu. Výpis se podle potřeby rozděluje do více stránek. Přepínání v těchto stránkách zajišťuje posuvník, který je umístěn dole pod výpisem dat.
3. Statistika účtů s největšími platebními transakcemi Slouží k prohlížení účtů, které realizovaly větší počet platebních transakcí přes tento systém. Statistiky jsou rozděleny do dvou samostatných stránek, zvlášť pro příchozí a odchozí platby.
Příloha B. Uživatelská příručka
80
Obrázek 25: Účty s největším platebními transakcemi
3.1.
Filtr
Vzhledem k velkému objemu dat lze zobrazit pouze ty data, které jsou pro uživatele zajímavá. Filtr obsahuje položky: • • • • • • • •
„datum od“ ve formátu „DD.MM.RRRR“ „datum do“ ve formátu „DD.MM.RRRR“ počet zobrazených položek na jednu stránku celková částka vetší než celková částka menší než název účtu / klienta číslo účtu zobrazovat platby pouze vybrané banky
3.2.
Výpis účtů
Výpis se zobrazuje v těchto sloupcích: • • • • • •
počet transakcí celková částka průměrná částka jedné transakce číslo účtu debet jméno účtu debet ID banky debetního účtu
Příloha B. Uživatelská příručka
81
V případě odchozích plateb se zobrazují stejné sloupce, jen místo účet debet je zde účet kredit. • • •
číslo účtu kredit jméno účtu kredit ID banky kreditního účtu
3.3. • •
Export
tisk Microsoft Office Excel
4. Výpis účtů Zobrazení všech účtů, které někdy realizovaly platbu přes clearingový systém a byly naimportovány do tohoto systému. Tento výpis je vhodný k rychlému nalezení určitého účtu v systému a následnému zobrazení jejich platebních transakcí.
Obrázek 26: Výpis účtů
Příloha B. Uživatelská příručka
82
4.1.
Filtr
K velkému objemu dat lze zobrazit pouze ta data, které jsou pro uživatele zajímavá. Filtr obsahuje položky: • • • •
počet zobrazených položek na jednu stránku název účtu / klienta číslo účtu název banky
4.2.
Výpis účtů
Výpis účtů se zobrazuje v těchto sloupcích: • • •
číslo účtu název účtu / klienta ID banky účtu
Při kliknutí na číslo účtu nebo na název klienta se výpis přepne do detailu daného účtu.
4.3. • •
servisní účet – daný učet se označí příznakem, že je servisní upravit – účet se přepne na editační stránku účtu
4.4. • •
Pomocné funkce ve výpisu účtů
Export
tisk Microsoft Office Excel
5. Detail účtu Slouží k detailnímu přehledu všech platebních transakcí, které byly spojeny se zobrazeným účtem. K tomuto výpisu se lze dostat kliknutím na vybraný účet ve „výpisu všech účtů“.
Příloha B. Uživatelská příručka
Obrázek 27: Zobrazení detailu účtu
Výpis je rozčleněn do dvou podkategorií: • •
příchozí platby na účet odchozí platby z účtu
5.1.
Filtr
Filtr obsahuje položky: • • • • • •
počet zobrazených položek na jednu stránku „datum od“ ve formátu „DD.MM.RRRR“ „datum do“ ve formátu „DD.MM.RRRR“ částky větší než částky menší než název banky
5.2.
Zobrazení souhrnných informací detailu účtu
Zobrazí se tyto základní údaje: • • • •
název vybraného účtu číslo vybraného účtu název banky, kde je veden tento účet alternativní název účtu (jiné názvy účtu)
83
Příloha B. Uživatelská příručka
84
5.3.
Zobrazení platebních transakcí
Výpis je vypsán v těchto sloupcích: • • • •
datum transakce částka účet debet – hypertextový odkaz na detail účtu debet účet kredit – hypertextový odkaz na detail účtu kredit
Po kliknutí na účet debet nebo účet kredit se výpis přepne do detailu vybraného účtu.
6. Editace účtů Sekce Editace účtů slouží k přímé úpravě informací o účtech.
Obrázek 28: Ukázka editace účtů
Příloha B. Uživatelská příručka
6.1.
85
Filtr
Filtr obsahuje položky: • • • •
počet zobrazených položek na jednu stránku název účtu / klienta číslo účtu název banky
6.2.
Zobrazení detailních informací o vybraném účtu
Zobrazí se tyto základní údaje: • • • • •
unikátní Id účtu název účtu / klienta číslo účtu ID banky, kde je veden tento účet servisní účet, příznak servisního účtu
6.3.
Výpis všech účtů
Každý výpis je vypsán v těchto sloupcích: • • • • • • •
C04_ID – id účtu C04_BC – kód banky C04_NUMBER – číslo účtu C04_NAME – název účtu C04_SERVICE – příznak servisního účtu sloupec s butonem SMAZAT sloupec s butonem EDITOVAT
7. Grafický denní přehled platebních transakcí Stránka s grafickým denním přehledem platebních transakcí. Je zobrazena jako sloupcový graf.
7.1.
Filtr
Filtr obsahuje položky: • • • • •
„datum od“ ve formátu „DD.MM.RRRR“ „datum do“ ve formátu „DD.MM.RRRR“ název účtu / klienta číslo účtu název banky
Příloha B. Uživatelská příručka
86
7.2.
Graf
Sloupcový graf je zobrazen jako se dvěma sloupci v každém dni. Jeden sloupec je znázorňuje příchozí transakce a druhý odchozí. Osa X znázorňuje dny, osa Y znázorňuje objem transakcí. Příchozí transakce jsou zobrazeny modrým sloupcem a odchozí transakce jsou červeným sloupcem
Obrázek 29: Ukázka grafu transakcí
8. Import clearingových souborů Slouží k importu clearingových souborů do systému. Systém rozeznává příchozí a odchozí clearingové soubory podle předpony souborů a přímá clearingové soubory pouze podle zadané přípony.
8.1.
Fáze 1
Slouží k prvotnímu nastavení importu, především o zadání předpony příchozích a odchozích clearingových souborů. Výchozí hodnota předpony příchozích clearingových
Příloha B. Uživatelská příručka
87
souborů je „tsi“ a odchozí je „tso“. Dále je zde políčko pro nastavení přípony souborů. Výchozí hodnota je „txt“.
Obrázek 30: Import - fáze 1
Následně je políčko pro zadání importovaného souboru. Stačí vybrat jeden soubor a v dalším kroku se zobrazí celý adresář, ve kterém se tento soubor nachází.
8.2.
Fáze 2
Zobrazí se výpis ve zvoleném adresáři, ve kterém jsou uloženy clearingové soubory. V levém sloupci jsou příchozí clearingy a v pravém odchozí. U každého souboru je políčko na zaškrtnutí importu. Příklad názvů clearingových souborů: • •
příchozí „TSI242.txt“ odchozí „TSO126.txt“
Příloha B. Uživatelská příručka
88
Obrázek 31: Import - fáze 2
Pro snadný import všech souborů slouží tlačítko „Označ vše“ pro opačnou operaci je tlačítko „Odznač vše“. Po vybrání souborů k importu se pokračuje kliknutím na „Importovat vybrané soubory“.
8.3.
Fáze 3
Ve třetím kroku importu se zobrazí tabulka s výpisem importovaných souborů s jejich údaji. V tabulce jsou tyto položky: • • • • •
název clearingového souboru datum vytvoření clearingového souboru velikost clearingového souboru počet importovaných záznamů z daného clearingového souboru počet nově importovaných účtů z daného clearingového souboru (v nově naimportovaných účtech jsou i duplicitní záznamy)
K dalšímu kroku importu se lze dostat kliknutím na tlačítko „Odstranit duplicitní účty“.
Příloha B. Uživatelská příručka
89
Obrázek 32: Import - fáze 3
8.4.
Fáze 4
Poslední fáze importu je odstranění duplicitních účtů v tabulce účtů. Zobrazí tyto údaje: • • •
původní počet účtů v tabulce počet účtů po odstranění duplicit počet odstraněných duplicitních účtů
Obrázek 33: Import - fáze importu
Příloha B. Uživatelská příručka
90
9. Import účtů Import účtů realizuje import externích účtů ve formátu CSV („Comma-separated values“, hodnoty oddělené čárkami). Jednotlivé položky v souboru mají následující formát aaa;xxx;ccc, kde aaa je název účtu klienta, xxx je číslo účtu klienta a ccc je Id banky.
Obrázek 34: Ukázka importu účtů
Na závěr se zobrazí počet vložených účtů.
10. Nastavení programu Tato sekce slouží ke globálnímu nastavení programu.
Příloha B. Uživatelská příručka
91
11. Tabulka s kódy bank Tato tabulka slouží k snadnému přidávání, editaci či mazaní jednotlivých položek, zejména kódů bank nebo jejich názvů.
Obrázek 35: Úkazka editaci s kódy bank
Příloha B. Uživatelská příručka
92
12. Nápověda Tato část systému tvoří základní uživatelskou příručku pro práci s aplikací CTStat.
Obrázek 36: Ukázka stránky s nápovědou
Příloha C. Instalační příručka
93
Příloha C Instalační příručka Instalace je možná pouze na systémech a Windows XP a Windows 2003 Server. Pro instalaci jsou nezbytná administrátorská práva. Celá instalace je rozdělena do několika následujících fází. •
Nejdříve je nutné nainstalovat webový server IIS 6.0, pokud ještě není nainstalovaný. Instalace webového serveru je popsána v [3].
•
Další požadovanou součástí je databázový server MySQL 5.0. Instalační soubor lze stáhnout, z oficiálních stránek výrobce nebo na přiloženém CD spustit soubor „\install\mysql\Setup.exe“. Celá instalace bude provedena ve výchozím nastavení. Databázový server MySQL je možné nainstalovat na stejný fyzický server jako se nainstaloval webový (IIS). Vzhledem k rozložení zátěže se doporučuje nainstalovat databázový server na dedikovaný fyzický server.
•
Po instalaci databázového serveru je nutné importovat vlastní databázi systému. K tomuto účelu lze využit připravený skript, který se nachází na přiloženém CD „install\create_tables.sql“. Tento soubor obsahuje SQL příkazy, které provedou požadovaný import dat. Obecný popis importu SQL příkazů je popsán v [4].
•
Další krok je nainstalovat podporu PHP 5.1.0. Instalační soubor lze stáhnout, z oficiálních stránek výrobce nebo na přiloženém CD spustit aplikaci „\install\php\php-5.1.4-installer.exe“. Instalaci lze také provést ve výchozím nastavení. Pouze je nutné v průběhu instalace zvolit správnou verzi webového serveru IIS, která byla na tento server nainstalována viz. Obrázek 37. Po dokončení instalace se ještě musí překopírovat tzv. „extensions“, česky řečeno „rozšíření“ do adresáře „C:\PHP\ext“. Tyto extensions jsou pouze rozšiřující moduly v podobě DLL knihoven. Tyto knihovny jsou k dispozici na oficiálních stránkách
výrobce
nebo
na
„\install\php\php-5.1.4-Win32.zip“.
přiloženém
CD
v archivním
souboru
Příloha C. Instalační příručka
94
Obrázek 37: Ukázka výběru webového serveru při instalaci PHP
•
Po dokončení je nutné upravit následující hodnoty v PHP konfiguračním souboru „php.ini“, který je ve výchozím stavu umístěný v „C:\Windows\php.ini“. Na obrázku (viz. Obrázek 38) jsou zobrazené konfigurační proměnné, které je potřeba změnit na uvedené hodnoty. Ostatní hodnoty lze nechat v původním nastavení. Vzorový konfigurační soubor je k dispozici k použití na „\install\php.ini“.
expose_php = Off max_execution_time = 300 max_input_time = 400 memory_limit = 128M display_errors = Off extension_dir = "C:\PHP\ext" enable_dl = On cgi.force_redirect = 0 upload_max_filesize = 10M extension=php_gd2.dll extension=php_mysql.dll Obrázek 38: Změna konfiguračních proměných v souboru php.ini
•
Pro spojení PHP a MySQL je nutné upravit nastavení na spojení PHP s databázi. Nastavení
komunikace
s databází
se
nachází
v souboru
„\src\www\config\config.ini”. Kde se nastaví příslušné hodnoty konfiguračních proměnných. Obsah tohoto konfiguračního souboru je následující.
Příloha C. Instalační příručka
95
[db] driver=Mysql host=localhost port=3306 database=clearing user=uzivatel password=heslo Obrázek 39: Obsah souboru config.ini
•
Překopírovat adresář „\src\“, kde jsou zdrojové soubory, do domovské složky webového serveru. Nejčastěji to bývá pro IIS „C:\Inetpub\wwwroot\“. Je vhodné si tento zdrojový adresář pojmenovat například na složku „clearing“. Nyní tedy bude celá cesta vypadat následovně „C:\Inetpub\wwwroot\clearing\“.
•
Dalším krokem je nastavení zabezpečení systému. Pro vybrané uživatele se nastaví práva na celý webový adresář. Doporučuje se vytvořit dvě lokální uživatelské skupiny pro administrátory a zvlášť pro uživatele. Potom se snadněji tyto práva nastavují a modifikují. Pro snazší nastavení těchto práv, lze použít instalační skript „\install\set_rights.bat“, který tyto práva patřičně nastaví. Ve skriptu
je
nutné
specifikovat
cestu
k webovému
adresáři
(například
C:\Inetpub\wwwroot\clearing\“) a jména příslušných skupin . Na IIS serveru je nutné přepnout autentifikaci na NTML (ukázka z nastavení IIS viz.Obrázek 9). Další informace o zabezpečení IIS serveru viz. [3].
96
Příloha D. Ukázka clearingového souboru
Příloha D. Ukázka clearingového souboru HD:26 20060906 0000300 8000004 0006200 KC:100000000000 20060906 CZK ID:20060906 8000004 UD:8010 1866998523 UK: 93002290 EC:968 ZK:906619 HD:21 20060906 0000800 5000088 0006200 KC:2195000000 20060906 CZK ID:20060906 FSYHO14037657 UD:994404 401001100 Společnost PRAHA 1 UK: 93002290 EC:558 ZK:600101356 AV:BY ORDER GIBAATWW HD:21 20060906 0008070 0000061 0006200 KC:2000000000 20060906 CZK ID:20060906 68409961 UD: 2976019001 UK:000000 0093002290 EC:0558 ZK:0200001926 HD:21 20060906 0003500 0000003 0006200 KC:8462100000 20060906 CZK ID:20060906 06090619330 UD:0 9000001995 Společnost BRNO 3 UK:0 94040053 Společnost PRAHA 2 EC:0000 ZK:0 ZP:06090619330 AV: GTOS06248004843 STAR PAYMENT HD:21 20060906 0003500 0000114 0006200 KC:50000000000 20060906 CZK ID:20060906 112000114 UD:0 9000001995 Společnost Ostrava 1 UK:0 93002290 EC:0000 ZK:0 ZP:112000114 HD:51 20060906 0000730 0000000 0006200 IN:5000051 5000055 S0:0000000 00000000000000000 S1:0000000 00000000000000000 S2:0000005 00000162657100000 S3:0000000 00000000000000000 S4:0000000 00000000000000000 S5:0000000 00000000000000000 S6:0000000 00000000000000000 S7:0000000 00000000000000000 S8:0000000 00000000000000000
5000051 0000300
5000052 0000000
5000053 0000000
5000054 0000000
5000055 0000000
0000000 0000000
Příloha E. Obsah přiloženého CD
97
Příloha E. Obsah přiloženého CD Obsah přiloženého CD je následující: index.html – výchozí stránka projektu, obsahuje základní informace o této práci a navigační menu readme.txt – popisu obsahu CD v textovém formátu install.txt – instalační příručka v textové podobě manual.html – uživatelská příručka v HTML formátu text/ – adresář obsahující vlastní text DP diplom.doc – text diplomové práce ve formátu Microsoft Word 2003 diplom.pdf – text diplomové práce ve formátu PDF data/ – adresář obsahující vzorové clearingové soubory src/ – adresář se zdrojovými soubory install/ – adresář s instalačními soubory podpůrných programů mysql/ – adresář s instalací MySQL databáze php/ – adresář s instalací PHP create_tables.sql – soubor s SQL příkazy pro vytvoření databáze php.ini – vzorový konfigurační soubor pro PHP set_rights.bat – instalační dávka pro nastavení oprávnění webových souborů
