Zpracování finančních dokladů formou outsourcingu

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Zpracování finančních dokladů formou outsourcingu Diplomová práce Autor: Bc. Radan Miksa Ekonomika a management, ITMK Vedoucí práce: Doc. Ing. Bohumil Miniberger, CSc. Praha Duben 2013 1

Prohlášení Prohlašuji, že jsem diplomovou 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 Jesenici dne Radan Miksa 2

Poděkování Rád bych na úvod své diplomové práce vřele poděkoval vedoucímu práce Doc. Ing. Bohumilu Minibergerovi, CSc. za vedení, věcné připomínky, poskytnuté konzultace a trpělivost. V neposlední řadě bych také rád poděkoval své rodině a společnostem Syconix, a.s., XEROX CZECH REPUBLIC s.r.o. a Océ-Česká republika, s.r.o. za podporu během celého mého studia. 3

Anotace Diplomová práce je zaměřena na procesní stránku outsourcingu zpracování finančních dokladů, a z hlediska technologického jej popisuje v teoretické rovině. Pro větší srozumitelnost je základem vzorová implementace této služby v imaginární společnosti. Při tvorbě diplomové práce jsem vycházel především ze svých mnohaletých pracovních zkušeností v tomto oboru, a to jak implementačních, tak i provozních. Cílem této práce je poskytnout vhodný materiál pro společnosti, které o službě outsourcingu uvažují, ale nedokáží si ji představit v praxi. Klíčová slova Outsourcing, finanční doklady, proces, digitalizace, vytěžování dat Annotation The thesis focuses on the procedural side of outsourcing financial documentation processing and describes it theoretically from the technological perspective. A model implementation in an imaginary company is provided in order to illustrate the theory comprehensively. I drew upon my extensive experience in implementation and operation in this field while writing this thesis. The aim of it is to provide suitable material to companies which are thinking about outsourcing but are not able to envision its implication in practice. Key words Outsourcing, financial documents, process, digitisation, data extraction 4

Obsah 1 Úvod... 9 2 Outsourcing a princip jeho využití... 10 2.1 Pojem outsourcing... 10 2.2 Proč outsourcing... 10 2.3 Outsourcing v oblasti digitalizace... 11 2.4 Service Level Agreement (SLA)... 12 3 Finanční doklady vhodné k outsourcingu zpracování... 13 3.1 Právní náležitosti faktury... 13 4 Úroveň poskytování služby... 15 4.1 Základní scénář zpracování... 15 5 Stručný popis střediska... 16 5.1 Pracoviště přípravy... 16 5.1.1 Čárové kódy... 17 5.1.2 Typy čárových kódů... 17 5.2 Skenovací pracoviště... 18 5.3 Pracoviště validace... 18 5.4 Pracoviště zpětné kompletace... 19 5.5 Pracoviště archivace... 19 6 Programové a technické vybavení... 22 6.1 Hardware... 22 6.1.1 Skenery třídy Desktop... 23 6.1.2 Skenery třídy Workgroup... 24 6.1.3 Skenery třídy Production... 24 6.2 Software... 25 6.2.1 Optimalizace naskenovaného obrazu... 25 6.2.2 Automatické vytěžení údajů... 26 6.2.3 Kofax Capture... 27 6.2.4 Kofax Transformation Modules... 28 6.3 Regulární výrazy... 30 6.4 Lidské zdroje... 32 6.4.1 Site manager... 32 6.4.2 Vedoucí jednotlivých pracovišť... 32 5

7 Rozbor procesu zpracování... 33 7.1 Příjem zásilek... 34 7.2 Příprava finančních dokladů... 34 7.3 Skenovaní finančních dokladů... 34 7.4 OCR... 34 7.4.1 Identifikace dodavatele... 37 7.4.2 Částky na finančních dokladech... 37 7.4.3 Vyhledávání datumů... 38 7.4.4 Typ dokladu... 39 7.5 Validace... 39 7.6 Tvorba PDF... 40 7.7 Export dat... 41 7.8 Předání zákazníkovi... 42 8 Vzorová implementace... 43 8.1 Charakteristika zákazníka... 43 8.2 Analýza současného stavu (AS-IS)... 46 8.2.1 Zpracování faktur... 46 8.2.2 Kontrola formálních náležitostí faktury... 46 8.2.3 Předběžné pořízení faktury... 47 8.2.4 Fyzická archivace... 47 8.3 Analýza požadovaného stavu (TO-BE) a návrh implementace... 48 8.4 Detailní popis procesu TO-BE... 49 8.4.1 Převzetí dokumentů... 49 8.4.2 Separace dokumentů... 49 8.4.3 Skenování dokladů... 50 8.4.4 Rozpoznání dat... 51 8.4.5 Databáze dodavatelů... 51 8.4.6 Rozpoznávaná pole a jejich definice... 52 8.4.7 Číselníky použité při vytěžování... 53 8.4.8 Kontrola dat validace... 54 8.4.9 Formát předávání metadat a naskenovaných obrazů... 55 8.4.10 Odesílání a přijímání dat... 55 8.4.11 Archivace dokladů... 56 6

8.4.12 Správa dokumentů... 56 8.4.13 Skartace dokladů... 56 8.5 Časový harmonogram... 57 8.6 Reporting... 58 8.6.1 Přehled zpracovaných materiálových dokladů... 58 8.6.2 Přehled zpracovaných režijních dokladů... 58 8.6.3 Přehled zpracovaných jiných dokumentů... 59 8.6.4 Přehled skartovaných dokladů... 59 8.6.5 Přehled reklamací... 59 8.7 Zabezpečení dat... 60 8.7.1 Zálohování dat... 60 8.7.2 Automatická skartace dat... 60 8.8 Zabezpečení sdíleného střediska... 60 8.8.1 Kamerový systém... 61 8.8.2 Docházkový systém... 61 8.8.3 Zabezpečovací a požární systém... 61 9 Návrh SLA... 63 9.1 Parametry pro provoz... 63 9.2 Chybovost zpracování... 63 9.2.1 Parametry kvality a chybovosti... 63 9.2.2 Způsob hodnocení... 65 9.3 Penalizační model... 65 9.3.1 Ocenění penalizačních stupňů... 65 9.3.2 Omezení smluvních pokut... 66 9.3.3 Omezení SLA pro pilotní provoz... 66 10 Závěry a doporučení... 67 11 Seznam použité literatury... 68 11.1 Tištěné monografie... 68 11.2 Elektronické monografie, webovská sídla, databáze a počítačové programy. 68 12 Definice pojmů a zkratek... 70 13 Seznam použitých tabulek, schémat, obrázků, grafů a příloh... 72 13.1 Seznam použitých tabulek... 72 13.2 Seznam použitých schémat... 72 7

13.3 Seznam použitých obrázků... 72 13.4 Seznam použitých grafů... 73 13.5 Seznam příloh... 73 8

1 Úvod Během své praxe se dennodenně setkávám s řadou společností uvažujících o outsourcingu zpracování svých finančních dokladů. Pro většinu z nich se jedná o podpůrnou činnost, která je velmi zatěžuje jak zdrojově tak i finančně. Bez této činnosti nemohou fungovat a nutí je tříštit síly a díky tomu se nemohou v plné míře soustředit na svůj hlavní obor podnikání. Řešení se zde jednoznačně nabízí. Svěřme tuto činnost partnerovi, který nám vše zajistí formou externí služby, tedy formou outsourcingu. Myšlenka dobrá, nicméně hned vzápětí se dostaví řada otázek a nejasností týkajících se bezpečnosti, kvality, flexibility a finanční výhodnosti tohoto řešení. Ve své diplomové práci se pokusím na všechny tyto otázky a nejasnosti odpovědět a přesvědčit čtenáře, že outsourcing zpracování finančních dokladů je pro ně to správné řešení. Cílem diplomové práce je aplikovat získané teoretické poznatky při vzorové implementaci této služby, a tímto danou problematiku ještě více čtenářům přiblížit. Diplomová práce je rozdělena na dva základní bloky. První část práce je zaměřena více na teoretickou stránku věci. Druhá část je zaměřena na reálnou implementaci vzorové společnosti včetně analýzy AS-IS 1 a TO-BE 2 a návrhu SLA 3. Nejrozsáhlejším podkladem pro vypracování diplomové práce byly mé dosavadní zkušenosti z tohoto oboru, kterému se věnuji bez přestávky téměř deset let. Svou praxi jsem začínal na úrovni technického konzultanta implementujícího systémy pro digitalizaci a extrakci dat. Následně jsem se posunul do roviny analytické a konzultační a v současné době se tomuto oboru věnuji v pozici řídícího pracovníka majícího na starost právě provoz outsourcingu zpracování. Finanční doklady jsem během své praxe zpracovával pro řadu společností včetně předních finančních institucí, předních konzultačních společností a mnoho výrobních podniků. V portfoliu nebyly pouze české společnosti, ale i řada zahraničních subjektů. Outsourcingu zpracování finančních dokladů jsem se již věnoval ve své bakalářské práci. Diplomová práce na tuto práci navazuje a rozšiřuje ji především o reálnou implementaci vzorové společnosti. 1 AS-IS současný stav 2 TO-BE budoucí neboli cílový stav 3 SLA Service Level Agreement 9

2 Outsourcing a princip jeho využití Outsourcing jako pojem je velice obsáhlý. V této kapitole je popsán velmi stručně s ohledem na téma této práce. Kapitola je kompletně zpracována dle Brucknera a Voříška [1]. 2.1 Pojem outsourcing Outsourcing pochází z americké obchodní angličtiny. Český ekvivalent neexistuje, jen občas je využíván opis využívání externích služeb. Každý podnik využívá pro svou činnost řadu zdrojů, které na základě své potřeby a legislativy obhospodařuje tak, aby byly pro jeho činnost prospěšné. Aby poskytovaly své vstupy včas a v odpovídající kvalitě a kvantitě. Stav, kdy požadované vstupy společnost koupí od jiného subjektu jako službu, je nazýván outsourcing. Tím se zbaví nutnosti vlastní zdroj obhospodařovat. Podnik takto v podstatě od sebe zdroj odsune (out) a vloží mezi sebe a zdroj jiný subjekt, který daný zdroj obhospodařuje. Outsourcingem je označován stav, činnost k tomuto stavu vedoucí a také permanentní činnost, která tento stav udržuje. Opačným stavem outsourcingu je insourcing. Insourcing je stav, kdy podnik obhospodařuje zdroj svými vlastními silami. Tento pojem může být někdy i zúžen na stav, kdy podnik obhospodařuje zdroj interně. Zčásti jej využívá pro své interní potřeby a zčásti je poskytuje i jiným subjektům. 2.2 Proč outsourcing Základním předpokladem úspěšného projektu outsourcingu je přesné stanovení cílů podniku. Důvody vedoucí k outsourcingu lze shrnout do čtyř základních skupin (viz obrázek 1): konkurenční, věcná, finanční, organizační. 10

Obrázek 1 - Původ důvodů pro outsourcing Zdroj: Bruckner a Voříšek, 1998 [1] Zajímavé je porovnat čtyři hlavní důvody s průzkumem trhu v roce 2010 provedeným společností AIIM v oblasti digitalizace dokumentů a vytěžování dat [4]. Nejvíce společností jako důvod uvedlo snížení nákladů, tedy důvod finanční, těsně následován možností se soustředit na hlavní činnost podniku, tedy důvod konkurenční. Další důvody jsou znázorněny v následujícím grafu 1. Graf 1 Proč společnosti volí outsourcing digitalizace dokumentů Zdroj: AIIM, 2010 [4] 2.3 Outsourcing v oblasti digitalizace Outsourcing v oblasti digitalizace a vytěžování dat v poslední době hodně roste. Je to hlavně spojené s výrazným zlepšením v oblasti internetu, především rychlosti, kdy je možné i velké objemy dat přenášet mezi sdílenými středisky a zákazníkem [4]. Dle výzkumu společnosti AIIM provedeném v roce 2010 [4] stále převažuje outsourcing pouze digitalizace bez následného vytěžení dat (viz graf 2). 11

Graf 2 - Předmět outsourcingu v oblasti digitalizace Zdroj: AIIM, 2010 [4] 2.4 Service Level Agreement (SLA) Dokument SLA by měl být strukturován tak, aby motivoval obě smluvní strany k rozvoji a vzájemné podpoře. Často se v literatuře setkáváme s pojmem win-win agreement, který v podstatě znamená, že oba partneři by měli těžit ze vzájemné spolupráce. Díky synergickému efektu plynoucímu ze strategického partnerství je tak možné dosahovat vyšší produktivity a těžit z větší konkurenceschopnosti na dnešním globalizujícím se trhu. [7] SLA patří mezi nejdůležitější body procesu outsourcingu. Je velmi důležitým nástrojem k eliminaci nevýhod outsourcingu IT, a proto by mu měla být věnována zvláštní pozornost managementu obou budoucích smluvních partnerů. [7] 12

3 Finanční doklady vhodné k outsourcingu zpracování Cílem této kapitoly je vymezit zpracovávané finanční doklady ze všech finančních dokladů. Finanční doklady lze rozdělit z hlediska zpracování na dvě skupiny. Jednou skupinou jsou finanční doklady vytvořené v dané společnosti a druhou skupinou jsou finanční doklady přijaté, tzn. vytvořené mimo prostředí dané společnosti. Do první skupiny lze zařadit faktury vydané, různé finanční výkazy, rozvahy a jiné. Do druhé skupiny naopak patří faktury přijaté, dobropisy přijaté, upomínky atd. Předmětem zpracování ve sdíleném středisku jsou finanční doklady druhé skupiny. Typy, které jsou zpracovávány, jsou vždy vymezeny smlouvou. Zpravidla se ale se zpracovávají pouze faktury přijaté a dobropisy přijaté. V této bakalářské práci je kladen důraz na zpracování faktur přijatých. Faktura je finanční doklad, kterým jedna společnost neboli dodavatel, nárokuje finanční odměnu za dodané zboží či služby po společnosti druhé neboli odběrateli. Přesná podoba faktury není v zákoně zakotvena, a tudíž její vzhled není jednotný. V zákoně jsou stanoveny pouze údaje, které musí faktura obsahovat. Tato skutečnost je uvedena v zákoně o dani z přidané hodnoty č.235/2004 Sb. a v zákoně o účetnictví č.563/1991sb. [12] 3.1 Právní náležitosti faktury Podle Ministerstva Financí ČR [12], faktura musí obsahovat: dodavatele včetně jeho adresy, DIČ dodavatele či odběratele odběratele včetně jeho adresy, datum vystavení faktury, datum splatnosti faktury, datum zdanitelného plnění v případě, že je odběratel plátcem DPH, předmět fakturace včetně jednotkové ceny, měrné jednotky, množství a slevy, evidenční číslo faktury, základ daně, sazbu daně a výši daně 13

Razítko a podpis na faktuře přijaté není podmínkou. Fakturu lze přijmout jak v elektronické tak i papírové podobě. Předmětem této práce jsou faktury přijaté v papírové podobě, nicméně do celého procesu lze po menších úpravách zahrnout i faktury přijaté v elektronické podobě. [12] Rozhodujícím faktorem pro outsourcing zpracování finančních dokladů je mimo jiné i denní objem dokladů. Technologie pro digitalizaci a následné vytěžení údajů jsou finančně náročné, ve většině případů licencované na počet zpracovaných stran či dokumentů. Spodní hranicí pro vhodnost využití outsourcingu je denní objem na úrovni 100 dokladů. V případě nižších objemů jsou náklady spojené s poskytováním příliš vysoké a pro zákazníka ve většině případů neznamenají úsporu oproti ručnímu zpracování pomocí vlastních zdrojů. 14

4 Úroveň poskytování služby Outsourcing zpracování finančních dokladů je velice široký pojem. V předchozí kapitole jsme si vymezili doklady, které jsou pro tuto činnost vhodné. V této kapitole nastíním různé scénáře outsourcingu zpracování od toho základního až po komplexní proces zpracování. Z praxe vím, že se většinou začíná základním scénářem a v případě úspěšné implementace se postupnými kroky transformuje na komplexní zpracování. Tento scénář vychází i z částečné nedůvěry či ne vždy pozitivními zkušenostmi s outsourcingem byť z jiných oblastí. Činnosti, které mohou být předmětem outsourcingu: Příjem dokladů Příprava k digitalizaci Digitalizace dokladů Extrakce dat Validace dat o Validace vůči databázím zákazníka o Validace shody vytěžených dat s daty uvedenými na fyzickém dokladu Archivace Skartace Řešení výjimek Další úroveň této služby může sahat až do oblasti BPO, tedy komplexního zpracování celého procesu včetně zaúčtování, platby atd. Nicméně tato oblast již není předmětem této diplomové práce a dotýká se jí jen okrajově. 4.1 Základní scénář zpracování Tento scénář vychází z předpokladu, že daná společnost si nepřeje, aby její finanční doklady opustily prostory společnosti. Fyzický příjem, vlastní digitalizace a archivace je plně v režii zákazníka. Fyzicky se doklady nacházejí pouze v prostorách zákazníka, aniž by jej opustily. Zákazník fakturu přijme, připraví k digitalizaci, naskenuje a již v elektronické podobě předá partnerovi ke zpracování. Vlastní proces archivace fyzického dokladu si opět zajišťuje sám. 15

5 Stručný popis střediska V diplomové práci se zabývám outsourcingem zpracování finančních dokladů a z podstaty této věci je nezbytnou součástí řešení vlastní digitalizační středisko, kde bude služba fyzicky vykonávána. Předmětem této kapitoly je stručně popsat nutné vybavení takového střediska včetně personálního obsazení. Střediska tohoto typu se v dnešní době neustálého tlaku na finální cenu budují především v krajích s levnou pracovní sílou, u nás se především jedná o Moravskoslezský kraj a Ústecký kraj. Pro jednodušší činnosti v procesu se využívají i v hojnější míře handicapovaní pracovníci. Nutno podotknout, že řada společností podnikajících v tomto oboru již uvažují nebo již zřídila svá střediska mimo EU. Služba může být velice jednoduchého rázu, kdy zákazník sám dopraví dokumenty určené k digitalizaci do sdíleného střediska. Ty jsou následně naskenovány a předány zpět zákazníkovi včetně naskenovaných obrazů na přenosných médiích. Nebo naopak může být služba velmi komplexní, kdy zahrnuje svoz dokumentů, digitalizaci a vytěžení údajů, následný export a fyzickou archivaci dokumentů včetně následné skartace. Další službu, které by mělo sdílené středisko nabízet je zřízení vlastního poštovní schránky pro zákazníka, na kterou zákazník přesměruje své dodavatele. Na straně zákazníka tak odpadá jakákoliv manipulace s papírovými dokumenty. Součástí této služby může být i proces zpracování neplatných dokladů. Ten zahrnuje vrácení dokladu dodavateli s vytvořením průvodního dopisu s důvodem vrácení. Kromě služeb digitalizace by mělo středisko nabízet i služby tiskové, tak aby pokrylo komplexní rozsah úkonů spojených s dokumenty. V rámci sdíleného střediska se nachází několik oddělených pracovišť. 5.1 Pracoviště přípravy V celém procesu je to první pracoviště. Na tomto pracovišti probíhá prvotní přebírání dokumentů ke zpracování a jejich následná příprava k digitalizaci. Prvním krokem je evidence přijatých finančních dokladů, kdy se eviduje počet přijatých dokladů. Následuje rozřezání obálek na automatické řezačce k tomu určené, vyjmutí faktur a jejich rozešití či rozsponkování. Následně se na každou první stranu faktury nalepí štítek s čárovým kódem, který slouží k jednoznačné identifikaci faktury v rámci celého procesu. Zároveň slouží jako separátor pro skenovací software a pro následné vyhledávání faktury ve fyzickém archivu. 16

5.1.1 Čárové kódy Pro účely separace a identifikace faktur se používají štítky o velikosti 3cm 5cm. Dle požadované číselné řady se vybere typ čárového kódu a jeho konkrétní složení. 5.1.2 Typy čárových kódů Typů čárových kódů je celá řada, nicméně pro tyto účely se v praxi využívají jen některé. Nejčastěji používané typy čárových kódů: Code 128 (viz obrázek 2) umožnuje kódování alfanumerických znaků a je nejčastěji používán. Pomocí tohoto čárového kódu je možné zakódovat 96 ASCII znaků a 11 speciálních znaků. Každý znak je reprezentován 11 moduly čáry či mezery.[10] Obrázek 2 - Čárový kód typu Code 128 Zdroj: Vlastní zdroj Struktura kódu je ve tvaru XEYYYYNNNNNN, kde XE slouží pro označení typu dokumentu (v tomto případě finančního dokladu), YYYY reprezentuje rok, kdy byl finanční doklad zpracován a NNNNNN je generická číselná řada vzrůstající po jednotkách. Code 39 (viz obrázek 3) umožňuje kódování numerických znaků 0 9, alfa znaků A Z a dalších 7 speciálních znaků. Každý z těchto znaků je reprezentován pěti čárami a čtyřmi mezerami.[10] Obrázek 3 - Čárový kód typu Code 39 Zdroj: Kodys, 2009 [10] 17

Interleaved2 of 5 (viz obrázek 4) umožňuje kódování pouze numerických znaků a kódování vždy probíhá v párech, tudíž podmínkou je sudý počet číslic. Vyznačuje se vysokou hustotou zápisu. Každý znak reprezentuje pět čar nebo pět mezer.[10] Obrázek 4 - Čárový kód typu Interleaved 2 of 5 Zdroj: Kodys, 2009 [10] 5.2 Skenovací pracoviště Dalším pracovištěm v procesu je skenovací pracoviště. Na tomto pracovišti je kladen důraz na co nejefektivnější využití rychlosti skenovacího zařízení. To znamená tlak na co nejmenší lidskou manipulaci s dokumenty. Obsluha skeneru dostane doklady v dávce v malé přepravce, doklady vyjme a vloží do automatického podavače skeneru. Skenovací aplikace automaticky separuje jednotlivé doklady na základě nalepených čárových kódů a vytváří z nich jednotlivé dokumenty v rámci aplikace Kofax Capture. Po naskenování je obsluha opět uloží do přepravky a předá na pracoviště kompletace. Nedílnou součástí práce operátora je pravidelná denní údržba skeneru, kdy je nutné celé zařízení důkladně vyčistit stlačeným vzduchem, případně štětečkem a přípravkem na bázi ironu vyčistit snímací plochy skeneru. Frekvence čištění je dána množstvím naskenovaných dokladů, minimálně však jednou denně. Pokud se skenují doklady, které jsou vytištěny na průklepovém papíře, je nutné skener čistit častěji. 5.3 Pracoviště validace Na tomto pracovišti je pracovní stanice vybavena dvěma monitory, kdy je jeden otočen na šířku a druhý na výšku. Na jedné obrazovce je zobrazen obsah dávky a validační formulář. Na druhém monitoru je zobrazen obraz naskenovaného dokladu. Úkolem validátora je kontrola vytěžených údajů z dokladů. Pro jeho orientaci mu systém zobrazuje data orámovaných polí. Pokud je pole orámované zeleně, nemusí validátor tomuto poli věnovat pozornost. V případě, že je pole orámované červeně, je nutná validátorova součinnost. Data orámovaná zeleně označujeme za data validní a data orámovaná červeně za data nevalidní. Vyhodnocení probíhá na základě validačních pravidel, která jsou popsána v kapitole 7.5. 18

Uživatel má k dispozici řadu nástrojů pro korekci dat. V případě, že nebyl údaj vytěžen vůbec, uživatel najede myší na požadovaný údaj na naskenovaném obrazu a po kliknutí na něj se automaticky údaj vepíše do validačního formuláře. Toto jednak zrychluje celý proces validace, jelikož uživatel nemusí údaj opisovat, a za druhé automaticky učí systém, kde se správný údaj nachází. V některých případech má uživatel zase k dispozici různé pomocné databáze jako například databázi dodavatelů či databázi objednávek. Pokud tedy není identifikován dodavatel, nemusí jej uživatel opisovat, ale využije k jeho dohledání databázi dodavatelů. Cílem tohoto pracoviště je identifikovat nevalidní faktury, které musí být vráceny zpět dodavateli, a validní faktury, které budou následně zaslány zákazníkovi k importu do jeho účetního systému. V neposlední řadě je také cílem zajistit, aby data naimportována do účetního systému plně odpovídala hodnotám uvedeným na finančních dokladech. Pokud identifikuje fakturu jako nevalidní, odešle ji na pracoviště zpětné kompletace. 5.4 Pracoviště zpětné kompletace Na pracovišti zpětné kompletace jsou z naskenované dávky finančních dokladů vyjmuty ty doklady, které nesplňují některou zákonem stanovenou náležitost či vykazují jiný nedostatek. Ty je potom nutné vrátit zpět dodavateli. Zbytek finančních dokladů je předán na pracoviště archivace. Přehled finančních dokladů, které je nutné vrátit zpět dodavateli, vychází z výsledku validace. Po ukončení validace je vygenerován report v podobě CSV se seznamem veškerých dokladů, které neprošly validačními pravidly. Tento report je následně předáván v dohodnutém intervalu zákazníkovi. 5.5 Pracoviště archivace Poslední pracoviště v celém procesu, které pracuje s papírovou podobou finančních dokladů, je pracoviště archivace. Archivaci jako takovou dělíme na krátkodobou a dlouhodobou. Krátkodobá archivace je určena pro uskladnění finančních dokladů po dobu maximálně 3 měsíců, většinou však po dobu jednoho měsíce. Krátkodobý archiv se nachází přímo v prostorách sdíleného střediska. Po uplynutí doby pro krátkodobou archivaci jsou následně archivní krabice předány externí archivní spisovně (viz obrázek 5). Ta zajistí jejich dlouhodobou archivaci dle platné legislativy ČR, popřípadě jiných zemí, pokud jsou zpracovávány finanční doklady pro zahraniční subjekt. Práce archivátora spočívá v uložení naskenovaných finančních dokladů do archivačních krabic dle různých kritérií. Většinou se faktury řadí do archivní krabice dle hodnoty čárového kódu. Na archivní krabici se následně umístí štítek, který nese informaci o 19

čísle dané archivační krabice a rozpětí čárových kódů finančních dokladů v ní obsažené. Zároveň tyto informace zanese do systému, aby bylo možné finanční doklady v případě potřeby dohledat. Obrázek 5 Proces práce s dokumenty v externí archivní spisovně Zdroj: Helcl, 2011 [6] Další činností archivátora je fyzické vyhledávání finančních dokladů v krátkodobém úložišti na přání zákazníka. Doba uložení v krátkodobém úložišti vychází právě z četnosti dohledávek. Většina žádostí o dohledání fyzického dokladu je právě realizována v prvním měsíci po naskenování. Po této době je již žádostí velmi malé množství. Při předávání archivačních krabic k dlouhodobému uložení je o tomto vždy vyhotoven zápis v podobě předávacího protokolu. Na předávacím protokolu je seznam předávaných krabic a rozpětí čárových kódu v nich obsažených. Současně je archivátorovi tato informace předána i v elektronické podobě, zpravidla v podobě CSV či jinak strukturovaném souboru. Soubor následně použije externí spisovna pro import dat do svého systému určenému pro dohledávání fyzických dokladů. Vyhledávání fyzických dokladů v dlouhodobém úložišti je zpravidla již zpoplatněnou službou. Ukázka možné struktury CSV souboru: BOX_ID;FIRST_BARCODE;LAST_BARCODE;ARCHIVE_DATE 1;XE2011000001;XE2011001547;22.3.2011 2;XE2011001548;XE2011003004;22.3.2011 Archivačních krabic (viz obrázek 6) je na trhu mnoho, zpravidla se využívají krabice dle výběru konečné externí archivní spisovny. Většina z nich má archivační krabice vlastní výroby a uzpůsobené přímo svým potřebám a prostorám. 20

Obrázek 6 Archivační krabice Zdroj: Activa, 2011 [3] 21

6 Programové a technické vybavení Jedním ze základních předpokladů kvalitního a efektivního sdíleného střediska je jeho programové a technické vybavení. Jeho kvalitě je přímo úměrná nutnost zásahů operátorů. Jednak v podobě řešení problémů s infrastrukturou a jednak v podobě větší potřeby zásahu při validaci finančních dokladů. Ve výsledku to znamená nárůst nákladů na zpracování finančních dokladů a tudíž i nárůst koncové ceny služby pro zákazníka. 6.1 Hardware Předmětem této kapitoly není popsat kompletní infrastrukturu, jako jsou síťové prvky, jednotlivé servery a pracovní stanice. Cílem této kapitoly je popsat pouze hardware z hlediska vlastního procesu digitalizace, tedy dokumentové skenery. Na základě předpokládaného objemu zpracovávaných finančních dokladů je nutné vybrat odpovídající skenovací zařízení. Důraz musí být kladen zejména na rychlost skeneru, kapacitu podavače, detekci dvojího podání a v neposlední řadě na výslednou kvalitu obrazu. Důležitou vlastností u skeneru je detekce dvojího podání. V dnešní době se pro tyto účely využívá ultrazvuková detekce. Obrázek 7 - Schéma detekce dvojího podání Zdroj: Panasonic, 2011 [13] Mezi přední výrobce dokumentových skenerů lze zařadit skenery od společností Fujitsu, Kodak, Canon, HP, Panasonic či Xerox (viz graf 3). 22

Graf 3 - Tržní podíl dokumentových skenerů v Evropě (2007) Zdroj: Fujitsu, 2011 [5] Z hlediska množství zpracovávaných dokumentů lze skenery rozdělit na tři základní skupiny. První skupina se nazývá Desktop, druhá skupina se nazývá Workgroup a třetí skupinou jsou skenery z třídy Production. Ve sdíleném středisku je vhodné mít kombinaci skenerů z různých tříd. 6.1.1 Skenery třídy Desktop Do této skupiny lze zařadit skenery menších rozměrů. Většinou se vyrábí ve variantách s plochým ložem či bez něj. Jsou určeny pro menší objemy a jejich rychlost tomu odpovídá. Ve středisku se vesměs využívají na zpracovávání dokumentů, které jsou poškozené či je nelze z různých důvodů rozešít na jednotlivé listy. Typické vlastnosti této třídy [5, 9, 13, 25]: Rychlost 40ppm / 80ipm Jednostranné či oboustranné snímání Velikost předlohy maximálně A4 Většinou varianta s plochým ložem Typické představitelé této třídy: Fujitsu fi-6130, fi-6230, fi-6140 a fi-6240 [5] Panasonic KV-S1025C a KV-S1045C [13] Kodak i30, i40 a i1220 [9] Xerox DocuMate 262i [25] 23

6.1.2 Skenery třídy Workgroup Do této skupiny spadají skenery střední třídy, vhodné na větší objemy dokumentů. Tomuto požadavku odpovídají i rozměry skenerů a jejich robustnost. Hlavním rozdílem oproti třídě Desktop je možnost skenovat dokumenty až do velikost A3. Typické vlastnosti této třídy [5, 9, 13, 25]: Rychlost 60ppm / 120ipm Jednostranné či oboustranné snímání Velikost předlohy maximálně A3 Většinou pouze s automatickým podavačem bez plochého lože Typické představitelé této třídy: Fujitsu fi-4340, fi-6670 [5] Panasonic KV-S2048C, KV-7075C [13] Kodak i1310, i1420, Truper [9] Xerox DocuMate 3640 [25] 6.1.3 Skenery třídy Production Jedná se o skenery špičkové kvality, zaměřené na skenování velkých denních objemů. Zařízení této třídy je velmi robustní, většina namáhaných částí je vyrobena z kovu, nikoliv z plastů jako tomu je u skenerů nižších tříd. Ve sdíleném středisku se využívají pro dávkové skenování dokumentů. Základním předpokladem pro plné využití výkonu těchto skenerů je výkonná pracovní stanice a kvalitní příprava dokumentů. Typické vlastnosti této třídy [5, 9, 13, 25]: Rychlost 130ppm / 260ipm Jednostranné či oboustranné snímání Ultrazvuková detekce vícenásobného podání Velikost předlohy maximálně A3 Pouze varianty bez plochého lože Typické představitelé této třídy 24

Fujitsu fi-6800 [5] Panasonic KV-S4085CL [13] Kodak Ngenuity 9090 [9] Xerox DocuMate 765 [25] 6.2 Software Software je další nedílnou součástí sdíleného střediska. Tato kapitola je opět zaměřena jen na část softwarového vybavení a to zejména na části týkající se optimalizace naskenovaného obrazu a následného vytěžení dat z dokumentů. Další skupinu samozřejmě tvoří operační systémy, jak na straně serverů, tak na straně klientských stanic. 6.2.1 Optimalizace naskenovaného obrazu Velice důležitá část celého procesu. Na kvalitě naskenovaného dokumentu závisí následná úspěšnost vytěžení dat. Tato část procesu má za úkol i z nekvalitní papírové předlohy (viz obrázek 8) vytvořit co nejlepší elektronickou podobu vhodnou pro následné OCR. Standardem v tomto směru je dnes software Kofax VirtualReScan [11] od americké společnosti Kofax. Ve většině případů je ke skenerům dodávám zdarma v podobě OEM licence, a to ve verzi Professional. V podstatě se jedná o rozšíření standardního ovladače skeneru o novou funkcionalitu potřebnou k optimalizaci naskenovaného obrazu. Obrázek 8 - Originální dokumenty Zdroj: Xerox, 2010 [24] Skenování vždy probíhá ve stupních šedi, aby bylo možné následně po naskenování obraz pomocí VRS zoptimalizovat (viz obrázek 9 a 10) bez nutnosti jej znovu skenovat a následně převést do obrazu o hloubce 1 bit, tedy černobílé. Během optimalizace 25

dochází k filtraci šumu, vyhlazení pozadí a znaků, automatickému ořezu dokumentu a mnoha dalším úpravám. Obrázek 9 Dokumenty naskenovány bez VRS Zdroj: Xerox, 2010 [24] Obrázek 10 Dokumenty naskenovány s VRS Zdroj: Xerox, 2010 [24] Základní parametry pro skenování dokumentů: Rozlišení 300 DPI Barevná hloubka 1bit (černobílá) Výstupní formát TIF Důležitou vlastností z hlediska efektivity skenování je automatická rotace stránek dle orientace textu. Při přípravě dokumentů tedy není nutné jednotlivé strany otáčet dle jejich orientace, což výrazně spoří čas potřebný k jejich přípravě. 6.2.2 Automatické vytěžení údajů Technologicky je tato část procesu asi nejnáročnější. Veškeré dokumenty lze rozdělit do tří skupin. Zaprvé se jedná o strukturované dokumenty. Ty se dají charakterizovat tím, že vím, co hledám, a vím, kde to hledám. Do této skupiny spadají veškeré statické formuláře. Druhou skupinou jsou polostrukturované dokumenty. Tuto skupinu můžeme 26

charakterizovat tím, že vím, co hledám, ale nevím, kde to hledám. Do této skupiny právě spadají finanční doklady, typicky faktury. Třetí skupinou jsou nestrukturované dokumenty, které lze charakterizovat tím, že nevím, co hledám, a ani nevím, kde to hledám. Typickým představitelem této skupiny je běžná korespondence, jako jsou dopisy či faxy. Strukturované dokumenty dnes dokáže vytěžit mnoho dostupných nástrojů, jako jsou Abbyy FineReader [2], Kofax Capture [11], eflow od Top Image Systems [16] či Documents a Forms [15] od společnosti Readsoft. Polostrukturované dokumenty dokáže efektivně bez nutnosti většího zásahu operátorů zpracovat jen několik produktů na trhu. Lídrem v této oblasti je jednoznačně společnost Kofax se svým produktem Kofax Transformation Modules [11], který je nadstavbovým modulem základny Kofax Capture. Mezi další produkty patří InvoiceReader [16] od společnosti TopImage Systems, který je nadstavbou základní platformy eflow či Invoices [15] od společnosti ReadSoft. Graf 4 Tržní podíl jednotlivých společností na trhu v dávkovém zpracování Zdroj: Spencer, Harvey, 2010 [23] Popis procesu vytěžení údajů je popsán na platformě Kofax (viz kapitola 6.2.3), nicméně obdobným způsobem je postupováno i v rámci platformy eflow. 6.2.3 Kofax Capture Jedná se o základní platformu pro vytěžování dat. Software je plně modulární, tzn., že se v rámci administrace systému nejprve nakonfiguruje workflow dokumentu v rámci systému Kofax Capture a teprve následně se nakonfigurují základní vlastnosti jednotlivých kroků. Prvním krokem je pořízení dokumentů, tedy modul Scan, který komunikuje se skenerem a zajišťuje vstup dokumentů do procesu zpracování. Skenování vždy probíhá dávkově, nikoliv po jednom dokumentu. Modul sken je plně integrován s aplikací VRS pro optimalizaci obrazu. 27

Dalším krokem ve workflow je KTM Server. Tento modul nejprve zajistí celostránkové OCR a podle předem nadefinovaných pravidel dohledává jednotlivé údaje na dokumentu. Popis pravidel je dále popsán v kapitole 6.2.3 Kofax Transformation Modules. Následuje krok Validation, kdy jsou na nalezená data aplikována validační pravidla a v případě rozporu je vyzván uživatel ke kontrole, popřípadě k opravě, vytěžených dat. Kontrola vytěžených údajů může probíhat na základě kontroly jednotlivých znaků nebo na základě kontroly kompletních údajů. Po kontrole údajů následuje modul Learning Server, kde dochází k automatickému vytváření šablon v případě, že byl dokument v předchozím kroku uživatelem upraven. V případě, že je požadovaným výstupem formát PDF, následuje modul PDF Generator. Tento modul zajistí převod formátu TIF na formát PDF či PDF/A. Posledním modulem v řadě je Export Connector, který ukládá dávky do cílového systému. V případě sdíleného střediska se většinou využívá export na adresářovou strukturu v podobě PDF či TIF a doprovodného souboru s metadaty ve formě CSV či jiného strukturovaného souboru. 6.2.4 Kofax Transformation Modules Jedná se o nadstavbový modul určený pro vytěžování polostrukturovaných dokumentů, tedy i finančních dokladů. Vytěžení údajů probíhá v několika krocích, nejprve je provedeno celostránkové OCR. K tomuto účelu využívá aplikace OCR Enginy třetích stran. Vybírat je možné z RecoStar, ABBY, Kadmos, OmniPage či jiných. Následuje porovnání na základě vzhledu dokladu s již zpracovanými doklady v předchozích dávkách. Pokud je nalezena odpovídající šablona, je přiřazena a vytěžení nadále probíhá formulářovým způsobem. Pokud není šablona nalezena, jsou aplikována obecná vytěžovací pravidla. Mezi ně lze zařadit formátové lokátory, které vyhledávají ve výsledku OCR řetězce odpovídající určité definici. Definice se specifikuje regulárními výrazy (viz obrázek 11). Výsledek lze ještě zúžit pomocí definice klíčových slov (viz obrázek 12), určením jejich pravděpodobné pozice vůči nalezenému výrazu a omezením oblasti hledání (viz obrázek 13). Ve slovní podobě může definice znít: Najdi na první stránce v její horní polovině výraz začínající na CZ následovaný 8 číslicemi. Následně vyfiltruj jen ty výrazy, které se nachází napravo od klíčového slova DIČ. 28

Obrázek 11 - Ukázka definice hledaného řetězce pomocí regulárních výrazů Zdroj: Vlastní implementace Kofax Transformation Modules Obrázek 12 - Ukázka definice klíčových slov a jejich pozice Zdroj: Vlastní implementace Kofax Transformation Modules Obrázek 13 - Ukázka definice oblasti hledání Zdroj: Vlastní implementace Kofax Transformation Modules 29

6.3 Regulární výrazy Regulární výraz (regular expression), označovaný též zkráceně jako regexp či regex, je speciální řetězec znaků, který představuje určitý vzor, neboli masku, pro textové řetězce. Regulární výrazy se proto nejčastěji používají ke kontrole dat zadávaných ve formulářích (například e-mailová adresa či PSČ). [14] Základem regulárních výrazů jsou metaznaky. V konkrétních aplikacích může být skupina metaznaků omezena jen na určitou skupinu. Mezi základní metaznaky regulárních výrazů patří: Tabulka 1 - Metaznaky regulárních výrazů Metaznak Popis Příklad Tečka, zpětné lomítko. (tečka) Zastupuje právě jeden libovolný znak a.b odpovídá např. acb, \ Vrací metaznaku původní význam a\+b odpovídá a+b Kvantifikátory předcházející znak se musí vyskytovat? Znak se vyskytuje minimálně 0 a maximálně 1 ab?c odpovídá pouze ac a abc * Znak se vyskytuje minimálně 0 a maximálně neomezeně ab*c odpovídá např. ac, abc, abbbbc + Znak se vyskytuje minimálně 1 a maximálně neomezeně ab+c odpovídá např. abc, abbbbc {n} Znak se vyskytuje právě n-krát ab{6} odpovídá pouze abbbbbb {m,n} Znak se vyskytuje minimálně m-krát, ab{2,4} odpovídá např. maximálně n-krát abb, abbb, abbbb {n,} Znak se vyskytuje minimálně n-krát ab{2,} odpovídá např. ab, abbb Skupiny znaků [ ] Odpovídá jednomu znaků v závorkách [abc] odpovídá právě [^ ] Odpovídá jednomu znaku, neuvedenému v závorkách 30 a,b,c [^abc] odpovídá libovolný znak krom a, b, c [ - ] Odpovídá jednomu znaku z rozsahu znaků [a-z] odpovídají (malá) písmena abecedy \s Odpovídá bílému znaku (\n, \r, \t, mezera aj.) a\sb odpovídá a b, ale ne ab \S Odpovídá jinému než bílému znaku a\sb odpovídá a+b, ale ne a b \d Odpovídá desítkové číslici a\db odpovídá a2b, ale ne axb \D Odpovídá libovolnému znaku kromě číslic 0-9 a\db odpovídá axb, ale ne a2b \w Odpovídá alfanumerickému znaku a \w odpovídá 1, a, A, _ podtržítku ap., ale ne $, + \W Odpovídá nealfanumerickému znaku nebo \W odpovídá $,!,?, %

Metaznak Popis Příklad podtržítku ap., ale ne 2, b Hranice (ukotvení) - Odpovídá pozici ^ Na začátku řetězce či řádku ^CZ najde CZ jen na začátku řetězce/řádku $ Na konci řetězce či řádku CZ$ najde CZ jen na konci řetězce/řádku \b Na začátku či konci tzv. slova \bcz\b nenajde CZ ve slově CZ123 či 123CZ \B Kdekoliv kromě začátku a konce slova \BCZ najde CZ ve slově 12CZ43, ale ne v CZ12 Alternativy, seskupování, zpětné odkazy (reference) Odděluje několik dílčích výrazů CZ SK odpovídá právě jednomu z kódů země Odděluje několik dílčích subvýrazů a(b c) odpovídá právě ab a ac ( ) Subřetězec na nějž je možno aplikovat ko(ko)?s odpovídá kvantifikátor právě kos a kokos Subřetězec na nějž se lze odkazovat (\d)\1 resp. (\d)$1 odpovídá 11, 22, 33 Speciální závorkové konstrukce (?: ) Uzávorkování netvořící zpětnou referenci (?:\d)(\d)\1 bude odpovídat 122, 133, 455 apod. (?# ) Komentář - text v závorkách za znakem # je a(?#test)b odpovídá ignorován právě ab (?= ) Kladné tvrzení o následujícím kos(?=t) odpovídá kos v kost, ale ne v kosa (?! ) Záporné tvrzení o následujícím kos(?!t) odpovídá kos v kosa, kosu ale ne v kost (?<= ) Kladné tvrzení o předcházejícím \d{3}(?<=0) sekvence 3 číslic; poslední musí být 0 (?<! ) Záporné tvrzení o předcházejícím \d{3}(?<!0) sekvence 3 číslic; poslední nesmí být 0 Zdroj: Pecka, 2008 [14] 31

6.4 Lidské zdroje Dalším klíčovým faktorem v celém procesu zpracování jsou lidské zdroje. Náklady na lidské zdroje tvoří největší část z celkových nákladů na provoz sdíleného střediska a efektivita a produktivita jednotlivých pracovníků velice významným způsobem ovlivňuje finální cenu zpracování dokladů. V každém středisku je několik úrovní vedení, které jsou znázorněny v následující organizační struktuře na schématu 1. Schéma 1 - Organizační struktura Site manager Vedoucí pracoviště přípravy Vedoucí skenovacího pracoviště Vedoucí validace Vedoucí pracoviště zpětné kompletace Vedoucí pracoviště archivace Pracovník přípravy Operátor skeneru Validátor Pracovník zpětné kompletace Archivátor Zdroj: Vlastní zpracování 6.4.1 Site manager Sitemanager je přímo zodpovědný za kompletní provoz sdíleného střediska, dodržování jednotlivých parametrů SLA vůči zákazníkům. Dohlíží nad celým procesem zpracování dokladů a připravuje reporty pro zákazníky a podklady pro fakturaci. Pravidelně se účastní SLA schůzek u zákazníků a je jejich styčnou osobou. Také koordinuje jednotlivé vedoucí všech zúčastněných pracovišť a spolu s nimi navrhuje motivační schémata pro pracovníky jednotlivých pracovišť. Vždy je potřeba najít rovnováhu mezi rychlostí a kvalitou odvedené práce. 6.4.2 Vedoucí jednotlivých pracovišť Vedoucí jednotlivých pracovišť mají na starosti vždy jedno pracoviště a dohlížejí nad jeho provozem a efektivním rozdělením zátěže mezi jednotlivé pracovníky daného pracoviště. Jeho dalším úkolem je hledat úzká hrdla celého procesu na daném pracovišti a připravovat návrhy na jejich odstranění. 32

7 Rozbor procesu zpracování Komplexní proces zpracování finančních dokladů se dá rozdělit do několika fází. Jednotlivé fáze, které můžeme vidět na schématu 2, vesměs odpovídají rozvržení jednotlivých pracovišť ve sdíleném středisku. Schéma 2 - Proces toku finančních dokladů v rámci digitalizačního centra P.O.BOX Příjem zásilek ve sdíleném centru Příprava finančních dokladů Předání zákazníkovi Není finanční doklad Je finanční doklad Skenování OCR Validace Tvorba PDF Export dat Přenos k zákazníkovi Zdroj: Vlastní zpracování Z diagramu procesu zpracování finančních dokladů je vidět náročnost celého procesu a vyplývá z něj také velmi častá manipulace, a to jak s fyzickým dokladem, tak s jeho 33

elektronickou podobou. Častou manipulací s finančním dokladem vzniká velké riziko časového prodlení zpracování. 7.1 Příjem zásilek Doklady jsou do sdíleného střediska doručovány Českou poštou. Po jejich příjmu proběhne zápis do databázového systému, kde se eviduje počet přijatých 4 zásilek a datum přijetí zásilek. Pro tyto účely se používá jednoduchá webová aplikace vyvinutá přímo pro potřeby sdíleného střediska. 7.2 Příprava finančních dokladů Proces přípravy je detailně popsán výše v práci (viz kapitola 5.1). Jedná se o ryze manuální práci bez jakékoliv softwarové podpory. 7.3 Skenovaní finančních dokladů Skenování dokladů probíhá dávkově a k separaci se využívá již dříve zmíněný čárový kód. Během skenování se zároveň kontroluje i kvalita naskenovaného obrazu a v případě potřeby se provede jeho korekce. Výstupem je naskenovaný obraz ve formátu TIF v barevné hloubce 1 bit a v rozlišení 300DPI. Ve skutečnosti se ale skenuje ve stupních šedi, aby bylo možné následně pomocí aplikace Kofax VirtualReScan upravit špatně čitelný obraz bez nutnosti jej znovu skenovat s jiným nastavením. Na černobílý je převeden až v okamžiku dokončení skenovacího procesu a uzavření celé naskenované dávky. Pro problematické faktury lze nastavit separátní skenovací profil s jiným nastavením než pro ostatní doklady. Systém je schopen automaticky detekovat problematickou fakturu a aplikovat jiný skenovací profil bez nutnosti zásahu uživatele. Není tedy nutné problematické doklady skenovat odděleně od ostatních. 7.4 OCR OCR je schopnost programu konvertovat naskenovaný (zdigitalizovaný) obraz tištěného nebo ručně psaného textu do podoby, která může být reorganizována a manipulována programy pro práci s textem. Využití OCR je zejména v ukládání obsahu knih a jiných dokumentů bez nutnosti přepisování či opětovného vytváření textu. [22] 4 Počet přijatých zásilek nemusí odpovídat počtu přijatých finančních dokladů. V jedné zásilce se může nacházet více než jeden finanční doklad. 34

Z finančního dokladu je potřeba vytěžit ty údaje (viz tabulka 3), které následně zákazník potřebuje pro účely svého účetnictví a reportování. Cílem je vytěžit veškeré údaje, které zákazník dříve zadával do svých systémů ručně. Název vytěžovaného pole Max. délka Tabulka 2 - Přehled vytěžovaných údajů Povinné pole Příklad Poznámka Číslo dodavatele 10 Ano v případě nenalezení dodavatele v databázi, bude doplněno číslo 1000000001 DIČ 5 12 Ne CZ12345678 Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. IČO 6 12 Ano 12345678 Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Název dodavatele 50 Ano Dodavatel, a.s. Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Ulice 50 Ne O. Peška 725 Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Město 50 Ne Kladno Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. PSČ 7 6 Ne 272 01 Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Datum zdanitelného plnění Datum vystavení dokladu 8 Ne 20081030 Zahraniční faktury toto pole bude prázdné 8 Ano Číslo dokladu 15 Ano Primárně variabilní symbol, vypustit vše kromě čísel. Oříznout zprava (12345 bude 345) 5 DIČ daňové identifikační číslo 6 IČO identifikační číslo organizace 7 PSČ poštovní směrovací číslo 35

Název vytěžovaného pole Max. délka Povinné pole Příklad Poznámka Měna dokladu 3 Ano CZK ISO kód měny 8 Celková částka 12,2 Ano 12345.50 včetně DPH 9 Typ dokladu 4 Ano INVO Z číselníku, který bude dodán Celková částka daně 12,2 Ne 56.00 Pokud není uvedeno, pole bude prázdné (nesčítat) Základ daně při 12,2 Ne 100.00 nulové sazbě daně Základ daně při 12,2 Ne 200.00 sazbě snížené sazbě Hodnota daně při 12,2 Ne 18.00 sazbě snížené sazbě Snížená sazba 12,2 Ne 9.00 daně Základ daně při 12,2 Ne 200.00 sazbě základní Hodnota daně při 12,2 Ne 38.00 sazbě základní Sazba daně základní 12,2 Ne 19.00 Zdroj: Vlastní zdroj Pro zvýšení úspěšnosti vytěžovaných údajů se v systému využívají pomocné databáze a seznamy. Po vytěžení údaje se daná hodnota porovná s příslušnou hodnotou v databázi či slovníku a na základě výsledku je údaj označen za validní či nevalidní. Nejčastěji používané databáze a seznamy: Databáze dodavatelů Databáze objednávek Seznam ISO kódů měn Seznam měsíců (leden, únor, březen ) 8 Dle ISO normy 4217 9 DPH daň z přidané hodnoty 36

7.4.1 Identifikace dodavatele Prvotní činností v rámci vytěžování dat je identifikace dodavatele. K tomuto účelu je využívána databáze dodavatelů, kterou v pravidelných intervalech, většinou na denní bázi, zasílá zákazník do sdíleného střediska. Identifikace probíhá na základě porovnání vytěžených údajů z dokladu s údaji v databázi. Pro co největší míru úspěšné identifikace dodavatele je využíván Fuzzy Search, kdy není požadována 100% shoda porovnávaných řetězců, ale jen částečná. Seznam údajů, které jsou porovnávány a slouží k identifikaci dodavatele: IČO a DIČ Název dodavatele Adresa dodavatele Číslo bankovního účtu Na základě výsledku Fuzzy Search je každé možné variantě přidána spolehlivost v rozmezí 0 až 100%. Hodnocení se provádí na základě shody jednotlivých vytěžených údajů s údaji v databázi. Záznam, který získal nejvyšší hodnotu, je vybrán jako odpovídající dodavatel. V systému se také nastaví, jaká je minimální spolehlivost, aby byl záznam uznán za ten korektní. Obrázek 14 - Výsledek Fuzzy Search Zdroj: Vlastní implementace Kofax Transformation Modules V rámci exportu již neprobíhá předání veškerých dat, jako je název dodavatele, IČO a jiné. Většina zákazníků požaduje v exportu pouze číslo dodavatele z jejich systému. Po importu do jejich účetního systému jsou data k dodavateli doplněna na základě obdrženého čísla dodavatele. 7.4.2 Částky na finančních dokladech Pro vyhledání částek na finančním dokladu se mimo jiné využívá i matematická logika. Princip dohledání korektních částek spočívá nejprve v nalezení všech číselných údajů na faktuře, které odpovídají předem definovanému regulárnímu výrazu. Následně se aplikují níže zmíněné vzorce. Systém automaticky dosazuje jednotlivé částky do vzorců a jako relevantní bere jen ty kombinace, které jim plně vyhovují. Míra odchylky 37

způsobená zaokrouhlováním je v systému také definovatelná. U české měny se využívá zaokrouhlování na celé koruny. Příklady vzorců pro nalezení správných kombinací částek: Základ daně při nulové sazbě DPH + základ daně při snížené sazbě DPH + hodnota daně při snížené sazbě DPH + základ daně při základní sazbě DPH + hodnota daně při základní sazbě DPH = celková částka včetně DPH základ daně při snížené sazbě DPH * snížená sazba DPH = hodnota daně při snížení sazbě DPH základ daně při základní sazbě DPH * základní sazba DPH = hodnota daně při základní sazbě DPH 7.4.3 Vyhledávání datumů O finančních dokladech se dá zjednodušeně říci, že co doklad to originál. V případech data splatnosti, data vystavení a data zdanitelného plnění existuje mnoho formátů uvedených na dokladu. Pro jejich vytěžení se používají regulární výrazy, kde je možné specifikovat veškeré možné formáty, které se eventuálně mohou na dokladech objevit. Nejběžněji se vyskytující formáty datumů: DD.MM.YYYY DD.MM.YY YYYYMMDD DD/MM/YYYY DD měsíc YYYY Příklady regulárních výrazů používaných pro vytěžování: \d{1,2}\s?([\.\-/])\s?\d{1,2}\s?\1\s?(\d{4} \d{2}) \d{1,2}\s?,\s?\d{1,2}\s?\.\s?(\d{4} \d{2}) [\doi\ ]{1,2}\s?([\.\-/])\s?[\dOI\ ]{1,2}\s?\1\s?([\dOI\ ]{4} \d{2}) \d{1,2}\.?\s? Monthname \s?(\d{4} \d{2}) Monthname je název seznamu s měsíci 38

Nedílnou součástí je i následné formátování, kdy veškeré možné formáty přetransformuje systém do jednoho předem určeného formátu. To je důležité jednak pro validátora, a jednak pro export dat a jejich následný import do účetnického systému zákazníka. Zpravidla se tedy výsledný formát řídí požadavkem zákazníka. 7.4.4 Typ dokladu Zpravidla se rozlišují dva typy finančních dokladů. Jedním typem je faktura a druhým typem je dobropis. Typ dokladu je vyhodnocen na základě dohledání klíčových slov. V případě, že je na dokladu nalezen výraz Faktura je přiřazen typ faktura reprezentován zkratkou INVO. Zkratka vychází z požadavku zákazníka, respektive jeho účetního systému. Klíčových slov je v systému možné nastavit více. Pokud je na dokladu nalezen výraz Dobropis je přiřazen typ dobropis reprezentovaný zkratkou CRME. Zkratka opět vychází z požadavku zákazníka, respektive jeho účetního systému. Klíčových slov je v systému možné nastavit více. Jestliže systém nenajde ani jedno z předem nadefinovaných klíčových slov, není typ dokladu určen a určení musí provést validátor v rámci validace. Obrázek 15 - Definice typu finančního dokladu Zdroj: Vlastní implementace Kofax Transformation Modules 7.5 Validace Validace, jejíž proces je znázorněn na schématu 3, probíhá jednak vizuální kontrolou, kdy se kontrolují vytěžená data oproti údajům uvedeným na finančním dokladu a jednak automaticky na pozadí. Během automatické validace se porovnávají data s údaji v pomocných databázích. Tímto způsobem je možné zkontrolovat správnost vytěžení např. dodavatele, jeho IČ či DIČ. Dalším způsobem validace je kontrola vytěženého údaje oproti nadefinovaným maskám. K jejich definici se využívají již výše zmíněné regulární výrazy. 39

Na každém vytěženém poli může být uplatněno několik validačních pravidel. Údaj může být označen za platný, pokud splní všechny nadefinované validační pravidla nebo pokud splní aspoň jedno z nich. Validační pravidla lze definovat i napříč více poli. Lze tedy aplikovat pravidla v duchu pokud je vyplněno pole A, musí být zároveň vyplněné i pole B. Tvorba takovýchto validačních pravidel již vyžaduje znalost programovacího jazyka.net, ve kterém je možné psát komplexnější validační pravidla. Schéma 3 - Proces validace Spuštění validace Automatické validace na pozadí Vyhodnocení jednotlivých polí Pole označeno zeleně Pole je validní Pole je nevalidní Uživatelská oprava dat Zdroj: Vlastní zpracování 7.6 Tvorba PDF Výstupem zdigitalizovaných finančních dokladů je ve většině případů dokument ve formátu PDF. Dalším možným výstupem je formát TIF. O tvorbu PDF se stará samostatný modul PDF Generator, který běží na pozadí bez nutnosti zásahu uživatelů. Jeho úkolem je převést naskenovaný doklad z formátu TIF na formát PDF, popřípadě PDF/A. Převod je nutný z toho důvodu, že Kofax Capture pro OCR interně využívá právě zmíněný formát TIF. Preferovaným výstupem je dnes již poměrně rozšířený formát PDF/A, který je vhodný pro dlouhodobé uchovávání naskenovaných obrazů. 40

7.7 Export dat Export dat je poslední modul v konfiguraci Kofax Capture. Jeho úkolem je vyexportovat data ze systému Kofax. Tento modul opět běží na pozadí bez nutnosti zásahu uživatele. Jak je vidět na obrázku 16, modul exportuje zpravidla dva soubory k jednomu finančnímu dokladu. Vlastní naskenovaný obraz v podobě PDF/A a dále vytěžená a zvalidovaná metadata ve formě XML či CSV. Export probíhá na souborovou strukturu, nebo na jiné úložiště. Během exportu dojde také k pojmenování výstupních souborů dle čárového kódu. Obrázek 16 Příklad výstupu exportovaných dat na adresářové struktuře Příklad struktury výstupního XML: Zdroj: Vlastní zdroj <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE jmeno_souboru.pripona SYSTEM "jmeno_souboru.pripona"> <INVOICE> <PO_BOX></PO_BOX> <BARCODE></BARCODE> <VENDOR_ID></VENDOR_ID> <VENDOR_SITE_ID></VENDOR_SITE_ID> <ICO></ICO> <VAT_REGISTRATION_NUM></VAT_REGISTRATION_NUM> <INVOICE_NUMBER></INVOICE_NUMBER> <INVOICE_TYPE></INVOICE_TYPE> <CURRENCY_CODE></CURRENCY_CODE> <PAYMENT_TYPE></PAYMENT_TYPE> <BANK_ACCOUNT></BANK_ACCOUNT> <BANK_CODE></BANK_CODE> <INVOICE_DATE></INVOICE_DATE > <PAYMENT_DATE></PAYMENT_DATE> <DUZP></DUZP> <ZERO_TAX_BASE_AMOUNT></ZERO_TAX_BASE_AMOUNT> <TAX_BASE_1_AMOUNT></TAX_BASE_1_AMOUNT> <TAX_1_AMOUNT></TAX_1_AMOUNT> <TAX_1_RATE></TAX_1_RATE> <TAX_BASE_2_AMOUNT></TAX_BASE_2_AMOUNT> <TAX_2_AMOUNT></TAX_2_AMOUNT> 41

<TAX_2_RATE></TAX_2_RATE> <INVOICE_AMOUNT></INVOICE_AMOUNT> <PURCHASE_ORDER></PURCHASE_ORDER> <ERROR_CODE_LIST></ERROR_CODE_LIST> <PROCESS_DATE></PROCESS_DATE> <ARCHIVE_BOX_NR></ARCHIVE_BOX_NR> </INVOICE> Mimo XML je možné exportovat metadata ve formátu CSV, IDOC 10, ISDOC 11 nebo TXT 12. Konkrétní formát a jeho přesná struktura většinou vychází z koncového systému zákazníka a jeho importního rozhraní. 7.8 Předání zákazníkovi Předání dat zpět zákazníkovi lze realizovat několika způsoby. Nejčastěji je využíván SFTP 13, na který jsou data uložena a odkud si je zákazník v pravidelných intervalech stahuje. Data se na SFTP ukládají zazipovaná, aby byl jejich přenos co nejjednodušší a velikost co nejmenší. Dalším způsobem předání dat je jejich vypálení na přenosná média. V závislosti na objemu předávaných dat jsou využívána různá přenosná média. V ojedinělých případech lze využít specializované kanály zákazníka jako je B2B 14 apod. Pro sdílené středisko je to krajní způsob, jelikož je nutné pro každého zákazníka vyčlenit samostatný server Veškerá data jsou také uchovávána interně pro případ, že by došlo k selhání přenosu či poškození médií. Doba, po kterou jsou data uchovávána, většinou odpovídá době krátkodobé archivace fyzických dokladů. Poté jsou data ze systému vymazána, a to jak naskenované obrazy, tak i metadata z interních databází systémů. 10 IDOC standard pro výměnu dat mezi SAP systémy 11 ISDOC formát elektronické fakturace v ČR 12 TXT textový soubor s koncovkou txt 13 SFTP - Secure File Transfer Protocol 14 B2B - Business-to-business 42

8 Vzorová implementace V této kapitole je ukázka vzorové implementace na fiktivním potencionálním zákazníkovi. 8.1 Charakteristika zákazníka Vzorový zákazník je středně velká výrobní společnost působící na českém trhu. Dodavatelé této společnosti jsou jak tuzemské společnosti, tak i společnosti zahraniční, výhradně však z Evropské unie a používající měnu EUR. Zákazník má naimplementovaný informační systém mysap 15 od společnosti SAP, zejména modul FI 16 určený pro finanční účetnictví a MM 17 modul určený pro skladové hospodářství. mysap zároveň využívá pro schvalování objednávek. Poměr mezi fakturami za služby (FI) a fakturami za materiál (MM) je 20 ku 80. Na základě tohoto poměru bylo rozhodnuto se věnovat v první vlně implementace pouze materiálovým fakturám. Objem přijatých faktur je zhruba 50 000 za rok. Rozložení po měsících je uvedeno v grafu 5. Graf 5 Přehled přijatých faktur po měsících Přehled přijatých faktur po měsících 5000 4000 3000 2000 Počet přijatých faktur 1000 0 Zdroj: Vlastní zdroj Pro vlastní implementaci je také důležité rozložení celkového ročního objemu mezi jednotlivé dodavatele zákazníka. Primárním důvodem je možnost tvorby šablon pro nejpočetnější dodavatele z hlediska objemu příchozích faktur. Optimální hranice pro 15 mysap software určený pro řízení podniku (ERP) 16 FI modul mysap určený pro finanční účetnictví 17 MM modul mysap určený pro skladové hospodářství 43

tvorbu šablony pro daného dodavatele je 250 přijatých faktur za den. V grafu 6 jsou uvedeny dodavatelé zákazníka, který splňují výše uvedené kritérium, včetně počtu přijatých faktur za rok. 12000 Graf 6 - Počet přijatých faktur za rok Počet přijatých faktur za rok 10000 8000 6000 4000 Počet faktur 2000 0 Zdroj: Vlastní zdroj Z grafu 6 lze také vyčíst, že 60% všech přijatých faktur za rok pochází pouze od 15 dodavatelů. Dále pak skutečnost, že 50% všech přijatých faktur za rok pochází pouze od 3 dodavatelů. Zde je na pováženou, zda pro tyto 3 dodavatele nezvolit jinou formu výměny daňových dokladů než je forma papírová. Jako možné řešení se zde jednoznačně nabízí některá z forem EDI 18. Pro implementaci a správné nastavení služby je také velmi důležitý vývoj objemu přijatých faktur za poslední 3 roky a dále předpokládaný vývoj objemu přijatých faktur po dobu fixace poskytování služby zpracování. Tato doba zpravidla bývá 36 nebo 48 měsíců. Tento vývoj je znázorněn v grafu 7. 18 EDI elektronická výměna dat mezi systémy dodavatele a zákazníka 44

Graf 7- Počet přijatých faktur za jednotlivé roky Počet přijatých faktur za jednotlivé roky 60000 50000 40000 30000 20000 Počet faktur 10000 0 Rok -3 Rok -2 Rok -1 Rok 0 Rok 1 Rok 2 Rok 3 Zdroj: Vlastní zdroj Jak vyplývá z grafu 7, zákazník předpokládá v prvních dvou letech nárůst počtu přijatých faktur. Ovšem v následujících dvou letech dojde ke změně trendu za poslední roky a celkový počet přijatých faktur bude klesat a to celkem významně. Důvodem pro takovýto pokles může být zavedení již zmíněného EDI, konsolidace dodavatelů nebo změna strategie společnosti. Pro budoucího poskytovatele je toto velmi důležitý údaj při kalkulaci ceny za poskytovanou službu. V neposlední řadě jej to ovlivní při plánování veškerých zdrojů a rozložení jeho financování. Většina poskytovatelů služby pak vyžaduje garanci minimálního počtu přijatých faktur za rok formou smluvního ujednání. Dalším důležitým údajem je průměrný počet stran na jednu přijatou fakturu. Tento údaj je důležitý opět převážně pro poskytovatele služby. Většina zmíněných systémů na zpracování faktur je totiž licencována na počet naskenovaných stran. Z toho vyplývá, že tento údaj má opět vliv na výši investice ze strany poskytovatele služby a tudíž na výslednou cenu za poskytování služby. Tabulka 3 - Průměrný počet stran Položka Průměrný počet stran Faktura 2,5 Příloha faktury 8 Faktura včetně příloh 10,5 Zdroj: Vlastní zdroj 45