ZPRACOVÁNÍ PAPÍROVÝCH PLATEBNÍCH PŘÍKAZŮ ELEKTRONICKOU FORMOU

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

ZPRACOVÁNÍ PAPÍROVÝCH PLATEBNÍCH PŘÍKAZŮ ELEKTRONICKOU FORMOU Bakalářská práce

Autor:

Martin Matějka BIVŠ ITK Informační technologie

Vedoucí práce:

Praha

Ing. Marcela Soldánová

Duben, 2011

Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze dne:

Martin Matějka

Poděkování: Na tomto místě bych rád poděkoval všem, kteří mi při zpracování této práce poskytli pomoc a potřebné informace. Především děkuji Ing. Marcele Soldánové za odbornou pomoc a poskytnutí cenných rad při zpracování práce. Dále bych rád poděkoval své rodině a především manţelce za podporu a trpělivost po celou dobu mého studia.

Anotace Tato práce popisuje tvorbu systému na zpracování papírových platebních příkazů elektronickou formou v modelových podmínkách reálné banky. V úvodu popisuje základy platebního styku v České republice, které slouţí jako teoretický základ a právní norma pro provádění mezibankovního platebního styku, kam spadá i zpracování platebních příkazů. V dalších částech pak popisuje samotné řešení problému elektronického zpracování papírových příkazů, a to od úvodní analýzy po návrh technologického řešení a testování navrţeného řešení.

Klíčová slova Příkaz k úhradě, příkaz k inkasu, skener, preprocessing

Title Processing of Paper Payment Orders Electronically

Abstract This document deals with the construction of system made for processing paper payment orders eletronically in model conditions of a real bank. The introduction describes the basics of payment systems in the Czech Republic, which serve as a theoretical ground and legal framework for the manner of execution of payments between banks, where the processing of payment orders is included. The next parts describe the solution of the problem of processing payment orders electronically. It starts with the first analysis and continues up to the design of technological solution and the designed solution testing.

Keywords Paymento order, collection order, scanner, pre-processing

Obsah Úvod ........................................................................................................................................... 7 1

2

Základy platebního styku .................................................................................................... 9 1.1

Hotovostní platební styk .............................................................................................. 9

1.2

Bezhotovostní platební styk....................................................................................... 12

1.2.1

Příkaz k inkasu ................................................................................................... 13

1.2.2

Příkaz k úhradě ................................................................................................... 14

Návrh řešení elektronického zpracování příkazů .............................................................. 16 2.1

Potřeby banky ............................................................................................................ 16

2.2

Výchozí situace.......................................................................................................... 17

2.3

Rozhodnutí o změně .................................................................................................. 18

2.4

Varianty vývoje systému ........................................................................................... 18

2.4.1

Vývoj vlastním IT oddělením ............................................................................ 18

2.4.2

Outsourcing ........................................................................................................ 18

2.4.3

Kompromis ......................................................................................................... 19

2.5

Věcný popis řešení..................................................................................................... 19

2.6

Fáze skenování .......................................................................................................... 20

2.6.1

Fáze zpracování .................................................................................................. 20

2.6.2

Navazující zpracování ........................................................................................ 21

2.7

2.7.1

Skenery ............................................................................................................... 24

2.7.2

Validační a verifikační stanice ........................................................................... 25

2.7.3

Aplikační servery ............................................................................................... 26

2.7.4

Databázový server .............................................................................................. 27

2.7.5

Síťová komunikace, EDI .................................................................................... 30

2.8

3

Technický popis řešení .............................................................................................. 23

Funkční popis řešení .................................................................................................. 31

2.8.1

Digitalizace papírových platebních příkazů ....................................................... 31

2.8.2

Získání dat .......................................................................................................... 31

2.8.3

Kontroly vytěţených dat .................................................................................... 32

2.8.4

Předání dat ke zpracování .................................................................................. 32

2.8.5

Předání informace o zpracování klientovi .......................................................... 32

Realizace navrhovaného řešení ......................................................................................... 34

5

3.1

Aplikace Focus .......................................................................................................... 34

3.1.1

Skenování ........................................................................................................... 34

3.1.2

OCR – Optické rozpoznávání znaků .................................................................. 35

3.1.3

Pouţité technologie OCR ................................................................................... 36

3.1.4

Korekce vytěţených dat ..................................................................................... 38

3.1.5

Verifikace vytěţených dat .................................................................................. 40

3.1.6

Verifikační parametry ........................................................................................ 41

3.1.7

Preprocessing ..................................................................................................... 42

3.1.8

Duplicity ............................................................................................................. 43

3.1.9

Archivace ........................................................................................................... 44

3.1.10 Distribuce dat ..................................................................................................... 48 3.1.11 Distribuce dat v rámci aplikace .......................................................................... 48 3.1.12 Distribuce dat v rámci banky ............................................................................. 48 3.1.13 Popis rozhraní ..................................................................................................... 49 3.1.14 Kontroly ............................................................................................................. 50 4

Závěr ................................................................................................................................. 51

5

Pouţitá literatura ............................................................................................................... 53

Seznam příloh ........................................................................................................................... 54 Příloha 1 ..................................................................................................................................... 1 Příloha 2 ..................................................................................................................................... 2 Příloha 3 ..................................................................................................................................... 5 Příloha 4 ..................................................................................................................................... 7 Příloha 5 ..................................................................................................................................... 8

6

Úvod Cílem práce je návrh procesu zpracování papírových platebních příkazů elektronicky pomocí jejich naskenování, rozpoznání naskenovaných příkazů, vytěţení dat a jejich následného odeslání do navazujících bankovních systémů. Svoji práci jsem zaměřil zejména na proces uvádění navrţeného systému do reálného provozu, coţ obnáší hlavně testování navrţených systémů, jejich ladění a integrace do stávajících bankovních systémů. Pro účely této práce je nejprve popsána situace obecně. Jako podklad jsem zpracoval reálnou situaci jedné z bank, která působí na bankovním trhu v České republice a Slovenské republice, řešení na Slovensku se ovšem budu věnovat jen velmi okrajově, a to proto, aby bylo moţné si snadno představit skutečnou situaci. Modelovaná aplikace se jmenuje Focus. V této bance v současné době (březen 2011) dochází k nasazování aplikace do rutinního provozu a plné nahrazení stávajícího způsobu zpracování je plánováno do konce roku 2011. Zpracování papírových platebních příkazů elektronickou cestou má několik výhod. Zrychlí zpracování, sníţí jeho náklady. Vyuţití elektronického archivu usnadní vyhledávání transakcí při případných reklamacích. Strojovým vytěţováním údajů z platebních příkazů také dojde ke sníţení chybovosti oproti ručnímu přepisování. Zavádění nového systému do provozu a jeho integrace mezi stávající bankovní systémy nikdy není jednoduché a v mnou uváděném modelovém případě došlo ke komplikacím, které musely být řešeny, například i doprogramováním původně neplánované funkcionality proto, aby nově nasazovaný systém plnil očekávání, která do něj byla od počátku vkládána. Samozřejmě u projektu takového rozsahu, jaký je popisován v této práci, je jisté, ţe ke komplikacím dojde. Díky vysoce profesionálnímu týmu, který na projektu pracuje, se daří všechny komplikace zvládat a aplikaci se podařilo bez většího prodlení dovést aţ k pilotnímu provozu. Zavedení nových technologií a systémů bývá obvykle vnímáno zaměstnanci banky nepříliš pozitivně. Ani v tomto případě se zaměstnanci linky zpracování nestavěli kladně k inovacím,

7

které přináší tento projekt, ale jiţ během fáze testování a později pak pilotního provozu zjistili, ţe nasazené aplikace a pouţité technologie usnadní jejich dosavadní práci. Pouţité technologie mohou při jejich popisu vypadat sloţitě, ale uţivatelské prostředí pro pracovníky, kteří s nimi budou v rutinním provozu denně pracovat, bude přirozené a vlastně si ani neuvědomí, jak komplikovaná technika a sofistikovaná řešení se za novým systémem skrývají. Pro lepší orientaci je v příloze 1 uveden seznam zkratek, které v práci pouţívám.

8

1 Základy platebního styku Základy platebního styku se dají vysledovat hluboko do historie. Pro potřeby mé práce stačí zmínit vývoj platebního styku v naší republice od 90. let minulého století. Od té doby prošel platební styk v České republice bouřlivým vývojem, který ještě stále probíhá, i kdyţ v současné době probíhá jiţ volnějším tempem. Na počátku tohoto období měla dohled nad bankovním trhem, a tedy i platebním stykem v naší republice Státní banka československá, po rozpadu republik byla zaloţena Česká národní banka (ČNB). Česká národní banka je zřízena Ústavou České republiky a její činnost je specifikována v zákoně č. 6/1993 Sb., o České národní bance a dalšími právními předpisy. Samotný platební styk je specifikován v zákoně č. 284/2009 Sb., o platebním styku a také jej upravuje vyhláška č. 62/2004 Sb., kterou se stanoví způsob provádění platebního styku mezi bankami.

1.1 Hotovostní platební styk Hotovostí rozumíme fyzické peníze, respektive fyzické oběţivo, tedy bankovky, mince a státovky. Bankovky a mince - jsou platebními prostředky emitovanými centrální bankou. Státovky – jsou papírové kreditní platidlo emitované státem; původně cenný papír na určitou peněţní částku, vydávaný státem, neúročitelný, znějící na majitele a který byl u pokladen státu přijímán na zaplacení státních pohledávek, např. daní. Vydávání bankovek v České republice upravuje v současné době zákon č. 6/1993 Sb., o České národní bance, vydávání státovek po zrušení zákona č. 41/1953 Sb., o peněţní reformě v roce 1992 uţ není moţné.3 Hotovostní platební styk je v současné době na ústupu. A to nejen v ČR, ale celosvětově. Pro hotovostní platební styk je nezbytná existence fyzických peněz. Charakteristickým a

3

ČNB [online].

2003

[cit.

2011-04-11].

Často

.

9

kladené

dotazy.

Dostupné

z

WWW:

jedinečným znakem hotovostního platebního styku je tedy fyzický přesun hotových peněz z místa na místo.4 Hotovostní platební styk je na ústupu z důvodu jeho ekonomické nevýhodnosti a také vyšší rizikovosti jak pro banky, tak pro obchodní organizace. Tento druh platebního styku je preferován při výše zmíněných transakcích s menšími částkami nebo při nedůvěře v solventnost obchodního partnera. V tabulce č.1 jsou uvedeni učástníci hotovostního platebního styku se zaměřením na oběh hotovosti. V nedávné době byl patrný velký tlak bank na maximální omezení hotovostních transakcí. Došlo k významnému zdraţení transakcí na přepáţkách oproti transakcím pomocí elektronického bankovnictví a zároveň banky začaly sniţovat počty svých poboček. Paradoxně, v současné době je sice dále elektronické bankovnictví levnější neţ stejné operace na přepáţkách, ale banky začínají počet svých poboček postupně zvyšovat. Současný trend je mít více malých přepáţek s malým počtem pracovníků, a to i v menších městech.

4

Schlossberger, O., Soldánová, M.: Platební styk 6. kapitola. BIVŠ. Praha 2007.

10

Tabulka 1: Přehled účastníků hotovostního oběhu Účastníci

Činnost Vybírají si bankovky z účtů, např. z bankomatů nebo na

Zákazníci -fyzické

i

právnické

osoby, přepáţkách bank. Ukládají si hotovost na účty u bank.

nadace Obchodníci

Přijímají za své zboţí a sluţby hotovost od zákazníků.

- podnikatelé a právnické osoby

Část takto získané hotovosti ukládají v bankách.

Komerční banky

Přijímají hotové peníze od občanů, fyzických i

- banky působící na území ČR právnických osob. v souladu se zákonem o bankách

Takto získanou hotovost spolu s hotovostí získanou od centrální banky pouţijí k uspokojení potřeb klientů v oblasti hotovostního platebního styku. Přebytečná část hotovosti je odváděna do centrální banky.

Centrální banka

Hotovost přijatá z oběhu je tříděna na peníze schopné se opět vrátit do oběhu a peníze poškozené, které uţ se do oběhu vrátit nemohou. Peníze neschopné návratu do oběhu se bezpečně zničí. V souladu se zákonem zavádí banka do oběhu bankovky a mince nové.

Zdroj: Vítkovský K.: Platební styk, část 3. BIVŠ. Praha 2000, vlastní úpravy

Pro účel hotovostních plateb se na území České republiky pouţívá zákonné platidlo - česká koruna. Jediný subjekt, který má ze zákona v ČR právo emitovat peníze, tedy bankovky i mince, je Česká národní banka. Emisní činnost je jednou z hlavních náplní České národní banky. Tím, kolik uvolní peněţních prostředků nebo také vydá do oběhu bankovek, ovlivňuje likviditu finančního trhu. Platné bankovky a mince vydané Českou národní bankou jsou zákonnými penězi ve své nominální hodnotě při všech platbách na území České republiky5.

5

Schlossberger, O., Soldánová, M.: Platební styk 6. kapitola. BIVŠ. Praha 2007.

11

Samostatnou kapitolou jsou hotovostní platby v zahraničí nebo platby v cizích měnách. Zde je moţné definovat několik problémových oblastí, zejména při směnách různých národních měn, nebo omezené moţnosti směny různých „exotických“ měn.

1.2 Bezhotovostní platební styk Provádění platebního styku mezi bankami a zúčtování na bankovních účtech je stanoveno zákonem o platebním styku č. 284/2009 Sb. a vyhláškou České národní banky 62/2004 Sb. Bezhotovostní platební styk můţe být prováděn uvnitř banky, v tom případně se jedná o vnitrobankovní platební styk, nebo mezi dvěma bankami, v tom případě jde o mezibankovní platební styk. Vnitrobankovní platební styk má pro klienta i pro banku výhody. Většina bank provádí převody finančních částek mezi svými klienty bezplatně nebo za niţší poplatek. Také bývají převody peněz v rámci jedné banky mnohem rychlejší. V naprosté většině případů jsou provedeny v rámci jednoho dne, ale například ČSOB zaručuje svým klientům převod mezi účty svých klientů do sedmi minut od podání platebního příkazu. Mezibankovní platební styk je v České republice prováděn prostřednictvím clearingového centra České národní banky. Sem posílají všechny banky působící na finančním trhu České republiky informaci o provedených transakcích, které byly z jejich banky směrem k jiné bance podány. Zde jsou tyto transakce zpracovány a kaţdá z bank obdrţí informaci o pohybech, které musí být na jejích účtech provedeny. Do roku 2009 měly banky na zpracování transakcí mezibankovního platebního styku tři dny od podání příkazu k transakci od svého klienta. Zákonnou úpravou6 bylo stanoveno, ţe banka zajistí, aby peněţní prostředky byly připsány na účet příjemce nejpozději do konce následujícího pracovního dne pro okamţiku přijetí platebního příkazu. U bezhotovostního platebního styku je nutným předpokladem, ţe obě strany transakce mají zaloţený běţný účet. Bez běţného účtu nemohou být prováděny ţádné bezhotovostní transakce. Základními instrumenty pro provádění bezhotovostního platebního styku jsou příkaz k inkasu a příkaz k úhradě. K nim se váţí pojmy „Plátce“, „Příjemce“ a „Převod“

6

§ 109 zákona č. 284/2009 Sb., o platebním styku.

12

Plátcem se rozumí klient banky, tedy fyzická nebo právnická osoba, která dává bance příkaz k převodu. Příjemcem se rozumí fyzická nebo právnická osoba, na jejíţ účet jsou finanční prostředky na konci transakce připsány. Převod je operace, která je bankou provedena na základě příkazu podaného plátcem své bance (převádějící instituci). Výsledkem musí být převedení finančních prostředků na účet příjemce. Plátcem i příjemcem můţe být tatáţ osoba.

1.2.1 Příkaz k inkasu Příkaz k inkasu je podáván na základě podnětu od příjemce platby. Jedná se tedy o příkaz podaný příjemcem platby, k zajištění transakce, jejímţ výsledkem bude připsání finančních prostředků na jeho účet. Samozřejmě není moţné, aby si kdokoli zadal příkaz k inkasu z jakéhokoli účtu. Součástí smlouvy o vedení účtu mezi klientem banky a bankou je i ujednání o tom, ţe banka chrání klientovy prostředky na jeho účtech u ní vedených. Proto provedení inkasní platby je moţné jen na základě ujednání mezi klientem a bankou. Klient podá bance písemnou instrukci, ve prospěch kterého čísla účtu a do jaké maximální výše je moţné inkasní transakci provést. Jako příklad nejrozšířenější inkasní transakce je SIPO – sdruţené inkaso plateb obyvatelstva. Touto formou jsou prováděny pravidelné platby například za elektrickou energii, plyn nebo poplatky za rozhlas a televizi. Velmi častá je také dohoda o inkasních platbách s mobilními operátory o strhávání poplatků za jimi poskytované sluţby. Pro svoji ochranu si můţe klient při podání svolení k inkasu stanovit i maximální limit, na který můţe být příkazcem (zároveň tedy i příjemcem platby) příkaz podán. Pokud tuto částku příkaz k inkasu překročí, banka plátce tuto transakci neprovede. Podle § 3 odst. 2 vyhlášky7 musí příkaz k inkasu obsahovat vţdy:

7



označení, ţe se jedná o příkaz k inkasu,



bankovní spojení příkazce (příjemce),



bankovní spojení plátce,

Vyhláška ČNB 62/2004 Sb.

13



částku v české měně,



podpis.

Příkaz, který tyto výše uvedené údaje neobsahuje, můţe být bankou odmítnut a vrácen klientovi, aniţ by byl zpracován. Dále mohou být na příkazu uvedeny údaje: 

datum splatnosti,



variabilní symbol,



specifický symbol,



textovou zprávu (AV pole),



datum vystavení příkazu k úhradě.

Inkasní forma platebního příkazu je pro banku rizikovější neţ provedení příkazu k úhradě, a to hlavně proto, ţe je banka při zprocesování zpracování příkazu k inkasu povinna provést více operací, neţ u příkazu k úhradě8.

1.2.2 Příkaz k úhradě Příkaz k úhradě je podáván z podnětu příkazce. Na základě tohoto příkazu dojde k odepsání finančních prostředků z jeho účtu, ty jsou následně převedeny na účet příjemce. Příkaz k úhradě je nejběţnější formou bezhotovostní platby. Touto formou je moţné provádět úhrady za zboţí, sluţby, případně daně apod. Vyhláška ČNB 62/2004 Sb. stanoví, jaké poloţky musí příkaz k úhradě obsahovat. Jsou stejné jako u příkazu k inkasu, jeţ jsem uvedl výše, nyní je vysvětlím podrobněji. Bankovní spojení plátce a příjemce – jedná se o přesnou identifikaci účtů zúčastněných stran. Číslo účtu se povinně skládá ze samotného čísla účtu a kódu banky. Některá čísla účtu mohou ještě obsahovat předčíslí. Číslo účtu a kód banky musí být od sebe vţdy jasně odděleny.

8

Schlossberger, O., Soldánová, M.: Platební styk 3. kapitola. BIVŠ. Praha 2007.

14

Částka – klient musí jasně uvést částku, na jakou příkaz zní. Částka se uvádí numericky, slovní vyjádření není vyţadováno. Měna – měnu sice uvádím jako povinný atribut platebního příkazu, ale v praxi není toto pole bankou striktně vyţadováno. Pokud je klientem předán příkaz bez uvedené měny, je povaţován za příkaz v české měně. Jinak je moţné podávat platební příkazy i v jiných měnách. Podpis – podpis na platebním příkazu slouţí ke kontrole, zda je příkazce oprávněn disponovat s finančními prostředky na účtu. Podpis je kontrolován proti podpisovému vzoru, který klient vyplní při zakládání účtu, případně při změně dispozičních práv. Datum splatnosti – datum, kdy má být platba provedena. Pokud je datum splatnosti na příkaze uvedeno, musí jej banka dodrţet. Pokud uvedeno není, musí být platba provedena nejpozději následující pracovní den po podání platebního příkazu. Způsob nakládání s datem splatnosti (například jak dlouho před splatností minimálně a maximálně můţe klient příkaz bance podat) bývá specifikován v obchodních podmínkách banky. Variabilní symbol – slouţí k identifikaci platby pro příjemce / plátce. Specifický symbol – doplňková identifikace platby. Konstantní symbol – slouţí k identifikaci charakteru platby. Je povinný pouze u plateb týkajících se příjmů a výdajů státního rozpočtu, například daně. Textová zpráva (tzv. AV pole) – jedná se o pole umoţňující zadat 4x35 znaků, které umoţňuje dodat k platbě další doplňkovou informaci. Datum vystavení – bývá doplněno i místem vystavení, ale v současné době se od uvedení místa upouští. Datum vystavení musí být niţší nebo rovno datu splatnosti. Pokud je datum vystavení vyšší neţ datum splatnosti, je banka oprávněna takto vyplněný platební příkaz odmítnout zpracovat. Pracovník banky, který přijímá nebo zpracovává platební příkazy, nesmí do náleţitostí příkazu k úhradě nebo inkasu zasahovat, to znamená, ţe nesmí jakkoli měnit informace klientem na příkaze uvedené. Tím se eliminuje riziko nejasností pří případné pozdější reklamaci.

15

2 Návrh řešení elektronického zpracování příkazů Svět kolem nás se neustále dynamicky mění a přináší neustále nové moţnosti a technologie, které lze vyuţívat v kaţdodenním ţivotě. Tyto změny se samozřejmě musí dotýkat i takové instituce, jako je banka. Proto, aby banka nejen udrţela, ale případně i zlepšovala své postavení na bankovním trhu, musí tyto změny nejen sledovat, musí také zvaţovat, zda není vhodné nebo dokonce nutné na tyto změny reagovat a nové technologie vyuţívat, tak aby pro své klienty zajišťovala vysoký standard sluţeb a pro ostatní občany se stala natolik atraktivní, ţe budou zvaţovat vyuţití jejích sluţeb. Dostupné technologie, a to jak v oblasti hardware i software však nelze nasazovat bezhlavě. Je třeba zachovávat kontinuitu sluţeb, ale také kompatibilitu systémů. V případě nasazování různých nesourodých systémů vznikají velké nároky na jejich udrţování, coţ je ve výsledku velmi nákladné a pro banku rozhodně neţádoucí.

2.1 Potřeby banky Potřeby banky z hlediska IT je nutné vnímat ze dvou základních pohledů. Prvním je pohled obchodní a druhým je pohled technologický. Obchodní pohled Provozní – zajištění standardní činnosti, podpora kaţdodenních operací a opravy chyb, které se v rutinním provozu vyskytly. Rozhodovací – poskytování informací manaţerským systémům, které slouţí k řízení společnosti, dlouhodobému plánování i sledování dosaţených výsledků. Informační – shromaţďování informací z více různých systémů pro potřeby fungování banky, coţ je například nabídka produktů, popis firemních standardů nebo organizační struktura. Technologický pohled Do technologického pohledu jsou zahrnuty bankovní systémy momentálně provozované ve společnosti, jde například o systémy podpory klientských operací nebo transakční systémy.

16

Mezi transakční systémy patří: OLTP

aplikace

(Online

Transaction

Processing)

-

tyto

aplikace

slouţí

k automatickému sběru dat a jejich navazující kontrole. Databáze – data vygenerovaná z OLTP aplikací jsou ukládána do databází. V současnosti existuje mnoho různých databázových systémů. Některé slouţí pouze jako čisté úloţiště dat, jiné jsou vybaveny vyšší logikou a jsou schopné uloţená data zpracovat a analyzovat. Datové sklady (v modelové společnosti Centrální datový sklad, CDS) - data jsou zde ukládána s určitou logikou tak, aby poskytovala vyšší uţitnou hodnotu a také jejich zpracování bylo rychlejší a poskytlo uţivatelům vyšší komfort neţ data uloţená výhradně v databázích. Bankovní systémy provozované ve společnosti generují data, která jsou později ukládána do výše uvedených databází nebo datových skladů. S těmito systémy pracují koncoví uţivatelé. Do těchto systémů spadá i aplikace, která je tématem této práce. Na zpracování papírových platebních příkazů se nutně musí podílet koncoví uţivatelé, bez zásahu lidské ruky to není moţné, na druhou stranu současné technologie umoţňují tento proces usnadnit a částečně automatizovat.

2.2 Výchozí situace Platební příkazy byly dlouhodobě v bance zpracovávány čistě manuální metodou, kdy operátoři z oddělení zpracování přepisovali (přetypovávali) údaje z příkazů ručně do aplikace, ze které byly po kontrole odesílány k dalšímu zpracování. Tato činnost byla velmi náročná a náchylná k chybám. Vzhledem k vysokému počtu příkazů, které operátor kaţdý den musel zpracovat, průměrně bylo na pracovišti zpracováno 10.000 příkazů denně, je velmi pravděpodobné, ţe k chybám muselo docházet. Způsob kontrol také nemohl být úplně optimální. Kontrolor porovnával hodnoty uvedené na platebních příkazech s hodnotou na obrazovce, coţ neumoţňovalo ţádnou automatizaci. Tak zvaná metoda čtyř očí sice pravděpodobnost zachycení chyby zvyšuje, ale metodám, které umoţňují dnešní technologie, se vyrovnat nemůţe. 17

2.3 Rozhodnutí o změně Existence kaţdé organizace je podmíněno její schopností generovat zisk, proto banky, stejně jako kaţdá jiná organizace, se snaţí optimalizovat procesy. Z tohoto důvodu i banky sledují produktivitu svých oddělení a zvaţují investice, které mohou přinést sníţení rizika zanesení chyby, sníţení nákladů a urychlení práce tak, aby investice měla smysl a v rozumném čase byla návratná. Oddělení, kde není téměř ţádná automatizace a vstup dat a jejich kontrola probíhá čistě manuálně, k investici přímo vybízí. Proto bylo rozhodnuto, ţe oddělení zpracování platebních příkazů bude modernizováno. Investice půjde do hardware i software, aby vzniklo celkové řešení, jehoţ nasazením vznikne moderní pracoviště, které přinese klientům větší jistotu bezchybného zpracování, pracovníkům tohoto oddělení pak vyšší komfort.

2.4 Varianty vývoje systému Vývoj řešení pro zpracování papírových platebních příkazů elektronicky se ve své podstatě neliší od jakéhokoli IT projektu. Systém, který potřebuje banka získat, lze prakticky pořídit dvěma způsoby – vlastním vývojem, nebo koupí systému od externího dodavatele.

2.4.1 Vývoj vlastním IT oddělením Interní vývoj takovéto aplikace prakticky nebyl moţný, jelikoţ IT oddělení banky nemělo dostatečné zkušenosti s potřebnými technologiemi, proto by vývoj potřebných aplikací trval neúměrně dlouho a konečné náklady by byly vyšší neţ u řešení poskytnutého zkušeným dodavatelem.

2.4.2 Outsourcing Nákup řešení od zkušeného dodavatele můţe urychlit implementaci a přinést zkušenosti se zaváděním podobného systému v obdobném prostředí. Ovšem i s kupovaným řešením mohou vzniknout komplikace. Původně zřejmě management banky nepřikládal rozsahu tohoto projektu dostatečný význam. Na základě nevhodného rozhodnutí a zřejmě i nedostatečných finančních prostředků byla k realizaci řešení vybrána nejmenovaná společnost, která svými kapacitami nestačila na vývoj

18

řešení, které by pokrylo potřeby tak velké společnosti, jako je banka působící na finančních trzích České i Slovenské republiky. Projekt se sice dostal aţ do fáze testování produktu bankovními testery, ale nedostatky shledané při těchto testech byly natolik fatální, ţe projekt musel být ukončen. Na základě takto získaných zkušeností bylo vypsáno nové výběrové řízení, kde byl jedním z kritických faktorů úspěchu v tomto řízení dostatečně silný partner s dobrými a snadno ověřitelnými referencemi, aby rozhodující orgán mohl ověřit, ţe informace uvedené v nabídce jsou pravdivé.

2.4.3 Kompromis Pokud je to moţné, je velmi výhodným řešením spojení obou výše uvedených postupů. Vnitřní IT zná velmi dobře prostředí, které v bance funguje, externí firma zná zase řešení, s kterým bankovní IT nemá zkušenosti. V modelovém případě můţe být interní IT oddělení vyuţito k řešení problematiky komunikace mezi nově vznikající aplikací a stávajícími bankovními aplikacemi, s kterými potřebuje komunikovat. Externí odborníci se pak mohou věnovat výhradně problematice, na kterou banka odborníky nemá. Tím se ve fázi vývoje a nasazení mohou ušetřit nemalé finanční prostředky i čas, jelikoţ externí pracovníci nemusí být zaškolování do způsobu fungování vnitřních systémů banky.

2.5 Věcný popis řešení Pro zpracování papírových platebních příkazů elektronicky bude vybudována zcela nová IT infrastruktura, jejíţ implementace přinese urychlení zpracování příkazů, sníţení chybovosti a také pohodlnější vyhledávání přijatých platebních příkazů v archivu, při případné reklamaci nebo auditu zpracování. Tato infrastruktura bude pomocí síťové komunikace napojena na stávající bankovní systémy, kterým bude zasílat výstupy v podobě vytěţených dat z naskenovaných platebních příkazů.

19

2.6 Fáze skenování Pro převedení papírových platebních příkazů do elektronické formy bude vybudováno centrální skenovací pracoviště, které bude vybaveno vysokorychlostními skenery, schopnými naskenovat i oboustranné platební příkazy při jediném průchodu příkazu zařízením. Papírové platební příkazy budou sváţeny na skenovací pracoviště ke zpracování. V případě podání urgentního platebního příkazu bude tento na pracoviště zaslán faxem. Všechny doručené platební příkazy zde budou obsluhou skenerů naskenovány. Urgentní platební příkazy budou zpracovány přednostně. Na displeji skeneru uvidí operátor skenování rychlý náhled úspěšnosti provedené operace. To znamená, ţe uvidí nedokonalý obraz naskenovaných platebních příkazů, ze kterého bude moci usoudit, zda skenování probíhá úspěšně. Pokud uvidí, ţe naskenované obrazy jsou příliš světlé nebo naopak příliš tmavé, skenování dávky zastaví, případně smaţe celou naskenovanou dávku a zahájí skenování znovu. Jestliţe ani opětovné skenování nepřinese zlepšení kvality naskenovaných obrazů, bude tento problém řešit s technikem zodpovědným za provoz skenerů. I kdyţ operátor skenování neuvidí detailní atributy a naskenované hodnoty, je zodpovědné posouzení kvality průběhu skenování velmi důleţité, jelikoţ toto je jediný vstup dat do systému. Operátoři navazujících pracovišť nemají k papírovým originálům platebních příkazů přístup, proto by měli velmi ztíţenou práci. Z nekvalitních skenů by systém jen těţko vytěţil správné hodnoty nebo by si nebyl jistý rozpoznáním, proto by k validaci a verifikaci (tyto činnosti jsou popsány v následujících kapitolách) předloţil kaţdý platební příkaz a všechna jeho pole, coţ je neţádoucí a proces zpracování by to velmi zpomalilo.

2.6.1 Fáze zpracování Po naskenování procházejí platební příkazy kontrolami korekce a verifikace. Během těchto kontrol systém nabízí k potvrzení hodnoty, jejichţ rozpoznáním si není na sto procent jistý, nebo je nerozpoznal vůbec. Dále jsou ke korekci nebo verifikaci automaticky nabízeny příkazy, které sice byly rozpoznány se stoprocentní jistotou, ale objem peněţních prostředků je vyšší neţ stanovená 20

hranice pro automatické kontroly, a proto musí dojít k manuální kontrole operátorem. Nastavení těchto parametrů a zodpovědnost za ně je v dokumentu zmíněna později. Kaţdý manuální zásah korektora musí být ještě potvrzen verifikátorem. Takto zkontrolované a potvrzené platební příkazy odcházejí do backendových systémů, kde dojde k jejich zaúčtování a je zajištěn převod finančních prostředků. Papírové platební příkazy jsou následně archivovány dle vnitřních předpisů banky. V modelovém případě se jedná o archivaci po dobu patnácti let.

2.6.2 Navazující zpracování Tím, ţe je papírový platební příkaz určen k archivaci, nekončí ţivotní cyklus dat z něj vytěţených. Ta musí projít dalším zpracováním tak, aby se uskutečnil poţadovaný převod finančních prostředků z účtu příkazce na účet příjemce. K tomuto převodu musí dojít v klientem poţadovaném termínu a také, pokud účty příkazce a příjemce nejsou ve shodné měně, musí dojít ke konverzi. To uţ není poţadovaná funkcionalita pro tento projekt, jelikoţ je jiţ integrována do jiných systémů, které jsou v bance pouţívány. Kromě výše uvedeného zajištění převodu finančních prostředků či jejich konverze, které zajišťují transakční systémy banky, například systém Profile, jsou data zpřístupněna i oddělení vyřizujícímu případné dotazy klientů na stav zpracování reklamace. Toto má na starosti oddělení, které je nazýváno back office. Kancelář back office má ke čtení zpřístupněný archiv zpracovaných papírových příkazů v elektronické podobě, kde můţe v případě reklamací podaných klienty, například pokud klient nesouhlasí s částkou strţenou ze svého účtu, vyhledávat elektronickou podobu příkazů a zároveň můţe zkontrolovat, co bylo systémem ke zpracování odesláno, kdy byl příkaz zaúčtován, případně zda byly během zpracování odhaleny nějaké chyby. Dále je zde vidět nejen elektronická podoba příkazu, ale i změny provedené při validaci a verifikaci. Toto můţe být velmi uţitečné u hůře čitelných platebních příkazů. Pracovníci back office nemají moţnost v záznamech o platebních příkazech měnit ţádné údaje. Do archivu zpracovaných platebních příkazů mají přístup i pracovníci na přepáţkách poboček banky. Zde bude moţné dohledat všechny přijaté platební příkazy, a to jak ty, které byly zpracovány, tak i ty, jejichţ zpracování neproběhlo z důvodu výskytu chyby v podaném příkazu. V případě výskytu chyby bude tato v archivu uvedena, aby mohl být klient 21

pracovníkem pobočky informován o důvodu odmítnutí zpracování příkazu. Systém sám o sobě nebude umět proaktvině informovat o nalezených chybách v průběhu zpracování. Obr 1 - Model zpracování platebních příkazů uc Model j ednání Zpracov ání příkazů

Naskenov at platební příkazy

Pracov ník skenov acího oddělení

Ov ěřit podpisov ý v zor Ov ěřit účet klienta

«extend»

Verifikov at platební «include» příkazy «include» Zpracov at platební příkazy

Pracov ník back office

«include» Odeslat do Back end

«include» Uložit data do DB

«include»

Data uložena v DB

Pracov ník pobočky

Zdroj: Vlastní tvorba

V obrázku 1 je znázorněn model procesu zpracování platebních příkazů. Jasně z něj vyplývá, jak proudí data systémem a v který okamţik mohou pracovníci banky vyuţívat údaje pořízené naskenováním platebních příkazů.

22

2.7 Technický popis řešení Aplikace pro zpracování papírových platebních příkazů elektronickou formou musí být robustní, jelikoţ bude zpracovávat velký objem platebních příkazů, z nichţ bude vytěţeno velké mnoţství dat. Jak jsem jiţ uvedl, aplikace by měla zvládnout zpracovat průměrně 10 000 platebních příkazů za den. Z toho vyplývá, ţe obzvláště u skenerů musí být kladen důraz na rychlost a kvalitu zpracování. Samozřejmě nejen rychlý hardware, ale i softwarové vybavení musí být dostatečně kvalitní a stabilní. Celý systém elektronického zpracování papírových platebních příkazů se bude skládat z několika komponent, které zajistí proces zpracování. K síťovému propojení a zajištění komunikace mezi jednotlivými komponentami bude vyuţita stávající infrastruktura banky a jiţ existující síťové prvky. Technologický návrh řešní je uveden v obrázku č.2. Nově vyvíjené komponenty, které budou v navrhovaném řešení pouţity, budou vyrobeny nebo upraveny tak, aby byly se stávající infrastrukturou plně kompatibilní a nevyţadovaly úpravy nebo změny jiţ pouţívaného hardware ani software. Komponenty, které je třeba pro potřeby navrhovaného řešení pořídit: skenery validační a verifikační stanice Validační a verifikační stanice nejsou fyzicky nová speciální zařízení. Jedná se pouze o instalaci software na standardní pracovní stanice, které jsou v bance pouţívány. Komponenty, které již v bance existují a budou s nově vzniklým řešením propojeny: aplikační server databázový server pracovní stanice v back office a na klientských pobočkách. síťová infrastruktura Jednotlivé komponenty se nebudou nacházet na jednom jediném pracovišti. Vybudování skenovací linky je plánováno na pracovišti v Hradci Králové, jelikoţ zde jiţ pracoviště na zpracování papírových platebních příkazů existuje. Sice není vybaveno skenovací linkou, ale i tak zde bude uţitečné vyuţít znalosti a zkušenosti stávajícího týmu. 23

Pracoviště back office je umístěno v Praze a v dnešní době, která umoţňuje rychlou elektronickou komunikaci, není důvod přesouvat jej k pracovišti zpracování. Komunikace bude probíhat výhradně po vnitřní zabezpečené síti banky. Popis sítě a síťových prvků, které budou pouţity, je v tomto dokumentu zmiňován jen velmi stručně a jen v nutných případech. Nejsou součástí navrhovaného řešení a záměrem je maximální vyuţití infrastruktury, která je v bance pouţívána. Zabezpečení síťové komunikace také není obsahem této práce, protoţe zde nedochází k ţádným změnám v jiţ pouţívané infrastruktuře a bude plně vyuţito standardního zabezpečení, které je v bance na vysoké úrovni, a proto se jím není třeba více zabývat. Obr. 2 - Technický návrh řešení zpracování papírových platebních příkazů: stm Model architektury

«device» Scanner

Zprocesov ání příkazů

«device» Zpracov atelské PC

«executionEnviron... Aplikační serv er

«executionEnviron... Back end system

DB serv er

«device» Klient Back office

«device» Klient Pobočka

Zdroj: Vlastní tvorba

2.7.1 Skenery Půjde o dva vysokorychlostní oboustranné skenery Kodak i1800 (viz příloha 2) s podavači, kam je vţdy vloţena dávka příkazů ke zpracování. Tento skener na pokyn pracovníka zpracuje celou dávku bez jeho dalšího zásahu. Skenery budou vybaveny snímači 24

kontrolujícími takzvané dvojpodání tedy podání dvou (nebo více) platebních příkazů najednou. V tom případě se zpracování dávky zastaví, obsluha skeneru musí zjištěný problém odstranit a spustit zpracování dávky znovu. Velikost dávky není pevně daná a v systému se dá parametrizovat. Jako optimální velikost dávky se povaţuje přibliţně 300 platebních příkazů. Pokud pracovník přepáţky vloţí do skeneru dávku větší, tato je automaticky rozdělena do více dávek. Pracoviště skenování bude vybaveno jedním malým skenerem Kodak i1220 (viz příloha 3), který bude slouţit k naskenování problematických platebních příkazů. To jsou například hodně pomačkané platební příkazy, které by vysokorychlostní skenery zpracovávaly obtíţně nebo by je odmítly zpracovat, jelikoţ jejich automatický podavač neumí podat papíry pomačkané nebo původně přeloţené. Kapacita skeneru Kodak i1800 je výrobcem uváděna na rychlost zpracování aţ 200 oboustranně potištěných listů za minutu. U skeneru Kodak i1220 je uváděna rychlost aţ 45 oboustranně potištěných listů za minutu, ale ta není tak podstatná, jelikoţ vyuţití tohoto skeneru očekáváme pouze ve výjimečných případech. Hlavní těţiště zpracování leţí na skenerech i1800, které by měly průměrně zpracovat 5.000 platebních příkazů denně. Dodávka skenerů Kodak byla vybrána z důvodu dlouhodobé smlouvy mezi bankou a firmou Kodak jako výhradního dodavatele tiskáren, faxů, skenerů a kopírovacích zařízení. K rozpoznání a vytěţení naskenovaných dat bude vyuţita technologie OCR – Optical Character Recognition. Tato technologie umoţňuje převádět různé typy papírových dokumentů, v tomto případě platebních příkazů na data, která se dají prohledávat a editovat. Pro potřeby zpracování platebních příkazů bude pouţita technologie, která umoţní vytěţovat data nejen z tištěných dokumentů, ale i z ručně vyplněných platebních příkazů. Rozpoznání ručně psaného písma je technologicky mnohem náročnější, bohuţel také méně spolehlivé a proto musí být doplněno fyzickou verifikací a validací rozpoznaných hodnot.

2.7.2 Validační a verifikační stanice Jedná se o klasické pracovní stanice, na kterých je nainstalována aplikace pro validaci a verifikaci naskenovaných platebních příkazů. Tyto stanice budou vybaveny čtečkami čipových identifikačních karet, kterými se budou pracovníci přihlašovat do systému. Vloţením karty do čtečky se pracovní stanice odemkne a pracovník můţe zahájit validaci 25

nebo verifikaci. Vytaţením karty ze čtečky dojde k uzamčení pracovní stanice. Kaţdé odemčení a uzamčení stanice bude systémem automaticky zaznamenáno do logu tak, aby později mohlo být dohledatelné, který pracovník v kterou dobu na pracovní stanici pracoval. Tyto logy jsou ukládány na disk pracovní stanice v adresáři, do kterého pracovník validace nebo

verifikace

nemá

přístup.

K těmto

souborům

má

přístup

pouze

pracovník

s administrátorskými právy. Zároveň je tento log exportován do systém G-Archive, tak aby tyto informace byly dohledatelné spolu s platebním příkazem.

2.7.3 Aplikační servery Aplikační servery jsou další z významných součástí systému. Je zde nainstalován software na rozpoznání naskenovaných platebních příkazů. Zároveň tu běţí zpracování výsledků validací a verifikací platebních příkazů operátory, kteří mají na svých stanicích pouze tenkého klienta aplikace, proto tedy všechny operace náročné na výpočetní výkon běţí právě na aplikačních serverech. Elektronický archiv, určený k vyhledávání zpracovaných příkazů bude provozován jako webová sluţba, kterou si uţivatel spustí na pracovní stanici. Tato stanice bude slouţit pouze jako terminál, zobrazující nalezené informace, ale vyhledání a zpracování informací do poţadované podoby bude probíhat na straně aplikačních serverů. Servery budou umístěné v datovém centru banky a budou na nich nainstalované komponenty aplikací PayScan potřebné ke zpracování a archivaci papírových platebních příkazů i jejich elektronických obrazů. Zpracování bude probíhat pomocí následujících komponent aplikace PayScan: - G-Scan – software na rozpoznávání naskenovaných dokumentů -

G-Correction/Verification – kontrola vytěţených dat

-

G-Archive – elektronický archiv

-

G-Batch Manager – distribuce dat, administrační konzole

26

2.7.4 Databázový server Databáze bude vystavena na architektuře Oracle9. Zde budou uloţeny všechny naskenované platební příkazy a datové věty (viz obrázek č.3) zaznamenávající všechny operace, které byly nad daty vytěţenými z platebních příkazů provedeny. Z těchto dat budou dále exportována data pro účetnictví, reporting a statistické údaje. Obr. 3 – Vzor odesílaných datových vět

Zdroj: Vlastní databáze Tato data jsou například zdrojem informací o „chování“ klienta. Banka vyhodnocuje finanční transakce svých klientů a podle nich dává nabídky na své produkty, jejichţ vyuţití můţe přinést klientovi například výhodnější tarify, nebo uzpůsobit bankovní sluţby tak, aby více vyhovovaly jeho potřebám. Za tímto účelem jsou primárně vyuţívána data uloţená v datovém skladu, kam samozřejmě bude aplikace navrhovaná v této práci poskytovat své výstupy.

9

http://www.oracle.com/cz/index.html [cit. 17.4.2011].

27

Do aplikační databázové struktury budou na denní bázi automaticky kopírovány aktuální bankovní číselníky nutné pro zpracování platebních příkazů. Kopie číselníků bude prováděna v nočních hodinách nebo ranních hodinách mimo provozní dobu klientských přepáţek. Vytváření kopie je nutné pro urychlení zpracování platebních příkazů a zároveň omezení datových přenosů ve vnitřní síti banky v pracovní době na nejnutnější minimum. Jedná se například o číselník měn, kurzovní lístek, číselník státních svátků a tak podobně. Naopak ověřování čísel účtů, podpisových vzorů a kontrola aktuálního zůstatku na účtu klienta bude probíhat přímo proti produkční databázi tak, aby byl systému zajištěn přístup k aktuálním datům. Tím se zajistí bezpečnost a správnost zpracování. Systém například neumoţní přečerpání prostředků na účtu klienta, který by podal platební příkaz k účtu, z kterého těsně před podáním příkazu vybral veškeré prostředky prostřednictvím bankomatu. Kontrolu čísel účtu a zůstatků na účtech bude systém schopen provést automaticky bez zásahu pracovníka zpracování. Na základě nastavení verifikačních parametrů bude systém automaticky nabízet ověření podpisového vzoru. Toto ověření musí provést pracovník zpracování, kterému systém automaticky nabídne výřez z platebního příkazu, kde se obvykle nachází podpis příkazce a zároveň vyvolá okno aplikace, která umoţňuje nahlíţení do databáze podpisových vzorů klientů. Při této aktivitě dojde k rozdělení obrazovky pracovní stanice na dvě poloviny, tak aby pracovník zpracování viděl oba dva podpisy vedle sebe a snadno je mohl porovnat. Systém nebude ručit za správnost takto ověřených podpisů. Zodpovědnost bude plně na straně pracovníka, který ověření podpisu provedl. Po potvrzení správnosti podpisu nebo vyřazení příkazu ze zpracování, pokud podpis nebude podpisovým vzorům odpovídat, se okno aplikace vrátí do původního nastavení, v jakém bylo před zahájením této kontroly. Vyvolání okna pro kontrolu podpisu proti podpisovému vzoru bude moţné spustit i přímo z verifikační konzole z menu aplikace nebo prostřednictvím určené klávesové zkratky. Po ukončení kontroly podpisu proti podpisovým vzorům nebude aplikace komunikující s databází vzorů ukončena, ale bude dále spuštěna na pozadí, aby se urychlilo její další případné vyvolání. Pro zajištění bezpečnosti a integrity dat v databázích, ze kterých bude aplikace pro zpracování platebních příkazů čerpat data, bude aplikačnímu účtu přiděleno pouze právo ke čtení dat. Vkládání nových hodnot nebo změna stávajících informací povolena nebude. K tomuto bude

28

pouţito standardních nastavení implementovaných v databázovém stroji Oracle, která jsou běţně při komunikaci s databází pouţívána. Stejně tak ostatní systémy přistupující k datům aplikace zpracování platebních příkazů nebudou mít oprávnění tato data měnit nebo jakákoliv data do databáze vkládat. Obr 4 - Analytický databázový model:

Zdroj: Vlastní tvorba

29

Obrázek č. 4 ukazuje návrh analytického datového modelu, který zdůrazňuje napojení nové funkcionality, to je tabulky platebních příkazů, do standardní databázové infrastruktury banky, v tomto případě naznačené například číselníkem měn nebo číselníkem bank.

2.7.5 Síťová komunikace, EDI Poté co platební příkaz projde všemi operacemi, které jsou součástí nově budovaného systému, jsou pomocí EDI zpráv data odeslána do stávajících bankovních systémů ke zpracování. EDI (Electronic Data Interchange) je způsob elektronické komunikace mezi různými systémy. Tato komunikace probíhá formou strukturovaných zpráv. Struktura je v rámci banky pevně daná, díky tomu mezi sebou dokáţí komunikovat systémy různých dodavatelů plně automaticky nebo jen s minimem manuálních zásahů. Struktura zpráv je postavena nad standardem UN/EDIFACT, coţ je mezinárodní EDI standard vyvíjený pod patronátem United Nations (OSN). Zkratka vznikla ze slov United Nations/Electronic Data Interchange For Administration, Commerce, and Transport. EDIFACT byl "adoptován" mezinárodní organizací pro standardizaci (ISO) jako standard ISO 973510. Tento standard nenařizuje, ale pouze navrhuje, jak by struktura EDI zprávy měla vypadat a jaké atributy by měla obsahovat. Proto se vlastní implementace můţe případ od případu lišit. Ovšem v rámci jedné organizace existují závazná pravidla, jak zpráva musí být strukturovaná a které atributy jsou povinné. K přenosu těchto zpráv bude vyuţita stávající síťová infrastruktura banky postavená nad architekturou T-Hub. Tím nevznikají další náklady a je zajištěna kompatibilita s ostatními systémy banky.

10

EDIFACT. ShopCentrik. 2008, 3, s. 1. Dostupný z WWW: http://www.shopcentrik.cz/slovnik/edifact.aspx>.

30

2.8 Funkční popis řešení V předchozích kapitolách byly popsány poţadavky na nově navrhované řešení, postup jak k rozhodnutí došlo i zevrubný technologický popis a dále i to, do jakých aplikačních částí budou rozděleny jednotlivé činnosti. Předchozí kapitoly nahlíţely na projekt hlavně z pohledu IT oddělení. V této kapitole stručně zmíním poţadavky sponzora projektu, tedy business části banky, jejíţ pracovníci budou reálnými uţivateli aplikací. IT oddělení bude po ukončení projektu a uvedení nově vybudovaného řešení do rutinního provozu zajišťovat podporu všem aplikacím, ale nebude uţivatelem ţádné z nich. Tato kapitola tedy popisuje, jaké poţadavky jsou na systém kladeny, ale neřeší jejich technologickou realizaci. Způsob technologického řešení je popsán v kapitole Realizace navrhovaného řešení.

2.8.1 Digitalizace papírových platebních příkazů Papírové platební příkazy musí být převedeny do elektronické podoby - naskenovány. Naskenovány musí být obě strany platebního příkazu, pokud je příkaz oboustranný. Tyto dvě strany musí být dále v systému prezentovány jako jeden celek. Papírový platební příkaz musí být označen identifikátorem, aby v případě potřeby jeho pozdějšího vyhledání, například z důvodu reklamace podané klientem, bylo prokazatelně moţné spojit papírovou a elektronickou podobu platebního příkazu.

2.8.2 Získání dat Data musí být z papírových platebních příkazů získána bez manuálního přepisování operátory. Ti budou dohlíţet na kvalitu a správnost získaných dat. Není ţádoucí, aby operátoři museli kontrolovat kaţdý digitalizovaný příkaz. Systém musí umět pracovat automaticky. Pracovníci oddělení zpracování musí mít moţnost kontrolovat platební příkazy podané na vysoké částky. Tyto příkazy musí být předloţeny ke kontrole automaticky, aniţ by je pracovníci v systému museli vyhledávat.

31

2.8.3 Kontroly vytěžených dat V případě, ţe si je systém nejistý rozpoznáním údajů, nebo byly dosaţeny businessem stanovené limity pro manuální kontrolu pracovníkem zpracování, je příkaz zobrazen na pracovní stanici pracovníka zpracování. Zde proběhne také kontrola podpisu proti podpisovým vzorům uloţeným v centrální databázi, pokud je příkaz takového typu nebo na takovou částku, ţe kontrolu podpisového vzoru vyţaduje – toto je obvyklé u platebních příkazů podaných na vysokou částku. Je-li podán příkaz na částku, u níţ business nevyţaduje manuální kontrolu operátorem a zároveň je tento platební příkaz stoprocentně rozpoznán a všechny údaje jsou korektní, prochází automaticky rovnou ke zpracování backendovými systémy. Po úspěšném otestování systému je cílem mít takto zpracovaných platebních příkazů co nejvíce. Systém provede kontrolu na správnost čísel účtů uvedených na platebním příkazu. Pokud se bude jednat o číslo účtu vedeného u „naší“ banky, je ověřena správnost čísla i to, zda je účet aktivní. V případě, ţe se jedná o účet u jiné banky, je provedena kontrola na modulo 11. Více o modulu 11 je uvedeno v kapitole 3.1.14 Kontroly. U vnitřních účtů není nutné provádět kontrolu na modulo 11, jelikoţ musí jít o úhradu z nebo na existující účet, u kterého byla tato kontrola provedena jiţ při jeho zakládání.

2.8.4 Předání dat ke zpracování Po potvrzení, případně ruční korekci chybně nebo nepřesně rozpoznaných hodnot systém provede automatické kontroly náleţitostí platebního příkazu. Pokud není uvedena, doplní splatnost na nejbliţší následující pracovní den. V případě konverzní operace doplní kurz a také poplatky, které za zpracování příkazu budou klientovi naúčtovány a předá příkaz ke zpracování backendovými systémy. Pokud je podán urgentní platební příkaz, musí být systémem předána informace, díky které bude tento příkaz v backendovém systému zpracován přednostně.

2.8.5 Předání informace o zpracování klientovi Tato část jiţ nespadá do řešení týkající se modelované aplikace. Je zde uvedena pouze pro úplnost toku informací v rámci zpracování.

32

Klient je dle nastavení jeho účtu informován o provedené transakci – nejčastěji výpisem z účtu. V případě nejasnosti nebo nesrovnalosti je transakce dohledána v archivu, kde jsou ověřena zpracovaná data. Obr. 5 - Funkční model navrhované aplikace act Funkční model

Platební příkaz

Účet

Kontrola zůstatku

Zpracuj příkaz

Čti data

Odešli peníze

Výpis z účtu

Kontrola podpisového vzoru

Klient

Zdroj: Vlastní tvorba

Na obrázku č. 5 je zjednodušený model celé funkcionality systému a toku dat od podání platebního příkazu klientem, aţ po jeho vyrozumění o provedené transakci výpisem z účtu i s naznačenými základními kontrolami.

33

3 Realizace navrhovaného řešení V této fázi jsou popsány všechny části, jak bylo řešení navrţeno i poţadavky, kterým se řešení muselo přizpůsobit, aby splňovalo poţadavky budoucích uţivatelů a systém byl po nasazení do rutinního provozu tím, co se od něj očekává. To znamená sadou aplikací, která urychlí a usnadní zpracování papírových platebních příkazů, přitom zajistí vyšší kontrolu a kvalitu dále zpracovávaných údajů, neţ tomu bylo doposud.

3.1 Aplikace Focus Aplikace

Focus

se

skládá

ze

specializovaných

sub-aplikací

G-Scan,

G-

Correction/Verification, G-Archive a G-Batch Manager, které spolu tvoří celek. Ten pak poskytuje komplexní sluţbu pro zpracování papírových platebních příkazů elektronickou formou, a to od úvodního naskenování aţ po závěrečné uloţení dat do archivu a databáze. I kdyţ jednotlivé sub-aplikace jsou schopné fungovat samostatně, v modelovém případě by dodání jen některé z nich nesplnilo zadání, které bylo na začátku vývoje aplikace Focus. V následujících kapitolách je popsána realizace jednotlivých činností v rámci celého procesu zpracování platebních příkazů.

3.1.1 Skenování Skenování bude probíhat na určeném skenovacím pracovišti, které bude vybaveno vysokorychlostními scannery Kodak, jenţ jsou schopny vytěţovat data z oboustranných dokumentů. Zároveň budou vybaveny potiskovým zařízením, které bude tisknout na rubovou stranu naskenovaných platebních příkazů jednoznačné identifikátory, pod kterými bude v případě reklamace moţné jednoduše spárovat fyzický (papírový) platební příkaz s jeho elektronickým otiskem. Identifikátor bude dvanáctimístné číslo, které bude unikátní pro kaţdý zpracovaný platební příkaz. Scanner musí zároveň zajišťovat kontrolu, aby v dávce nedošlo k tzv. „dvojpodání“, coţ znamená, ţe by byly zpracovány dva slepené příkazy jako jeden. Toto je zajištěno ultrazvukovými snímači, které vyhodnocují na třech místech najednou sílu zpracovávaného papíru. Pokud některý ze snímačů zjistí odlišnou hodnotu, vyhodnotí ji jako zpracování více

34

listů papíru najednou. V takovém případě se zpracování zastaví a bude nutný manuální zásah operátora skenovacího pracoviště. Systém tento poţadavek splňoval, ale v průběhu testů byl zjištěn problém. Pokud byla dávka opakovaně skenována, došlo k přepisu jiţ jednou natištěného identifikátoru, který se tímto stal nečitelným. Bohuţel, hardwarové řešení neumoţňovalo přesunutí tiskové hlavy tak, aby tiskla na jiné místo platebního příkazu. Toto bylo nakonec vyřešeno metodickým pokynem pro pracovníky skenovací linky, kteří v případě opětovného vloţení příkazů na podavač skeneru, musí příkazy pootočit o 90°. Systém je nastaven tak, ţe vytištěnou hodnotu identifikátoru ani v případě zrušené dávky nepouţije. Za správný je pak povaţován identifikátor s vyšší hodnotou. Původně natištěný identifikátor se v elektronické podobě v systému nebude vyskytovat.

3.1.2 OCR – Optické rozpoznávání znaků Optické rozpoznávání znaků – optical character recognition je mechanický nebo elektronický převod ručně psaného nebo tištěného textu do jeho elektronicky editovatelné podoby. Toto je velmi často vyuţíváno k převádění knih nebo dokumentů například pro jejich uveřejnění na internetu nebo zařazením do elektronické knihovny. Zvláštní význam má tato technologie pro slabozraké, kterým zpřístupní dříve nedostupné dokumenty. Digitalizace dokumentů nebo knih umoţní například jejich převedení do hlasové podoby pomocí tak zvaných screen readerů. Pro účely této modelované aplikace je OCR základním kamenem, zvláště část zaměřená na rozpoznání tištěných textů, které je úspěšnější neţ u odpovídajících textů a hodnot psaných rukou11. OCR software je zaloţen na rozpoznávání znaků nebo částí znaků. Velmi časté je rozdělení rozpoznaného znaku do kruhu rozděleného přibliţně po 15° do výsečí. Tyto výseče systém analyzuje, na základě vyhodnocení rovných linií a křivek rozhoduje o jaký znak – písmeno nebo číslici – se jedná. Kvalita rozpoznání stále není stoprocentní ani u tištěného ani psaného textu. U tištěného textu se úroveň rozpoznání pohybuje, dle pouţitého fontu, v rozmezí 71%

11

FERILLI, Stefano. Automatic Digital Document Processing and Management. 1st Edition. Bari, Italy :

Springer, 2011. 295 s. ISBN 978-0-85729-197-4, s. 161.

35

aţ 98%. Rozpoznání ručně psaného textu je na mnohem niţší úrovni a je stále aktivně zkoumáno a vylepšováno. V případě zpracování papírových platebních příkazů je zde vyuţívána moţnost vytěţení tištěných (standardních) a ručně psaných (nestandardních) údajů. Některé systémy jsou schopny „aktivního učení“, coţ se uplatňuje hlavně u delších textů psaných jedním fontem nebo jedním rukopisem. Systém se naučí základní charakteristiky pouţívaného písma, a tím dosáhne mnohem vyšší úspěšnosti jeho rozpoznání. Toto není v případě zpracování papírových platebních příkazů lehce aplikovatelné, jelikoţ zde dochází ke zpracování krátkých textů s mnoha odlišnostmi pouţitého tiskového fontu nebo rukou psaného písma. Pro usnadnění v navrhovaném řešení je pouţita technologie masek a tak zvané slepé barvy. To znamená, ţe do aplikace jsou nahrány šablony nebo vzory nejčastěji pouţívaných platebních příkazů, z kterých systém přesně ví, kde se bude nacházet jaké pole, například částka, datum, číslo účtu nebo podpis a jak je označeno.

3.1.3 Použité technologie OCR Jako technologie budou v navrhované aplikaci vyuţity systémy RecoStar pro rozpoznání tištěných příkazů a DokuStar pro rozpoznání rukou psaných platebních příkazů. RecoStar je technologie zaměřená na vytěţování dat z předtištěných formulářů. DokuStar je technologie zaměřená na rozpoznávání a digitalizaci nestrukturovaných dokumentů. Před nasazením systému k testování bude uţivatelem do systému uloţena informace, jaké hodnoty se budou v kterém poli nacházet. Banka dodá s předstihem dodavateli vzory všech pouţívaných platebních příkazů. Dodavatel je převede do elektronické podoby a kaţdému poli, do kterých klienti vyplňují hodnoty, budou přiděleny přesné souřadnice. Tím vznikne maska platebního příkazu. Při pozdější kontrole by tak nemělo dojít k pochybení, kdy se například systém snaţí rozpoznat částku platebního příkazu z čísla účtu nebo naopak. Všechny typy platebních příkazů, které mají v systému svoji masku, budou zpracovávány jako standardní příkazy.

36

Mezi standardní platební příkazy (viz příloha 4) patří všechny typy příkazů, jejichţ formuláře si klient můţe vyzvednout na pobočkách. Tyto platební příkazy jsou vytištěny tak zvanou slepou barvou, kterou aplikace zná z dříve připravené masky a umí ji z naskenovaného obrazu odfiltrovat. Tím je umoţněno snadnější rozpoznání vyplněných hodnot. Aplikaci jsou k rozpoznání předány příkazy, z kterých jsou odstraněny veškeré předtištěné popisy a orámování. Systém proto rozpoznává jen informace doplněné klientem. Bude-li někdy v budoucnu zaváděn nový typ platebního příkazu, je nezbytně nutné, aby po schválení jeho podoby byla opět vytvořena jeho maska, která bude importována do aplikace. Aţ následně bude moci být příkaz distribuován na pobočky a klientům. Starší typy platebních příkazů, které klienti mohou mít v omezeném mnoţství u sebe a jsou stále bankou akceptovány, dále příkazy, které jsou vytištěny z bankovních systémů na běţný papír, budou zpracovávány jako nestandardní příkazy (viz příloha 5). Jejich zpracování je komplikovanější, protoţe v systému neexistuje jejich maska, ani nejsou vytištěny slepou barvou, která by mohla být před rozpoznáním odfiltrována. Systém je nastaven tak, ţe vyhledává údaje podle klíčových slov, jako například „splatnost“ nebo „částka“. Tyto příkazy nemohou projít plně automatickým zpracováním a vţdy vyţadují kontrolu operátorem. Systém musí být schopen zpracovat následující typy platebních příkazů: jednotlivý příkaz k úhradě hromadný příkaz k úhradě jednotlivý příkaz k inkasu hromadný příkaz k inkasu K rozpoznání typu platebního příkazu bude docházet na základě natištěného čárového kódu. Kaţdý formulář obsahuje vlastní čárový kód, který obsahuje typ formuláře a jeho verzi. To umoţní skenovat standardní platební příkazy bez potřeby jejich třídění před skenováním, coţ výrazně usnadní práci skenovací linky. Systém dokáţe rozpoznat i příkazy vloţené do skeneru obráceně a k verifikaci nebo validaci je zobrazí správně natočené. Dokumenty, na kterých systém neidentifikuje čárový kód, povaţuje za nestandardní. V případě, ţe systém nedokáţe automaticky rozpoznat typ dokumentu, například z důvodu poškozeného čárového kódu, vybere operátor správnou masku z nabídky a další zpracování proběhne obvyklým způsobem. Kontrola činnosti operátora je popsána v následujících kapitolách. 37

3.1.4 Korekce vytěžených dat Korekce je první kontrola naskenovaných platebních příkazů operátorem. K výběru dávek ke kontrole bude slouţit samostatná komponenta systému – G-Correctionon/Verification Console. V jejím úvodním okně se řadí naskenované platební příkazy automaticky podle priority a času naskenování. Po spuštění verifikační konzole nabídne aplikace pracovníkovi seznam dávek určených ke korekci. Dávky budou řazeny dle priority, ty s nejvyšší prioritou nejvýše. Libovolně si bude moci pracovník nastavit zvýraznění prioritních transakcí (urgentních plateb). Tyto platby budou označené jinou barvou. Pokud nejsou v seznamu ţádné prioritní transakce, jsou dávky řazeny dle času skenování. Ty nejdříve naskenované se budou nacházet v seznamu nahoře. Pracovník můţe pomocí tlačítka pro spuštění korekcí zahájit zpracování dávek, v takovém případě mu systém automaticky přidělí dávku s nejvyšší prioritou. Poklepáním na vybranou dávku můţe zahájit korekci konkrétní dávky ze seznamu. Po zpracování dávky se systém zeptá, zda chce pracovník pokračovat v korekci další dávky. Pokud zvolí, ţe ve zpracování pokračovat nechce, systém se vrátí na úvodní obrazovku a zobrazí se seznam nezpracovaných dávek. Ke korekci budou nabídnuty příkazy, které systém nerozpoznal, nebo si není jistý rozpoznáním některých znaků. Toto očekávám hlavně u rukou psaných platebních příkazů. Systém nabídne korektorovi rozpoznané hodnoty a zároveň zobrazí výřez naskenovaného formuláře s hodnotou, kterou nabízí ke kontrole. V případě, ţe se systému nepodaří hodnotu vůbec rozpoznat, bude zobrazen výřez platebního příkazu a pole k natypování bude prázdné. Korektor má moţnost potvrdit hodnotu rozpoznanou systémem, vyplnit hodnotu sám, nebo označit platební příkaz jako nerozpoznatelný. V případě oboustranného dokumentu systém umoţní zkontrolovat obě strany dokumentu. Úroveň, dle které systém rozhoduje o úspěšnosti rozpoznávání, je parametrizovatelná. Nastavuje se v procentních bodech. Čím bude tato hodnota vyšší, tím si bude systém jistější a bude nabízet k manuální kontrole méně příkazů, zároveň však roste pravděpodobnost neodhalené chyby. Dodavatel systému provede výchozí nastavení podle svých zkušeností se zaváděním tohoto systému v předchozích implementacích v jiných bankovních domech. Optimální nastavení systému můţe být zpřesněno během testování a pilotního provozu 38

aplikace. U standardních platebních příkazů bude tato hodnota na základě zkušeností dodavatele nastavena na vyšší úroveň neţ u nestandardních. Toto nastavení je oprávněn provádět pouze administrátor systému. Vţdy je však nutné kalkulovat s dvěma veličinami – dobou zpracování formuláře (klesá s vyšší úspěšností rozpoznávání) a neodhalenou chybovostí (roste s vyšší úspěšností rozpoznávání). V rámci testů provedených bankovními testery na omezeném vzorku platebních příkazů se zdála tato nastavení optimální. Po zahájení pilotního provozu, kdy bylo k dispozici více vzorů ručně psaného písma, bylo rozhodnuto o sníţení hodnoty jistoty rozpoznání u nestandardních příkazů tak, aby operátoři měli vyšší kontrolu nad zpracovávanými údaji. Obr. 6 - Ukázka systémem nerozpoznané hodnoty nabídnuté ke korekci

Zdroj: Vlastní tvorba, snímek obrazovky z testování systému

Aplikace se automaticky posouvá po znacích navrţených ke kontrole. Pokud je navrţený znak správný (viz obrázek č. 6), operátor jej nemusí přepisovat, stačí potvrzení klávesou Enter, jinak znak přepíše a aplikace se automaticky posune na další navrţený znak. Takto operátor pokračuje stále dokola, dokud nezkoriguje celou dávku. 39

Systém musí zajistit, aby jeden platební příkaz nemohl být zpracován dvěma různými pracovníky. Jakmile si pracovník načte platební příkaz ke kontrole, bude záznam uzamčen jednoznačnou identifikací pracovníka a číslem stanice, na které je zpracováván. Ţádnému jinému pracovníkovi nebude zpracování tohoto příkazu umoţněno. Systém zobrazí hlášku, kde bude informovat, ţe platební příkaz je zpracováván jiným pracovníkem. Pokud se pracovník rozhodne zpracování příkazu v průběhu zpracování ukončit, bude mu to umoţněno, ale systém zobrazí hlášku, ţe všechny dosud provedené změny v platebním příkazu budou ztraceny. V některých případech (viz kapitola 3.1.6 Verifikační parametry) je nutné provést kontrolu podpisového vzoru. Pokud podpis na platebním příkazu nesouhlasí s podpisovým vzorem k danému bankovnímu účtu, platební příkaz musí být vyřazen ze zpracování. Na toto bude pouţita externí komponenta pro zobrazování podpisových vzorů uloţených v databázi. Popis této komponenty není obsahem této práce. Všechny změny, které korektor s platebním příkazem provedl, musí být v systému zaevidované a zpětně dohledatelné i s údajem, který pracovník konkrétní platební příkaz zpracovával.

3.1.5 Verifikace vytěžených dat Verifikace se dá popsat také jako implementace „kontroly čtyřech očí“. Verifikátor provádí kontrolu změn provedených v rámci validace. Pokud má operátor oprávnění provádět validační i verifikační kontroly, systém zajistí, ţe takovému operátorovi nebude umoţněno verifikovat změny, které sám provedl při korekci. K verifikaci se nabízejí platební příkazy, v kterých byla během korekce provedena změna nebo jejichţ částka je vysoká a v systému je nastaveno, ţe pro tuto částku musí být provedeny oba typy kontrol (viz shora uvedená kapitola Verifikační parametry). Pokud verifikátor provádí kontrolu údajů natypovaných korektorem, nemá moţnost vidět hodnoty, které korektor zadal, ale opět pouze výřez z platebního příkazu, který je momentálně obsahem verifikace. Zároveň systém nenabízí hodnotu, kterou sám rozpoznal. Pole pro verifikace bude tedy vţdy prázdné. Pokud se částka zadaná korektorem a verifikátorem neshoduje, je zobrazena chybová hláška a verifikátor má moţnost ji zadat znovu, případně zpracování příkazu přerušit nebo platební příkaz vyřadit ze zpracování. V případě hromadného platebního příkazu můţe být vyřazena pouze jedna z transakcí, další mohou být postoupeny ke 40

zpracování. V takovém případě ještě musí operátor provést kontrolu celkové sumy hromadného platebního příkazu. Vyřazené transakce budou uloţeny do archivu. Všechny změny, které verifikátor s platebním příkazem provedl, musí být v systému zaevidované a zpětně dohledatelné i s údajem, který pracovník konkrétní platební příkaz zpracovával.

3.1.6 Verifikační parametry V systému je moţné nastavit verifikační parametry, které určují, jaká pole při jakých částkách musí být korigována. Systém bude moţné nastavit tak, ţe pokud bude zadán platební příkaz na nízkou částku a bude 100% rozpoznán, nemusí projít korekcí ani verifikací a bude přímo zaslán ke zpracování bankovními systémy. Při vyšších částkách můţe být nastaveno, ţe ke kontrole dojde vţdy. Pro systém budou rozhodující dvě hladiny částek. Tyto částky mohou být parametrizovány jako částky A1 a A2 (například A1 = 1 000 Kč; A2 = 10 000 Kč) Platební příkazy s částkou niţší neţ A1 nemusí projít kontrolou, částky mezi A1 a A2 procházejí mírnou kontrolou a platební příkazy s částkou nad A2 procházejí přísnou kontrolou. U platebních příkazů, jejichţ hodnota překračuje částku A2, musí být také vţdy provedena kontrola podpisových vzorů. Obr. 7 - Vzor verifikačních kontrol: Jméno pole

Do A1 změna Ne

Do A1 změna Ano

Mezi A1 a A2 změna Ne

Mezi A1 a A2 změna Ano

Nad A2 změna Ne

Nad A2 změna Ano

Částka

0

1

1

1

1

1

Měna

0

0

1

1

1

1

č.účtu plátce

0

1

0

1

1

1

Kód banky plátce

0

0

0

0

0

1

č.účtu příjemce

0

1

0

1

1

1

kód banky příjemce

0

1

0

1

1

1

Zdroj: Funkční specifikace aplikace, L.Hand, str. 47 – vlastní úprava

Na obrázku č. 7 je uvedeno nastavení verifikačních kontrol pro pilotní provoz aplikace. Hodnota 0 v nastavení verifikačních parametrů znamená, ţe se kontrola nemá provádět, hodnota 1 znamená, ţe kontrola musí být provedena. Nastavení těchto kontrol a jejich hladin nesmí být zpřístupněno kaţdému pracovníkovi. Musí být vytvořena role oprávněného pracovníka, který bude za udrţování těchto pravidel

41

zodpovědný. Zároveň kaţdá úprava těchto parametrů musí být zaznamenána a v systému musí být zpětně dohledatelné, kdo a kdy změnu provedl. Během pilotního provozu byly částky nastaveny na úroveň tak, jak je ve výše uvedeném příkladu s tím, ţe před předáním do rutinního provozu, ke kterému ještě nedošlo, budou tyto částky změněny na vyšší hodnoty dle poţadavku business oddělení.

3.1.7 Preprocessing Preprocessing je kontrola na existenci účtu příkazce, případně i příjemce v backendových systémech banky a dále na to, zda je účet aktivní, tedy ţe nebyl zablokován ani zrušen. Tato kontrola je provedena po naskenování dávky ještě před tím, neţ je tato dávka nabídnuta ke korekci a verifikaci. Tím bude muset operátor čekat na provedení této kontroly při vlastním zpracovávání dávky pouze v případě, ţe systém chybně rozpoznal číslo účtu plátce nebo příkazce, případně jeho část, a on provedl manuální korekci. Preprocessing původně v aplikaci nebyl navrţen. Během testů jsme došli ke zjištění, ţe kontrola čísel účtů během zpracování platebního příkazu operátory zpomaluje zpracování. Zvláště při vyšším zatíţení bankovních sítí byla doba odezvy aţ 7 vteřin, během kterých operátor nemohl vykonávat ţádnou činnost. Pokud byly ve zpracovávaném platebním příkazu oba účty uvnitř banky, mohl operátor strávit čekáním aţ 14 vteřin, coţ se nezdá jako příliš dlouhá doba, ale pokud se takových platebních příkazů v rámci směny sešlo například 50, coţ se při průměrném zpracování 1 500 platebních příkazů mohlo stát, jednalo by se o zdrţení téměř 15 minut. Na základě kontroly opravených hodnot čísla účtu se bude rozhodovat o následujícím zpracování příkazu: -

V případě, ţe půjde o jednotlivý nebo hromadný příkaz k úhradě a číslo účtu plátce je v cizí měně, bude typ dokumentu změněný na „Konverze“.

-

V případě, ţe půjde o jednotlivý nebo hromadný příkaz k inkasu a číslo plátce (plátců) bude v cizí měně, bude dokument uloţen do archivu s chybovou hláškou: „Chybný – nezpracovaný, účet plátce nepodporuje operaci.“

42

3.1.8 Duplicity Zpracování duplicitních příkazů je neţádoucí, jelikoţ můţe dojít k dvojitému odepsání finančních prostředků z účtu klienta. Proto je vhodné při podezření na případné podání duplicitnícho platebního příkazu ověřit u klienta, například telefonicky, zda nedošlo k omylu. Kontrola duplicit můţe také odhalit chybu v procesu zpracování na straně banky. Systém bude nastaven tak, aby automaticky detekoval moţné duplicity. Jako duplicitní budou označeny platební příkazy, kde je shodné číslo účtu plátce, číslo účtu příjemce, částka a datum splatnosti. Pokud je dávka ve stavu „Duplicitní dokumenty“, musí operátor zahájit proces řešení duplicit. Dvojitým kliknutím na takto označenou dávku se mu otevře prohlíţeč duplicit, kde se zobrazí k posouzení platební příkazy systémem označené jako duplicitní. V tomto prohlíţeči uvidí dva nebo více dokumentů, které systém povaţuje za duplicitní. Operátor můţe například podle hodnoty v AV poli, které systém nijak nevyhodnocuje, rozpoznat, ţe klient zadal dva téměř shodné platební příkazy úmyslně a o duplicitu se nejedná, nebo ţádnou rozdílnost nenajde a musí se dále rozhodnout, jak s příkazy naloţí. Operátor bude mít k dispozici následující volby: -

Duplicitní dokumenty – tím pracovník potvrdí, ţe se skutečně jedná o duplicitu. Pokud některý z těchto příkazů jiţ byl odeslán k dalšímu zpracování (v jiné dávce), bude příkaz z aktuálně zpracovávané dávky zařazen k archivaci a dále zpracováván nebude. Jiţ odeslaný dokument bude ponechán ve standardním zpracování. Pokud se dva nebo více duplicitních dokumentů nachází v jedné dávce, je k dalšímu zpracování zařazen první naskenovaný z těchto dokumentů, ostatní jsou zařazeny k archivaci a dále zpracovávány nejsou.

-

Různé dokumenty – tím pracovník potvrdí, ţe se nejedná o duplicitu a k dalšímu zpracování jsou postoupeny oba nebo více dokumentů zařazených na kontrolu duplicit.

-

Nechat nerozhodnuté – operátor si není jistý, ponechá dokumenty nerozhodnuté, dokud nezjistí, například telefonátem klientovi, k platebním příkazům dostatek informací, aby mohl správně rozhodnout. 43

Dávka zůstává ve stavu „Duplicitní“ aţ do vyřešení všech duplicit v této dávce. Potom je celá exportována k dalšímu zpracování backendovými systémy.

3.1.9 Archivace Archivace je poslední činnost, která je s platebními příkazy prováděna. Tato činnost je jednodušší v tom, ţe zde jiţ nejsou prováděny ţádné kontroly. Proto probíhá plně automaticky, zato je náročná na datový prostor, jelikoţ do archivu kaţdý den přibývá velké mnoţství údajů. Zároveň pokud je potřeba v elektronickém archivu nějaká data vyhledat, je to činnost velmi náročná na výpočetní výkon systému. Všechny platební příkazy, které prošly zpracováním, musí být uloţeny do elektronického archivu, včetně těch, které byly naskenovány, ale později byly vyřazeny ze zpracování. V takovém případě musí být u příkazu jasně uvedeno, z jakého důvodu k vyřazení došlo. Elektronický archiv je zaloţený na internetové technologii umoţňující přistupovat oprávněným osobám k dokumentům z libovolného místa v bance, za pouţití standardního intranetového připojení, bez nutnosti instalace klientské aplikace. Toto má pozitivní přínos v úspoře nákladů na administraci systému. Není nutné instalovat ţádné dodatečné komponenty, ani dělat speciální nastavení internetového prohlíţeče. V případě potřeby by bylo moţné vyuţít i zabezpečeného protokolu https://, ale to nepovaţuji ve vnitřním prostředí banky za nutné, neboť by to zvyšovalo objem přenesených dat. V elektronickém archivu musí být umoţněno pokročilé vyhledávání, aby se uţivatelům nabízely pouze relevantní údaje. Při očekávaném zpracování 10 000 platebních příkazů denně, tedy přibliţně 2 600 000 platebních příkazů ročně, je velká pravděpodobnost, ţe při zadání jednoho čísla účtu se po vyhledání nabídne velká mnoţina odpovídajících záznamů. Proto je ţádoucí, aby bylo moţné vyhledávat podle následujících údajů: částka měna datum splatnosti datum podání příkazu číslo účtu plátce číslo účtu příjemce jednotlivý příkaz k úhradě hromadný příkaz k úhradě 44

příkaz k inkasu Tyto hodnoty musí být navzájem kombinovatelné, aby jejich vyplněním mohlo dojít k jednoznačné identifikaci platebního příkazu. Pro potřeby interního vyhledávání musí být umoţněno i vyhledávání podle jednoznačného identifikátoru, který tiskne na platební příkaz skener v průběhu zpracování. Totoţný identifikační údaj je automaticky přiřazen k elektronické podobě platebního příkazu a datové větě vytěţené z tohoto příkazu. Při vyhledání platebního příkazu musí mít uţivatel moţnost vidět všechny stavy, kterými platební příkaz prošel. To znamená hodnoty, které byly při naskenování rozpoznány, případně jak byly v průběhu zpracování měněny hodnoty v jednotlivých polích a také elektronická podoba platebního příkazu. Zároveň musí být zobrazen finální stav zpracování platebního příkazu. Jednotlivé fáze zpracování budou zobrazeny na samostatných stránkách internetového prohlíţeče. Na první stránce bude zobrazeno to, co bylo rozpoznáno skenerem, na druhé to, co bylo změněno během korekce, na třetí to, co bylo změněno během verifikace. V kroku, kdy došlo k nějaké změně, bude zvýrazněna hodnota, která byla měněna. Pokud je příkaz úspěšně zpracován aplikací na rozpoznání kontroly platebního příkazu, ale je shledána nějaká nesrovnalost v návazných bankovních systémech, musí toto být také zaevidováno v elektronickém archivu, aby v případě reklamace pracovník reklamačního oddělení měl maximální moţnost poskytnout klientovi relevantní informace o stavu jeho příkazu. Z toho důvodu musí být komunikace mezi systémy oboustranná. V archivu musí být uvedeno, v případě neúspěšného zpracování v návazných platebních systémech, nejen v jakém systému byla shledána chyba, ale i identifikace chyby, například „Typ debetního účtu není vhodný pro danou platební operaci“. Tato chyba můţe nastat, pokud klient zadá příkaz k úhradě ze svého spořícího účtu, ze kterého není povolen tento typ transakce. Pracovník reklamačního oddělení musí mít moţnost tuto informaci klientovi poskytnout. V archivu se musí zobrazit i takzvané pasivní dokumenty. Jsou to dokumenty, které prošly zpracováním jinou cestou a naskenovány byly výhradně kvůli tomu, aby byly dohledatelné v elektronickém archivu.

45

Hlavní úlohou systému GArchive je slouţit jako archiv elektronických, papírových (naskenovaných) dokumentů, coţ umoţní nejen sdílení dokumentů v rámci banky, ale hlavně jednoduché a rychlé vyhledávání dokumentů na základě poţadovaných kritérií a jejich zobrazení v internetovém prohlíţeči. Základní vlastnosti systému: jednoduché a přehledné uţivatelské prostředí vytvoření centrálního úloţiště naskenovaných dokumentů, archivace a správa dokumentů, popis dokumentů pomocí indexů (profil dokumentu) vyhledávání dokumentů podle vybraných indexů (číslo účtu, suma a podobně) vestavěný prohlíţeč dokumentů umoţňuje zobrazovat vyhledané dokumenty v interním prohlíţeči pro standardní příkazy se zobrazí i popisky polí (na původním formuláři byly odfiltrovány, ale GArchive tyto popisky doplní) správa nezpracovaných platebních příkazů umoţňující kompletní řazení jejich zobrazení pomocí dynamických adresářů umoţní nastavovat sofistikovaná přístupová práva k dokumentům umoţní sledovat historii přístupu k jednotlivým dokumentům vytváření skupin dokumentů (sloţky), případně jejich sdruţování na základě určitých kritérií (dynamické sloţky) moţnost provázání dokumentů přes tzv. související dokumenty Systém GArchive má zabudovaný interní prohlíţeč dokumentů, který umoţňuje prohlíţet dokumenty bez potřeby otvírat externí aplikace. Interní prohlíţeč dokumentů nebude vyţadovat ţádné speciální nastavení internetového prohlíţeče, ani doinstalování nějakých speciálních komponent. Pro naskenované dokumenty (formát TIFF, JPG) budou k dispozici funkce na zvětšování a zmenšování dokumentů, stránkování a podobně.

46

Obr. 8 – Vzor naskenovaného hromadného příkazu k úhradě

Zdroj: Vlastní tvorba, pilotní provoz systému.

Systém GArchive nebude zabezpečovat tisk obsahu dokumentů, které jsou v něm uloţené. Vzhledem k pouţití tzv. tenkého klienta je však moţné vytisknout obsah dokumentu pomocí funkcí samotného internetového prohlíţeče. Tenký klient je pouhý zobrazovač výsledků nebo informací, které uţivatel od systému poţaduje. Všechny výpočetní operace probíhají na straně serveru. Typický tenký klient je

47

webový prohlíţeč. Uţivatel zadá dotaz, Tento dotaz je zpracován na straně serveru a následně zobrazen uţivateli na obrazovce v tenkém klientu. Opak tenkého klienta - tlustý klient provádí výpočetní operace nebo jejich část a vzdálený server vyuţívá například jako sdílené úloţiště dat. Příkladem tlustého klienta můţe být MS Outlook nebo jiný poštovní klient.

3.1.10 Distribuce dat Data musí být distribuována nejen v rámci aplikace pro elektronické zpracování platebních příkazů, ale také mezi jednotlivými bankovními systémy. Distribuce dat bude probíhat automaticky, podle předem nastavených parametrů a uţivatel nebude mít moţnost tuto komunikaci nijak ovlivnit.

3.1.11 Distribuce dat v rámci aplikace V rámci aplikace nedochází k fyzickému předávání dat. Data budou uloţena v databázi, do které budou mít jednotlivé komponenty přístup. Způsob přístupu bude definován v rámci databázových uţivatelských rolí, které budou děleny na role aplikační a uţivatelské. Tím bude zajištěno, ţe kaţdá změna v datech bude dohledatelná a bude moţné vysledovat, kdo a kdy změnu provedl. Toto je nutné nejen pro řešení případných reklamací, ale je to jeden ze základních bezpečnostních a auditních poţadavků.

3.1.12 Distribuce dat v rámci banky Data musí být po všech kontrolách odeslána do navazujících bankovních systémů k dalšímu zpracování. Jako komunikační kanál bude pouţit standardní bankovní backbone kanál, to znamená páteřní síťové propojení, v tomto případě nazývaný T-Hub. V případně nedostupnosti některého z návazných systémů nebo backbone kanálu nesmí dojít ke ztrátě ţádných dat. Data, která se nepodařilo odeslat, si ponesou příznak o neúspěšné komunikaci a po obnovení dostupnosti cílového systému budou znovu odeslána. Po potvrzení přijetí bude příznak o neúspěšném odeslání smazán. Data jsou odesílána nejen za účelem vypořádání platebních příkazů, ale i ke statistickým účelům nebo stanovení behaviárního skóre klientů a od toho odvozených sluţeb a nabídek.

48

Data určená k vypořádání platebních příkazů budou odesílána v reálném čase tak, aby nedošlo k prodlení při jejich zpracování. Data pro statistické účely budou odesílána mimo pracovní dobu klientských přepáţek, případně budou mít statistické aplikace umoţněný přístup do aplikační databáze a načtou si potřebná data v rámci svého nočního zpracování. Obr. 9 - Nákres rozhraní datového toku: CMDB

M24 Web Services T-Hub

M24sk

PayScan

Zdroj: Vlastní tvorba

3.1.13 Popis rozhraní Aplikace komunikuje s ostatními systémy banky pomocí páteřního kanálu T-Hub. T-Hub distribuuje podle typu zpráv jednotlivé zprávy na místo určení. Všechny zprávy jsou ukládány do centrální databáze CMDB a pokud se nejedná o pasivní nebo konverzní transakce jsou distribuovány do návazných backendových – transakčních – systémů. Z obrázku č. 9 je patrné, ţe se zpracování dělí na M24 a M24sk. To znamená, ţe jsou oddělovány zprávy pro Českou a Slovenskou republiku. V centrální databázi jsou evidovány všechny transakce. K dělení na Českou a Slovenskou měnu dochází z důvodu rozdílných domácích měn v obou zemích.

49

3.1.14 Kontroly Aplikace PayScan má standardně implementované následující validační kontroly: modulo 11 v čísle účtu příjemce (modulo je početní operace související s operací celočíselného dělení. Například 7 / 3 = 2 se zbytkem 1. Také můţeme říci, ţe 7 modulo 3 = 112) modulo 11 v čísle účtu plátce kontrola na číselník bank – centrálně zpracovávaný bankovní číselník kontrola na celkový součet částek v případě hromadného platebního příkazu kontrola na číselník nepovolených konstantních symbolů kontrola na vyplnění numerických polí alfabetickými znaky kontrola na číselník měn kontrola na neexistující datum splatnosti kontrola na povinně vyplněná pole Následné kontroly jsou ponechány na standardních bankovních systémech, které jiţ mají systém kontrol vybudovaný a je parametrizovatelný pomocí centrálně udrţovaných bankovních číselníků. Replikace těchto číselníků není ţádoucí, proto nemohou být tyto kontroly na straně aplikace prováděny.

12

Wikipeida

[online].

9.3.2011

[cit.

2011-03-18].

.

50

Zbytek

po

dělení.

Dostupné

z

WWW:

4 Závěr Vývoj nového bankovního systému patří k úkolům, které jsou náročné, protoţe jejich úkolem je zpracování velkého mnoţství dat a zacházení s finančními prostředky klientů. Proto zde musí být implementovány kontroly a postupy, které eliminují riziko vzniku chyby na minimum. Úkolem navrhovaného systému je zefektivnit zpracování papírových platebních příkazů. Pokud by se toto nepovedlo, práce se systémem by byla náročná, rozpoznání hodnot by bylo málo úspěšné a nutnost kontrol prováděných operátory by byla vysoká. Znamenalo by to, ţe projekt se nepovedl a investici by bylo nutné odepsat. Digitalizace papírových platebních příkazů pomocí jejich skenování oproti dosavadnímu manuálnímu přetypování je výrazným usnadněním a urychlením práce. Během zpracování uţ nebude muset být fyzicky kontrolován kaţdý platební příkaz tak jako dosud, ale jen obtíţně rozpoznatelné příkazy nebo příkazy, u kterých verifikační parametry nařizují kontrolu pracovníkem oddělení zpracování. Proces zpracování platebních příkazů, které splňují parametry na automatické kontroly, bez zásahu operátora, přináší zásadní milník do zpracování papírových platebních příkazů. To, ţe bude takový příkaz doručen bankovním svozem, ze vzdálených lokací Českou poštou nebo v případě urgentních příkazů faxem na skenovací pracoviště, kde je bez jakýchkoli zdlouhavých manuálních kontrol předán k naskenování a poté předán k archivaci, přinese značnou úsporu času, aniţ by tím jakkoli utrpěla kvalita zpracovaných dat nebo jejich kontrol. Podle měření prováděných v průběhu pilotního provozu aplikace došlo k zrychlení zpracování o 15%. Po nasazení do rutinního provozu a zmírnění verifikačních parametrů (vynucené kontroly budou u příkazů podaných na vyšší částky neţ dosud), očekávám další nárůst rychlosti zpracování oproti manuálnímu a to na 20% aţ 25%. Systém automaticky detekuje duplicity ve zpracovávaných platebních příkazech, coţ při manuálním zpracování příkazů nebylo moţné, zvláště byl-li shodou okolností zpracován jeden příkaz více pracovníky. Nyní budou veškeré duplicitně podané platební příkazy nebo příkazy téměř shodné, a tedy z duplicitního podání podezřelé, systémem zachyceny a 51

pracovníci budou muset provést manuální ověření. Duplicitně podaný příkaz bude pracovníky ze zpracování vyřazen. Tato funkcionalita sníţí počet klienty podaných reklamací, coţ přinese pozitivní dopad i na pracovníky back office a reklamačního oddělení, kteří se systémem zpracování platebních příkazů primárně nepracují. Elektronický archiv, který umoţňuje vytváření dynamických sloţek přesně dle potřeb pracovníků je také významným prostředkem pro zkvalitnění a zefektivnění provádění pracovních činností. Kaţdý pracovník, který údaje v archivu vyhledává, si můţe vytvořit své vlastní sloţky, nebo vyuţít sloţek sdílených s kolegy a tím mít data kdykoli přístupná s minimálním úsilím a vysokou kvalitou. Tím, ţe je v maximální moţné míře vyuţito existujících komponent, aplikací a infrastruktury banky, očekávám snadnou integraci navrhovaného řešení do stávajícího prostředí banky a omezení nutných nákladů na nejniţší moţnou míru. Jedním z moţných rizik je niţší úspěšnost rozpoznání ručně psaných nebo nestandardních platebních příkazů oproti standardním. Bohuţel mezi klienty je rozšířeno stále velké mnoţství starších typů platebních příkazů, které aplikace nebude umět optimálně zpracovat. Z tohoto důvodu je třeba motivovat klienty k pouţívání aktuálních vzorů platebních příkazů, jejichţ vzory jsou v aplikaci implementovány. Tím se zvyšuje kvalita zpracovaných dat a rychlost zpracování. Pouţívání zastaralých vzorů by mělo být například zatíţeno poplatkem za zpracování, aby klienti měli zájem pouţívat předtištěné platební příkazy, se kterými umí systém pro zpracování platebních příkazů pracovat. Toto musí být řešeno metodickým pokynem a také to musí být s klienty citlivě komunikováno pomocí PR oddělení tak, aby klienti nevnímali takový krok negativně, ale jako snahu o zkvalitnění sluţeb, které banka svým klientům poskytuje. Zavádění moderních technologií v poskytování sluţeb klientů je ţádoucí a je vţdy veřejností pozitivně vnímáno. Sluţba elektronického zpracování papírových platebních příkazů je vhodná i pro klienty, kteří nechtějí omezit osobní styk na „své“ přepáţce pobočky banky, kde platební příkazy předají tak, jak jsou zvyklí, ale tyto příkazy budou dále zpracovány moderním a kvalitnějším způsobem. Cílem práce byl návrh komplexního řešení zpracování papírových platebních příkazů elektronicky. Tento cíl se podařilo naplnit.

52

5 Použitá literatura [1] Functional Specification ČSOB – autor: Lloyd Hand [2] Závazné zadanie PayScan – autor: Gradient Slovakia s.r.o [3] Česká republika. Zákon o platebním styku. In ZÁKON č. 284/2009 Sb., o platebním styku . 2009, s. 1-58. [4] Česká republika. Vyhláška 62/2004 Sb., kterou se stanoví způsob provádění platebního styku mezi bankami, zúčtování na účtech u bank a technické postupy bank při opravném zúčtování. In Sbírka zákonů ČR. 2004, 20, s. 911 - 920. Dostupný také z WWW: . [5] ČNB [online]. 2003 [cit. 2011-04-11]. Často kladené dotazy. Dostupné z WWW: .. [6] SCHLOSSBERGER, Otakar; SOLDÁNOVÁ, Marcela. Platební styk. 3., přeprac. a dopl. vyd. Praha : Bankovní institut vysoká škola, 2007. 435 s. ISBN 978-80-7265-107-8. [7] FERILLI, Stefano. Automatic Digital Document Processing and Management. 1st Edition. Bari, Italy : Springer, 2011. 295 s. ISBN 978-0-85729-197-4. [8] LIU, Yingming; CHEN, Guoqin; YING, Mingsheng. Fuzzy Logic, Soft Computing and Cumputational Intelligence. Bejing, China : Tsinghua University Press, 2005. Signal/Image Processing & Pattern Recognition, s. 979-981. ISBN 7-302-11377-7/TP-7494. [9] Oracle Česká republika [online]. 2011 [cit. 2011-04-17]. Oracle. Dostupné z WWW: . [10] Dokumentové skenery [online]. 2009 [cit. 2011-04-17]. Scanservice. Dostupné z WWW: . [11] Wikipeida [online]. 9.3.2011 [cit. 2011-03-18]. Zbytek po dělení. Dostupné z WWW: .

53

Seznam příloh Příloha 1

Seznam zkratek

Příloha 2

Popis scanneru Kodak i1800

Příloha 3

Popis scanneru Kodak i1220

Příloha 4

Vzor standardního platebního příkazu

Příloha 5

Vzor nestandardního platebního příkazu

54

Příloha 1 Seznam použitých zkratek CDS

- Centrální Datový Sklad

CMDB

- Configuration Management Database – konfigurační databáze

ČNB

- Česká národní banka

ČR

– Česká republika

ČSOB

- Československá obchodní banka

EDI

- Electronic Data Ingerchange – Elektronická výměna dat

ISO

- International Organization for Standardization - Mezinárodni

organizace pro normy IT

- Informační Technologie

OLTP

- Online Transaction Processing – Online zpracování dat

OCR

- Optical Character Recognition – Optické rozpoznávání znaků

SIPO

- Soustředěné inkaso plateb obyvatelstva

UN/EDIFACT - United Nations/Electronic Data Interchange For Administration, Commerce, and Transport – Spojené národy/Elektronická výměna dat pro administrativu, obchod a transportní sluţby

1

Příloha 2 Popis scanneru Kodak i1800

Zdroj: scanservice a.s. http://www.scanservice.cz/produkty/dokumentove-skenery/

Doporučený denní objem neomezený Rychlost skenování (A4 na šířku, při 200 dpi) Aţ 200 stran za minutu (800 obrazů za minutu) Optické rozlišení 300 dpi Rozlišení na výstupu ČB: 200/240/300/400 dpi Barva/Stupně šedi: 100/150/200/240/300 dpi Maximální velikost dokumentu 305 mm x 863 mm (12 in. x 34 in.) Minimální velikost dokumentu 64 mm x 64 mm (2.5 in. x 2.5 in.) Tloušťka a hmotnost papíru Standardní podavač: 45 g/m² aţ 200 g/m²

2

Ultra-lehký podavač: 25 g/m² aţ 75 g/m² Podavač Kapacita 500 listů Detekce vícenásobného podání Ultrazvuková technologie; tři ultrazvukové senzory fungují společně i nezávisle na sobě Konektivita IEEE-1394 ( FIREWIRE ) rozhraní, 6 pinový konektor; včetně karty IEEE-1394 a kabelu Imagingové funkce (přímo ve skeneru) Perfect Page Scanning iThresholding autocrop aggressive crop deskew image rotation electronic color dropout dual stream scanning halftone removal noise removal zone processing toggle patch automatic color detection Formát výstupního souboru JPEG (pro obrázky barevné a ve stupních šedi) TIFF (pro ČB obrázky) Faktory pro ochranu životního prostředí Bez pouţití olova Slučitelné s Energy Star

3

Slučitelné se standardem 508 Xenonové bezrtuťové lampy Provozní teplota: 15–35° C (59–95° F) Provozní vlhkost: 15 aţ 76 % rel. vlhkost Spotřeba energie 190 - 260 W; Energy Star: <6 W Příslušenství Tiskárna s vysokým rozlišením Příslušenství pro bílé pozadí Manuální podavač Rozměry Váha: 218 kg (480 lb.) Hloubka: 99 cm (39 in.) Šířka (závisí na postavení dotekového monitoru): 78 cm–83 cm (31 in.–33 in.) Výška (nastavitelná): 102 cm–127 cm (40 in.–50 in.) Zdroj: scanservice a.s. http://www.scanservice.cz/produkty/dokumentove-skenery/ [cit, 17.4.2011]

4

Příloha 3 Popis scanneru Kodak i1220

Zdroj: scanservice a.s. http://www.scanservice.cz/produkty/dokumentove-skenery/

Doporučený denní objem Aţ 3000 listů denně Rychlosti skenování: (A4 na výšku, ČB/ve stupních šedi/barevné) Aţ 45 listů za minutu (i1210 jednostranně, i1220 oboustranně) při 200 DPI. Skenovací technologie Single CCD (i1210) Dual CCD (i1220) Bitová výstupní hloubka odstínů šedé je 256 stupňů (8 bitů) Barevná hloubka snímání je 48 bitů (16 x 3) Výstupní barevná hloubka je 24 bitů (8 x 3) Optické rozlišení 600 dpi (i1210, i1220), 1200 dpi (A4 volitelné ploché loţe) Osvětlení duální fluorescentní lampa (studená katoda) Rozlišení na výstupu 75,100,150, 200, 240, 300, 400, 600 a 1200 dpi

5

Maximální velikost dokumentu 215 mm x 863 mm (8,5 in. x 34 in.) Minimální velikost dokumentu 50 mm x 63,5 mm (2.0 in. x 2.5 in.) Tloušťka a hmotnost papíru Od nejtenčího „průklepáku“ aţ po karton Podavač Automatický podavač dokumentů pro kontinuální skenování Kapacita aţ 50 listů Detekce vícenásobného podání ultrazvuková technologie Konektivita USB 2.0 Zdroj: scanservice a.s. http://www.scanservice.cz/produkty/dokumentove-skenery/ [cit, 17.4.2011]

6

Příloha 4 Vzor standardního platebního příkazu

Zdroj: Vlastní tvorba, pilotní provoz systému.

7

Příloha 5 Vzor nestandardního platebního příkazu

Zdroj: Vlastní tvorba, pilotní provoz systému.

8