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
3
2.1
Pojem outsourcing ........................................................................................... 10
2.2
Proč outsourcing .............................................................................................. 10
2.3
Outsourcing v oblasti digitalizace.................................................................... 11
2.4
Service Level Agreement (SLA) ..................................................................... 12
Finanční doklady vhodné k outsourcingu zpracování ............................................. 13 3.1
4
Úroveň poskytování služby ..................................................................................... 15 4.1
5
Základní scénář zpracování.............................................................................. 15
Stručný popis střediska ........................................................................................... 16 5.1
6
Právní náležitosti faktury ................................................................................. 13
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
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
8
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
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
8.7.1
Zálohování dat .......................................................................................... 60
8.7.2
Automatická skartace dat.......................................................................... 60
8.8
9
Zabezpečení dat ............................................................................................... 60
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
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-IS1 a TO-BE2 a návrhu SLA3. 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 TO-BE – budoucí neboli cílový stav 3 SLA – Service Level Agreement 2
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 Tečka, zpětné lomítko Zastupuje právě jeden libovolný znak . (tečka) Vrací metaznaku původní význam \ Kvantifikátory – předcházející znak se musí vyskytovat Znak se vyskytuje minimálně 0× a maximálně ? 1× * Znak se vyskytuje minimálně 0× a maximálně neomezeně Znak se vyskytuje minimálně 1× a maximálně + neomezeně Znak se vyskytuje právě n-krát {n} {m,n}
Znak se vyskytuje maximálně n-krát
minimálně
{n,}
Znak se vyskytuje minimálně n-krát
[^ ]
Odpovídá jednomu znaku, neuvedenému v závorkách
[-]
Odpovídá jednomu znaku z rozsahu znaků
\s
Odpovídá bílému znaku (\n, \r, \t, mezera aj.)
\S
Odpovídá jinému než bílému znaku
\d
Odpovídá desítkové číslici
\D
Odpovídá libovolnému znaku kromě číslic 0-9
\w
Odpovídá alfanumerickému znaku a podtržítku Odpovídá nealfanumerickému znaku nebo 30
a.b odpovídá např. acb, a\+b odpovídá a+b
ab?c odpovídá pouze ac a abc ab*c odpovídá např. ac, abc, abbbbc ab+c odpovídá např. abc, abbbbc ab{6} odpovídá pouze abbbbbb m-krát, ab{2,4} odpovídá např. abb, abbb, abbbb ab{2,} odpovídá např. ab, abbb
Skupiny znaků Odpovídá jednomu znaků v závorkách []
\W
Příklad
[abc] odpovídá právě a,b,c [^abc] odpovídá libovolný znak krom a, b, c [a-z] odpovídají (malá) písmena abecedy a\sb odpovídá a b, ale ne ab a\Sb odpovídá a+b, ale ne a b a\db odpovídá a2b, ale ne axb a\Db odpovídá axb, ale ne a2b \w odpovídá 1, a, A, _ ap., ale ne $, + \W odpovídá $, !, ?, %
Metaznak
Popis podtržítku Hranice (ukotvení) - Odpovídá pozici… Na začátku řetězce či řádku ^
Příklad ap., ale ne 2, b
$
Na konci řetězce či řádku
\b
Na začátku či konci tzv. slova
\B
Kdekoliv kromě začátku a konce slova
Alternativy, seskupování, zpětné odkazy (reference) Odděluje několik dílčích výrazů |
^CZ najde CZ jen na začátku řetězce/řádku CZ$ najde CZ jen na konci řetězce/řádku \bCZ\b nenajde CZ ve slově CZ123 či 123CZ \BCZ najde CZ ve slově 12CZ43, ale ne v CZ12
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}(?
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
Pracovník přípravy
Vedoucí skenovacího pracoviště
Vedoucí validace
Operátor skeneru
Vedoucí pracoviště zpětné kompletace
Validátor
Pracovník zpětné kompletace
Vedoucí pracoviště archivace
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ých4 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ě. Tabulka 2 - Přehled vytěžovaných údajů
Název vytěžovaného pole Číslo dodavatele
10
Ano
DIČ5
12
Ne
CZ12345678
IČO6
12
Ano
12345678
Název dodavatele
50
Ano
Dodavatel, a.s.
Ulice
50
Ne
O. Peška 725
Město
50
Ne
Kladno
PSČ7
6
Ne
272 01
Datum zdanitelného plnění Datum vystavení dokladu Číslo dokladu
8
Ne
20081030
8
Ano
15
Ano
Max. délka
Povinné pole
Příklad
Poznámka v případě nenalezení dodavatele v databázi, bude doplněno číslo 1000000001 Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Slouží pro korektní určení čísla dodavatele a pro vizuální kontrolu při validaci. Zahraniční faktury toto pole bude prázdné
Primárně variabilní symbol, vypustit vše kromě čísel. Oříznout zprava (12345 bude 345)
5
DIČ – daňové identifikační číslo IČO – identifikační číslo organizace 7 PSČ – poštovní směrovací číslo 6
35
Název vytěžovaného pole Měna dokladu
Max. délka
Povinné pole
Příklad
3
Ano
CZK
Celková částka včetně DPH9 Typ dokladu
12,2
Ano
12345.50
4
Ano
INVO
Celková částka daně Základ daně při nulové sazbě daně Základ daně při sazbě snížené sazbě Hodnota daně při sazbě snížené sazbě Snížená sazba daně Základ daně při sazbě základní Hodnota daně při sazbě základní Sazba daně základní
12,2
Ne
56.00
12,2
Ne
100.00
12,2
Ne
200.00
12,2
Ne
18.00
12,2
Ne
9.00
12,2
Ne
200.00
12,2
Ne
38.00
12,2
Ne
19.00
Poznámka ISO kód měny8
Z číselníku, který bude dodán Pokud není uvedeno, pole bude prázdné (nesčítat)
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 9
Dle ISO normy 4217 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
Zdroj: Vlastní zdroj
Příklad struktury výstupního XML:
41
<ERROR_CODE_LIST> Mimo XML je možné exportovat metadata ve formátu CSV, IDOC10, ISDOC11 nebo TXT12. 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 SFTP13, 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 B2B14 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 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 11
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 mySAP15 od společnosti SAP, zejména modul FI16 určený pro finanční účetnictví a MM17 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
Počet přijatých faktur
2000 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) FI – modul mySAP určený pro finanční účetnictví 17 MM – modul mySAP určený pro skladové hospodářství 16
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. Graf 6 - Počet přijatých faktur za rok
Počet přijatých faktur za rok 12000 10000 8000 6000 Počet faktur
4000 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 EDI18. 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 Počet faktur
30000 20000 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 Faktura Příloha faktury Faktura včetně příloh
Průměrný počet stran 2,5 8 10,5
Zdroj: Vlastní zdroj
45
8.2 Analýza současného stavu (AS-IS) Analýza AS-IS není kvůli její velké obsáhlosti v diplomové práci uvedena do největších podrobností a je spíše uvedena na úrovni procesní. Zejména vlastní proces účtování v systému mySAP je velmi složitý a není předmětem této práce. Větší důraz je kladen na analýzu TO-BE, která je v této práci rozpracována do podstatně většího detailu.
8.2.1
Zpracování faktur
Zákazník vytvoří v systému SAP objednávku, která následně pomocí elektronického workflow projde schválením. Po úspěšném schválení je vystavena objednávka, která je v elektronické podobě formou přílohy e-mailu zaslána dodavateli. Dodavatel na základě této objednávky připraví a vyexpeduje zboží. Následně vystaví papírovou fakturu, kde uvede číslo obdržené objednávky. Z hlediska plnění objednávky mohou nastat tyto stavy: a) Objednávka je plně pokryta – v tomto případě se shoduje celková částka uvedená na objednávce s celkovou částkou uvedenou na faktuře. b) Objednávka je pokryta částečně - v tomto případě se neshoduje celková částka uvedená na objednávce s celkovou částkou uvedenou na faktuře. Zákazník obdrží vystavenou fakturu v papírové podobě na své centrální podatelně v sídle společnosti. Pracovníci podatelny každou přijatou fakturu zapíší do deníku přijatých faktur. Jednou denně mezi 16:30 a 17:00 předají přijaté faktury na místo k tomu určené na finanční oddělení. Hlavní účetní následující den roztřídí všechny přijaté faktury na tři dávky a každou z nich předá konkrétní účetní ke zpracování. Rozdělení probíhá na základě typu faktury, dodavatele a celkové fakturované částky. Účetní následně začne zpracovávat postupně všechny faktury v přidělené dávce. Denní výkon jedné účetní se pohybuje okolo 30 zpracovaných faktur.
8.2.2
Kontrola formálních náležitostí faktury
U každého zpracovávaného dokladu musí účetní zkontrolovat formální náležitosti faktury. Kontroluje, zda jsou na faktuře správně uvedeny veškeré údaje uvedené v kapitole 3.1. V případě, že jsou na faktuře v této oblasti kontrol nalezeny neshody, je faktura s průvodním dopisem obsahujícím popis nesrovnalosti navrácena dodavateli.
46
8.2.3
Předběžné pořízení faktury
Následujícím krokem je předběžné pořízení faktury v mySAP v MIR719. Účetní založí novou přijatou fakturu a z faktury ručně opíše všechny povinné údaje, které tato transakce vyžaduje. Každý zadávaný údaj má na sebe navázanou řadu systémových kontrol, kdy se především kontrolují formáty zadávaných dat a jejich logické hodnoty. Na základě zadaného čísla objednávky jsou automaticky importovány údaje z objednávky. Účetní následně provede kontrolu, případně korekci importovaných údajů, ze schválené objednávky. Po zadání veškerých potřebných údajů a spárování s objednávkou je předběžně pořízený doklad zaslán k zaúčtování. Na pozadí tohoto kroku následuje řada dalších logických kontrol, které vyhodnotí, zda je možné daný doklad zaúčtovat. V opačném případě je nutné jej vrátit dodavateli, či účetní k opravě, nebo zajistit jeho schválení. Schválení je nutné zajistit především v případech, kdy se liší cena uvedená na objednávce od ceny uvedené na faktuře na úrovni jednotkové ceny.
8.2.4
Fyzická archivace
Po úspěšném zaúčtování je opsáno číslo faktury, které automaticky přiřazuje systém mySAP každému zaúčtovanému dokladu. Číslo se opisuje na první stranu přijaté faktury. Následně jsou faktury seřazeny chronologicky dle tohoto čísla a založeny do šanonu. Šanony jsou uloženy v účtárně a jsou dále členěny dle měsíce a roku. Na hřbetu každého šanonu je uvedena číselná řada, měsíc a rok. V účtárně jsou archivovány vždy šanony daného kalendářního roku. Po účetní uzávěrce daného kalendářního roku jsou šanony přemístěny do archivní spisovny společnosti, která je umístěna v podzemních prostorách sídla. Po uplynutí skartační lhůty, která u těchto dokladů činí 10 let20, jsou skartovány.
19
MIR7 – transakce určená pro předběžné pořízení faktury v mySAP. 10 let – běžná skartační lhůta pro faktury. V dnešní době nicméně již řada společností skartuje přijaté faktury v kratší lhůtě, v ojedinělých případech ihned po naskenování. 20
47
8.3 Analýza požadovaného stavu (TO-BE) a návrh implementace Na základě analýzy u zákazníka byla navržena infrastruktura, která vychází z infrastruktury sdíleného střediska a ze současné infrastruktury zákazníka. Obrázek 17 – Návrh infrastruktury
Zdroj: Vlastní zdroj
Mail Service – bude zřízen dedikovaný P.O.BOX, na který budou doručovány veškeré faktury zákazníka. P.O.BOX bude zřízen poskytovatelem služby. Separation – manuální proces třídění došlé pošty z dedikovaného P.O.BOXu. Bude vyčleněna veškerá dokumentace, která není předmětem služby. Scan – skenování faktur na dokumentovém skeneru ve sdíleném středisku. Pro účely separace budou využívány čárové kódy. Archive – fyzické uložení naskenovaných dokladů do archivních boxů a uložení do dlouhodobého archivu dle skartační lhůty. Paper shredder – skartace dokumentů po uplynutí skartační lhůty Recognition servers – automatické vytěžení údajů z naskenovaných faktur a aplikace nastavených validačních pravidel. V této fázi také probíhá párování s číselníky dodanými zákazníkem. Validation – kontrola automaticky vytěžených údajů z dokladu, případné manuální dopárování s číselníky dodavatele v případě, že předchozí krok nebyl úspěšný. Release servers – tvorba XML a PDF, které budou následně předány zákazníkovi.
48
SFTP server - slouží pro předání dat zákazníkovi. Odesílání dat bude prováděno pomocí SFTP klienta, kdy na straně vytěžovacího centra bude SFTP server a na straně zákazníka bude klient pro stahování dat.
8.4 Detailní popis procesu TO-BE 8.4.1
Převzetí dokumentů
Poskytovatel služby zřídí samostatný dedikovaný P.O.BOX pro tento projekt. Zasílací adresu poskytne zákazníkovi, který zajistí u svých dodavatelů přesměrování relevantních dokladů na danou adresu. P.O.BOX bude denně vybírán odpovědným vyškoleným pracovníkem poskytovatele služby v ranních hodinách mezi 9:00 a 10:00. O každém výběru bude proveden záznam, který bude obsahovat počet převzatých zásilek a podpis odpovědného pracovníka. Po přechodnou dobu zajistí zákazník zasílání relevantních dokladů na pracoviště poskytovatele služby kurýrní službou. Součástí dodávky bude seznam zasílaných dokladů umožňující kontrolu vyškoleným pracovníkem poskytovatele služby.
8.4.2
Separace dokumentů
Po doručení zásilek na pracoviště poskytovatele služby následuje separace jednotlivých dokumentů. Separaci budou provádět vyškolení pracovníci poskytovatele služby podle předem vzájemně odsouhlasených metodických pokynů. Dokumenty budou rozděleny na čtyři základní skupiny: doklady určené k digitalizaci a rozpoznání v českém jazyce (faktury, dobropisy…) doklady určené k digitalizaci a rozpoznání v jiném než českém jazyce (faktury, dobropisy…) doklady určené k digitalizaci a zaslání e-mailem (opis faktury, upomínky…) dokumenty určené rovnou ke skartaci bez digitalizace (reklamní letáky…) Doklady z prvních tří skupin budou při separaci vyjmuty z obálek, rozešity a nakonec opatřeny čárovým kódem. Čárový kód bude nalepen vždy pouze na první straně dokladu a na místě, kde nedojde k přelepení nebo zkreslení důležitých údajů. Pokud takovéto místo na dokladu nebude, čárový kód bude nalepen na prázdný list A4, který bude vložen před první stranu dokladu. 49
Specifikace čárového kódu: Typ čárového kódu
Code 39
Tvar čárového kódu
YYNNNNNN, kde YY=rok přijetí dokladu a NNNNNN je genericky vzrůstající řada
Příklad čárového kódu
13000001
Specifikace štítků: Výška
3cm
Šířka
5cm
Barva
bílá
Dokumenty ze čtvrté skupiny budou rovnou uloženy do archivačního boxu k tomu určenému. Během pilotního provozu bude tato archivační krabice předávána zákazníkovi k posouzení obsažených dokumentů a potvrzení správnosti zařazení dokumentů rovnou ke skartaci bez jakékoliv digitalizace a následného zpracování. Po uplynutí pilotního provozu budou tyto dokumenty rovnou skartovávány.
8.4.3
Skenování dokladů
Skenování bude prováděno na pracovišti vybaveným produkčními skenery. Veškeré skenovací linky jsou osazeny produktem Kofax VirtualReScan Professional zajišťujícím maximální možnou kvalitu naskenovaných dokladů. Digitalizaci budou provádět vyškolení pracovníci poskytovatele podle předem vzájemně odsouhlasených metodických pokynů. Skenovat se budou veškeré doklady určené k digitalizaci a to včetně veškerých příloh až do velikosti A3. Dokumenty většího formátu než je A3 budou individuálně řešeny ve spolupráci se zákazníkem. Pro separaci jednotlivých dokladů bude sloužit čárový kód nalepený při třídění dokumentů. Parametry skenování: Rozlišení vertikální
300DPI
Rozlišení horizontální
300DPI
Barevná hloubka
1bitová (černobílá)
Velikost stránky
automatický ořez dle skutečné velikosti dokumentu 50
Doklady budou skenovány dávkově. Po naskenování se automaticky vytiskne průvodní list k dávce. Zde je uvedeno unikátní ID21 dávky v rámci zpracování ve středisku poskytovatele služby, název dávky a datum založení dávky. Průvodka je fyzicky přiložena k dokladům a společně uložena do připraveného archivačního boxu.
8.4.4
Rozpoznání dat
Tento krok probíhá zcela automaticky na serverech poskytovatele služby a to bez jakékoliv interakce uživatelů. Dle předem nadefinovaných pravidel budou z dokladů vytěženy potřebné údaje. V této fázi zpracování rovněž proběhne automatické doplnění hodnot ze zákazníkem poskytnuté databáze dodavatelů.
8.4.5
Databáze dodavatelů
Databáze bude poskytována na denní bázi v nočních hodinách. K přenosu dat bude opět využit SFTP server. Formát předávané databáze bude v podobě CSV exportovaném ze systému mySAP. CSV soubor bude obsahovat hlavičku s názvy sloupců a jako oddělovač jednotlivých údajů bude použit středník (;). Metadata CSV souboru budou tvořit údaje z databáze zákazníka v přesném pořadí, jak je uvedeno níže: ID Nazev_dodavatele DIC ICO Ulice Mesto PSC Stat Důležité je, aby předávaná databáze dodavatelů neobsahovala duplicitní záznamy. Předávaná databáze bude dále obsahovat tzv. Dummy záznam, který bude použit v případě, že daný dodavatel není nalezen v poskytnuté databázi a přesto od něj dorazila faktura ke zpracování. 21
ID – identifikační číslo
51
Příklad CSV souboru databáze dodavatelů včetně Dummy záznamu: ID;Nazev_dodavatele;DIC;ICO;Ulice;Mesto;PSC;Stat 0012546735;Dodavatel 1;CZ23434247;23434247;Státní 657/1;Praha;14000;CZ 9999999999;Dummy;CZ99999999;99999999;Dummy 1;Dummy;99999;CZ
8.4.6
Rozpoznávaná pole a jejich definice
Při rozpoznávání se doklady dělí na šest základních skupin a na rozdělení závisí i počet rozpoznávaných polí a jejich definice. Vytěžovaná pole jsou detailně popsána v příloze 1 této práce. Níže v kapitole jsou jen popsány rozdílnosti v závislosti na typu dokladu. Tuzemské materiálové doklady v české měně Nevytěžují se řádkové položky Tuzemské materiálové doklady v cizí měně Nevytěžují se řádkové položky Vytěžuje se daňový přehled a cena celkem v české měně Zahraniční materiálové doklady Nevytěžují se řádkové položky Datum zdanitelného plnění se nebude vytěžovat, bude předána prázdná hodnota Tuzemské režijní doklady v české měně Vytěžují se řádkové položky Tuzemské režijní doklady v cizí měně Vytěžují se řádkové položky Vytěžuje se daňový přehled a cena celkem v české měně Zahraniční režijní doklady Vytěžují se řádkové položky Datum zdanitelného plnění se nebude vytěžovat, bude předána prázdná hodnota Kód daně na úrovni řádkových položek se nebude vytěžovat, bude předána zpět pevně stanovená hodnota
52
8.4.7
Číselníky použité při vytěžování
V této kapitole jsou popsány jednotlivé číselníky používané při vytěžování dokladů. ISO kód měny Číselník bude obsahovat standardní ISO kódy měn jako např. CZK, EUR. Tento číselník bude vytvořen poskytovatel služby. Tabulka 4 – ISO kódy měn
ISO kód CZK EUR USD
Popis Česká koruna Měna eurozóny Americký dolar Zdroj: Vlastní zdroj
Kód daně Číselník používaný při vytěžování řádkových položek. Na základě vytěžené sazby daně bude doplněn adekvátní kód daně. Tento číselník bude vytvořen poskytovatelem služby. Tabulka 5 – Kódy daně
SAP kód B2 I3 I5 I9
Popis EU - nákup zboží z EU - 19% Tuzemská plnění přijatá - 19% Tuzemská plnění přijatá - 9% Případy nerelevantní pro DPH - vstup (0%) Zdroj: Vlastní zdroj
Druh dokladu Číselník používaný při vytěžování typu dokladu. Na základě určení typu dokladu bude doplněn adekvátní mySAP kód. Tento číselník bude vytvořen poskytovatelem služby s tím, že potřebné kódy ze systému mySAP dodá zákazník. Tabulka 6 – Druh dokladu
SAP kód INVO CRME PRIN DENO COIN
Popis Faktura přijatá Opravný daňový doklad (dříve dobropis) Zálohová faktura Vrubopis Souhrnná faktura Zdroj: Vlastní zdroj
53
Měsíce Číselník sloužící pro korektní vytěžování datumů. Obsahuje slovní označení měsíce a jeho číselnou hodnotu. Níže je uvedena jen část číselníku. Tento číselník bude vytvořen poskytovatelem služby. Tabulka 7 - Měsíce
Název měsíce Leden Únor Březen Duben January February March April Jan Feb Mar Apr I II III IV
Číslo měsíce 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Zdroj: Vlastní zdroj
8.4.8
Kontrola dat – validace
V této části je popsána kontrola vytěžených dat ve validačním modulu KTM. Tímto modulem projde každý naskenovaný doklad, který je určen k vytěžení. Kontrolu vytěžených dat budou provádět vyškolení pracovníci poskytovatele služby dle předem vzájemně odsouhlasených metodických pokynů.
Na nevytěžené údaje, nebo na hodnoty, u kterých si nebyl rozpoznávací server jistý dle nastavených validačních pravidel, bude validátor upozorněn červeným ohraničením daného údaje. Systém jej nepustí dál, dokud neprovede kontrolu a potvrzení, případně opravu všech takto označených údajů.
54
Ukázka nevalidního pole určeného ke kontrole nebo k opravě: Obrázek 18 – Nevalidní pole
Zdroj: Vlastní zdroj
Ukázka validního pole: Obrázek 19 – Validní pole
Zdroj: Vlastní zdroj
V tomto kroku zároveň probíhá i automatické formátování jednotlivých údajů na požadované formáty popsané v příloze 1 této diplomové práce.
8.4.9
Formát předávání metadat a naskenovaných obrazů
Metadata, neboli vytěžené a zkontrolované hodnoty, budou předávány ve formátu IDOC. Naskenované doklady budou předávány ve formátu PDF/A. Pro pojmenování předávaných souborů bude použita hodnota čárového kódu nalepena na první straně dokladu. Příklad: 13000001.idc 13000001.pdf
8.4.10
Odesílání a přijímání dat
Komunikace mezi zákazníkem a vytěžovacím centrem bude zprostředkována pomocí protokolu SFTP, kdy na straně zákazníka bude provozován klient SFTP, který bude stahovat data ze střediska poskytovatele v pravidelných intervalech. Kvůli optimálnímu využívání datových linek zákazníka bude stahování prováděno v nočních hodinách mezi 1:00 a 5:00. Pro tyto účely bude využit jednoduchý skriptovatelný SFTP klient určený pro přenášení souborů, který je běžně dostupný na trhu. Tento klient bude nainstalován a zaskriptován na serveru zákazníka vyhrazeného pro stahování dat ze střediska poskytovatele.
55
8.4.11
Archivace dokladů
Doklady budou archivovány v archivačních krabicích. V každé krabici bude zároveň přiložen vytištěný seznam uložených dokladů. Jednoznačný identifikační údaj bude čárový kód nalepený na první stránce každého dokladu. Tento údaj bude zároveň sloužit pro vlastní dohledání originálu v rámci archivu. Pro dlouhodobou archivaci bude využit externí partner poskytovatele služby, který disponuje veškerým vybavením nutným pro provoz certifikované archivní spisovny tak, jak ukládá platná legislativa České republiky.
8.4.12
Správa dokumentů
Od okamžiku předání/převzetí dokumentů ke zpracování a úschově bude až do okamžiku fyzické likvidace dokumentů skartací zajišťována Vyhledávací a kurýrní služba, která zajistí požadovanou dostupnost nejen elektronických dokumentů do 24 hod. od objednání. V případě požadavku na zajištění originálu dokumentu budou nejprve vytvářeny fotokopie dokumentů, které jsou společně s fotokopií zápůjčního lístku potvrzeného oprávněnou osobou zakládány zpět do archivačního obalu. Originál dokumentu je oprávněným osobám obvykle distribuován externí kurýrní službou poskytovatele s garantovanou dobou doručení do 24 hod. resp. 3 pracovních dní od zadání požadavku Oprávněnou osobou klienta. Příjem požadavků na vyhledání a distribuci dokumentů je zajištěn poskytovatelem služby v pracovní dny v době od 8:30 do 16:30 hod na definované emailové schránky určené výhradně k tomuto účelu.
8.4.13
Skartace dokladů
Po uplynutí skartační lhůty definované zákazníkem (10 let) budou veškeré doklady důvěryhodně skartovány. Zákazníkovi bude vždy předán seznam takto skartovaných dokladů. I v tomto případě bude jednoznačným identifikátorem dokladu čárový kód. Skartaci dokladů budou provádět vyškolení pracovníci poskytovatele služby podle předem vzájemně odsouhlasených metodických pokynů. Důležitým prvkem celého procesu skartace je skartační řízení. Skartačním řízením se rozumí soubor činností a služeb spojených nejen s řádnou fyzickou likvidací resp. skartací dokumentů, ale zejména také s řádným výběrem archiválií a vyřazením převzatých nebo vytříděných dokumentů s uplynulou skartační lhůtou. A to za podmínek a v souladu s legislativou a interními pravidly a zvyklostmi klienta.
56
Nezbytnou podmínkou poskytování této služby je zpracovaná základní evidence dokumentů a přiřazení skartačních znaků a lhůt v rámci odborného posouzení dokumentů. Zákazníkovi je vystaven certifikát o provedení skartace dokumentů. Skartovaný materiál je následně využit jako druhotná surovina v papírenském průmyslu.
8.5 Časový harmonogram Časový harmonogram vychází ze skutečnosti, že se jedná o outsourcing ve sdíleném středisku, tzn., že veškerá infrastruktura je již vybudována a předmětem nasazení nového zákazníka je pouze úprava stávajícího prostředí. Celková implementace se skládá z těchto kroků: Analýza Návrh řešení Implementace řešení Testovací provoz Pilotní provoz Ostrý provoz Začátek harmonogramu je v den „D“. Jedná se zpravidla o datum, kdy dojde k oboustrannému podpisu smlouvy mezi zákazníkem a poskytovatelem služby. Uvedený harmonogram slouží pouze pro orientační posouzení časové náročnosti. Jeho reálná podoba je vždy závislá na konkrétních podmínkách a výsledku analýzy u zákazníka a v neposlední řadě na poskytnuté součinnosti ze strany zákazníka. Obrázek 20 - Harmonogram projektu
Zdroj: Vlastní zdroj
57
Základem úspěchu je oboustranné nepodcenění rozsahu činností. K realizaci je nutné přistoupit jako k plnohodnotnému projektu včetně veškerých zásad řízení projektu podle zvolené metodiky, např. PRINCE 222.
8.6 Reporting V průběhu poskytování služby bude poskytovatel zákazníkovi na pravidelné bázi předávat níže uvedené reporty sloužící ke kontrole poskytovatele a vyhodnocování SLA.
8.6.1
Přehled zpracovaných materiálových dokladů
Tento report bude obsahovat následující údaje a jeho forma bude CSV soubor: Seznam všech zpracovaných dokladů identifikovaných hodnotou čárového kódu Počet stran u každého dokladu Počet všech zpracovaných dokladů Počet všech stran Interval zasílání bude 1 × měsíčně e-mailem na dedikovanou e-mailovou adresu poslední den v měsíci a bude generován automaticky systémem poskytovatele.
8.6.2
Přehled zpracovaných režijních dokladů
Tento report bude obsahovat následující údaje a jeho forma bude CSV soubor: Seznam všech zpracovaných dokladů identifikovaných hodnotou čárového kódu Počet stran u každého dokladu Počet řádkových položek u každého dokladu Počet všech zpracovaných dokladů Počet všech stran Počet všech položek Interval zasílání bude 1 × měsíčně e-mailem na dedikovanou e-mailovou adresu poslední den v měsíci a bude generován automaticky systémem poskytovatele.
22
PRINCE 2 – jedna z možných metodik řízení projektů.
58
8.6.3
Přehled zpracovaných jiných dokumentů
Tento report bude obsahovat následující údaje a jeho forma bude CSV soubor: Seznam všech zpracovaných dokumentů určených pouze k digitalizaci a nikoliv rozpoznání identifikovaných hodnotou čárového kódu Počet stran u každého dokumentu Počet všech zpracovaných dokumentu Počet všech stran Interval zasílání bude 1 × měsíčně e-mailem na dedikovanou e-mailovou adresu poslední den v měsíci a bude generován automaticky systémem poskytovatele.
8.6.4
Přehled skartovaných dokladů
Tento report bude obsahovat následující údaje a jeho forma bude CSV soubor: Seznam všech skartovaných dokladů identifikovaných hodnotou čárového kódu Počet stran u každého dokladu Počet všech skartovaných dokladů Počet všech stran Interval zasílání bude 1 × měsíčně e-mailem na dedikovanou e-mailovou adresu poslední den v měsíci a bude generován automaticky systémem poskytovatele.
8.6.5
Přehled reklamací
Tento report bude obsahovat následující údaje a jeho forma bude CSV soubor: Seznam všech reklamovaných dokladů identifikovaných hodnotou čárového kódu Důvod reklamace Stav vyřízení reklamace Nápravné opatření Vyhodnocení SLA
59
Interval zasílání bude 1 × měsíčně e-mailem na dedikovanou e-mailovou adresu první den v měsíci následujícím po účtovaném měsíci a bude generován manuálně pracovníky poskytovatele. Report bude sloužit pro vyhodnocení SLA a případné uplatnění sankcí dle platně uzavřeného SLA.
8.7 Zabezpečení dat V této části je popsáno zabezpečení dat v rámci této implementace. Není zde detailně popsáno kompletní zabezpečení sdíleného střediska, jelikož některé části zabezpečení nejsou relevantní pro tuto implementaci.
8.7.1
Zálohování dat
Veškerá data předaná zákazníkovi (ZIP soubory) jsou zálohována na datovém úložišti, jehož obsah je 1x denně v nočních hodinách zálohován na datovou pásku. Zároveň 1x denně v nočních hodinách probíhá záloha databáze obsahující archiv vytěžených dat a databázi dodavatelů. Datové pásky jsou ukládány v sídle poskytovatele služby, tedy mimo prostory sdíleného střediska, v trezorech k tomu určených.
8.7.2
Automatická skartace dat
Zálohovaná data (ZIP23 soubory + databáze) jsou uchovávána po dobu maximálně 60 dnů. Po uplynutí této lhůty jsou automaticky skartována včetně všech médií obsahujících tato data. Během skartace je automaticky tvořen report obsahující seznam čárových kódů smazaných dokladů. Na vyžádání je možné tento seznam zákazníkovi poskytnout formou CSV souboru obsahující seznam skartovaných čárových kódů.
8.8 Zabezpečení sdíleného střediska V této kapitole je stručně popsáno zabezpečení sdíleného střediska určeného pro realizaci vzorové implementace. Z hlediska zákazníka by níže uvedené zabezpečení mělo znamenat standard při poptávání outsourcingových služeb tohoto rozsahu. Součástí zabezpečení by měl být i vypracovaný plán obnovy střediska v případě nenadálých událostí (disaster recovery plan, business continuity plan).
23
ZIP – jeden ze souborových formátů určených ke kompresi dat
60
8.8.1
Kamerový systém
Pracoviště sdíleného střediska je monitorováno 24 hodin 7 dnů v týdnu kamerovým systémem řádně registrovaným na Úřadu pro ochranu osobních údajů dle platné legislativy České republiky. Záznamové médium je uschováno ve vlastním uzamykatelném racku v serverovně s řízeným přístupem pracovníků. Kamery snímají veškeré prostory, kde dochází k manipulaci s dokumenty zákazníka (ze záznamu kamer není možné číst obsah zpracovávaných dokumentů) Kamerový systém je napojen na vlastní záložní zdroj energie Záznamy z kamerového systému se uchovávají po dobu 30 dní Kamery snímají 24 hodin denně, 7 dnů v týdnu
8.8.2
Docházkový systém
Pracoviště sdíleného střediska je vybaveno docházkovým a vstupním systémem. Každý pracovník disponuje vlastní přístupovou kartou s jednoznačnou identifikací pomocí unikátních ID. V rámci sdíleného střediska existují různé přístupové zóny. Každý pracovník má přístup jen na část pracoviště nezbytnou pro jeho vlastní práci. Docházkový systém slouží jednak k registraci pracovníka na pracovišti a dále k přehledu jeho odpracovaných hodin. Administrativní modul docházkového systému je obsluhován výhradně Site Managerem nebo jeho zástupcem.
8.8.3
Zabezpečovací a požární systém
Veškeré prvky zabezpečovacího a požárního systému jsou certifikovány NBÚ24. Zabezpečení a kontrola objektu sdíleného střediska je realizována smluvním vztahem s bezpečností agenturou, která je přítomna 24 hodin 7 dnů v týdnu včetně státních svátků. Dalším prvkem zabezpečení je systém EZS25. EZS a jeho stručná charakteristika: Magnetická čidla na všech oknech a dveřích objektu a to včetně vnitřních Pohybová čidla v každé místnosti sdíleného střediska
24 25
NBÚ – Národní bezpečnostní úřad EZS – elektronický zabezpečovací systém
61
GSM26 modul Napojení na PCO27 Dalším nezbytným bezpečnostním prvkem je protipožární ochrana. Ve sdíleném středisku je realizována optickokouřovými čidly, které zaznamenávají kouř nebo zvýšenou teplotu objektu nebo jeho částí.
26 27
GSM – globální systém pro mobilní komunikaci PCO – pult centrální ochrany
62
9 Návrh SLA Tato kapitola navrhuje parametry poskytovaných SLA, penalizaci za nedodržení těchto parametrů (rozumí se sankce v podobě smluvních pokut) a omezující podmínky, za kterých jsou tato SLA platná. Smluvní pokuty definované v SLA jsou kalkulovány jako procentuální část z měsíční platby za poskytované služby v měsíci, ve kterém došlo k porušení SLA. Výsledná výše smluvní pokuty bude započtena v nejbližší měsíční platbě za poskytované služby. Měřícím intervalem pro hodnocení SLA je vždy jeden kalendářní měsíc. Výše smluvní pokuty pro dané období je součástí akceptačního protokolu. Pokud u vyhodnocovaných parametrů SLA, které nejsou pod penalizací a jsou vyhodnocovány, dojde k jejich porušení tři a vícekrát v období šesti po sobě jdoucích měsíců, budou tyto parametry zařazeny do penalizačního modelu. V rámci SLA je vždy dohodnuto několik hodnotících kritérií dodávané kvality služby.
9.1 Parametry pro provoz Provoz bude zajištěn v následujícím režimu: Tabulka 8 – Garantovaná dostupnost služby
Parametr Garantovaný režim provozu Garantovaná dostupnost služby Akceptovatelný výpadek
Hodnota Pracovní dny 95 %
Vyhodnocováno Ano
1 den v měsíci
Ano
Zdroj: Vlastní zdroj Tabulka 9 – Penalizační model
Úroveň porušení Výpadek 2 dny v měsíci Výpadek nad 2 dny v měsíci
Stupeň 1 4
Zdroj: Vlastní zdroj
9.2 Chybovost zpracování 9.2.1
Parametry kvality a chybovosti
V tabulce 8 je návrh parametrů kvality a maximální povolené chybovosti. Systematická chyba, která se opakovaně projeví ve zpracování, je považována za jedno porušení parametrů SLA v rámci zpracování jednoho dne.
63
Tabulka 10 – Parametry kvality a chybovosti
Parametr
Popis
Kvalita obrazu, správnost roztřídění a vyhodnocení dokumentu
Pro porovnání kvality naskenovaných dokladů je k dispozici Etalon kvality. Jedná se o elektronický soubor naskenovaných jednotlivých dokladů (dokumentů). Podle tohoto Etalonu je zákazník oprávněn poukázat na nekvalitně naskenovaný obraz dokumentu (dokladu). Nečitelností se rozumí nemožnost vizuálního vyčtení informací z dokumentu. V případě nečitelnosti provede dodavatel služby resken dokumentů zdarma. DIČ, vč. Identifikace dodavatele. Údaj se počítá jako jeden celek, tzn., že více chyb v jednom údaji se považuje za jednu chybu Např. popis v řádkové položce. Údaj se počítá jako jeden celek, tzn., že více chyb v jednom údaji se považuje za jednu chybu. Hodnocena je srozumitelnost textu, chybějící interpunkce či jiné speciální znaky se nepovažují za chybu. Dále se za chybu nepovažuje záměna malých písmen za velká a naopak. Cena celkem, tabulka daní, ceny v jednotlivých řádkových položkách. Údaj se počítá jako jeden celek, tzn., že více chyb v jednom údaji se považuje za jednu chybu. Včetně data splatnosti z hlavičky faktury.
Hlavičkové údaje mimo částky Textové údaje
Číselné údaje
Povolená chybovost 0,5 % nečitelných obrazů (viz tabulka 11)
1 % chybných údajů (viz tabulka 12) 3 % chybných údajů (viz tabulka 13)
0,5% chybných údajů (viz tabulka 14)
Zdroj: Vlastní zdroj
V případě nedodržení povolené chybovosti je její výše rozdělena na jednotlivé úrovně a následně oceněna jedním z penalizačních stupňů, které jsou popsány v kapitole 9.3.1. Tabulka 11 – Penalizační model pro parametr kvalita obrazu
Úroveň porušení > 0,5 % ≤ 3 % >3%≤5% >5%
Stupeň 2 3 4 Zdroj: Vlastní zdroj
64
Tabulka 12 – Penalizační model pro parametr hlavičkové údaje mimo částky
Úroveň porušení >1%≤3% >3%≤5% >5%
Stupeň 2 3 4 Zdroj: Vlastní zdroj
Tabulka 13 – Penalizační model pro parametr textové údaje
Úroveň porušení >3%≤6% >6% ≤8% >8%
Stupeň 2 3 4 Zdroj: Vlastní zdroj
Tabulka 14 – Penalizační model pro parametr číselné údaje
Úroveň porušení > 0,5 % ≤ 3 % >3%≤5% >5%
Stupeň 2 3 4 Zdroj: Vlastní zdroj
9.2.2
Způsob hodnocení
Za porušení SLA se považují případy, kdy dojde k překročení výše uvedených parametrů. Hodnocení probíhá na základě zjištění chyby auditem nebo kontrolou, při každodenním zpracování (fyzická kontrola naskenovaného dokladu, dodaných dat v zaslaných souborech apod.).
9.3 Penalizační model 9.3.1
Ocenění penalizačních stupňů
Smluvní pokuta je vždy vypočítávána z aktuální částky fakturace za službu za daný měsíc (viz tabulka 15) a je o tuto částku ponížena. Smluvní pokuty za jednotlivé parametry se sčítají. Tabulka 15 – Ocenění penalizačních stupňů
Stupeň 1 2 3 4
Smluvní pokuta 5% 10 % 15 % 25 % Zdroj: Vlastní zdroj
65
9.3.2
Omezení smluvních pokut
Souhrnná výše smluvních pokut za jeden měsíc nepřekročí 30 % z měsíční fakturace. V případě, že je nedodržením naplněno více úrovní porušení konkrétního penalizačního modelu, pokuta je kalkulována a uplatňována pouze dle nejvyššího stupně. Pro účely aplikace smluvních pokut se jedním porušením rozumí sled porušení v rámci jedné škodní události. Jde o případ, kdy se jedna příčina projeví v jedné kategorii služeb např. na pěti naskenovaných dokladech. Toto je pak považováno za jedno porušení SLA parametrů. Pokud tedy dodavatel služeb porušil své závazky ve více kategoriích služeb, uplatní se v daném měsíci smluvní pokuty jednotlivě v rámci každé takové kategorie služeb.
9.3.3
Omezení SLA pro pilotní provoz
V případě, že počet přijatých dokladů přesáhne denně množství 200 kusů, každý další doklad bude zpracován následující den. Toto ustanovení platí po dobu prvního měsíce od zahájení zpracování. Zahájení zpracování bude započato přenesením první dávky digitalizovaných (oskenovaných a vytěžených) dokladů. Zároveň po tuto dobu nebude probíhat hodnocení jednotlivých parametrů SLA.
66
10 Závěry a doporučení Diplomová práce popsala jen jeden z několika možných způsobů zpracování některých finančních dokladů. Vždy záleží na konkrétním zákazníkovi a jeho prostředí, kterou variantu zvolí. Jestli zvolí zpracování finančních dokladů formou outsourcingu, nebo zda se rozhodne celou technologii implementovat přímo ve svém prostředí. Rozsah popsané oblasti je velmi široký a z tohoto důvodu nebylo cílem popsat veškeré dílčí kroky v daném procesu zpracování do největších detailů. Práce byla napsána tak, aby dané problematice porozuměl především čtenář vycházející z finančního oddělení společnosti. Na vzorové implementaci byly aplikovány teoretické poznatky z dané oblasti aby čtenářům přiblížila kompletní proces zpracování včetně dopadu na jejich stávající proces zpracování. I přes veškerá opatření pro zaručení maximální bezpečnosti a kvality služby, jakou jsou různé certifikáty nebo SLA, bude pravděpodobně u řady čtenářů stále převládat určitý pocit nejistoty při myšlence na zavedení outsourcingu zpracování finančních dokladů. Jako u každého outsourcingu, i zde platí pravidlo, že zákazník musí mít ve svého poskytovatele služby důvěru. Doporučuji věnovat maximální možnou pozornost vlastnímu výběrovému řízení na poskytovatele služby, ověření si jeho referencí a vždy požádat o možnost prohlídky sdíleného střediska, které bude určené pro zpracování dokladů.
67
11 Seznam použité literatury 11.1 Tištěné monografie [1]. Bruckner, Tomáš a Voříšek, Jiří. Outsourcing informačních systémů. 1. Vydání. Praha : BSC Praha, 1998. ISBN 80-247-1278-4.
11.2 Elektronické monografie, webovská sídla, databáze a počítačové programy [2]. ABBYY. FineReader. ABBYY. [Online] [Citace: 10. 2 2011.] http://finereader.abbyy.com/. [3]. Activa. Activa. [Online] [Citace: 23. 3 2011.] http://obchod.activa.cz/produkt/ironmountain-dg-01a-archivacni-krabice-18157/. [4]. AIIM. Capture and Business Process: drivers and experiences of content-driven processes. [Online] AIIM, 2010. [Citace: 2. 4 2011.] http://downloads.vertmarkets.com/files/downloads/e218d5e9-8a30-4de6-b5353d7b94f28826/industrywatch-capture-emc.pdf. [5]. Fujitsu. Scanners. Fujitsu. [Online] 1995 – 2011. [Citace: 24. 1 2011.] http://www.fujitsu.com/global/services/computing/peripheral/scanners/. [6]. Helcl, Petr. Systematic. Systematic. [Online] 2011. [Citace: 22. 3 2011.] http://www.systematic.cz/. [7]. Hora, Michal. Tajemství zkratky SLA. SystemOnLine. [Online] 2001 – 2011. [Citace: 14. 1 2011.] http://www.systemonline.cz/outsourcing-ict/tajemstvi-zkratky-sla1.htm. [8]. Jungmann Michal. Dotaz na CSV soubory. FJFI ČVUT v Praze [Online] 2002. [Citace: 14.4.2011] http://tereza.fjfi.cvut.cz/pipermail/fanda/2002-June/006993.html [9]. Kodak. Document Scanners. Kodak Document Imaging. [Online] 2010. [Citace: 24. 1 2011.] http://graphics.kodak.com/docimaging/us/en/products/document_scanners/index.htm. [10]. Kodys. Čárový kód. Kodys. [Online] 2009. [Citace: 25. 1 2011.] http://www.kodys.cz/carovy-kod.html. [11]. Kofax. Kofax. [Online] 1992 – 2011. [Citace: 10. 2 2011.] www.kofax.com. [12]. Ministerstvo Financí ČR. Zákon o DPH. business center.cz. [Online] 1. 4 2004. [Citace: 13. 2 2011.] http://business.center.cz/business/pravo/zakony/dph/. 68
[13]. Panasonic. High Speed Scanner. Panasonic. [Online] 2011. [Citace: 24. 1 2011.] http://panasonic.net/pcc/products/scanner/. [14]. Pecka, Miroslav. Regulární výrazy. Regulární výrazy. [Online] 2005 – 2008. [Citace: 13. 2 2011.] http://www.regularnivyrazy.info/. [15]. ReadSoft. Software products. ReadSoft. [Online] 2010. [Citace: 13. 2 2011.] http://www.readsoft.com/software-products/. [16]. Top Image Systems. Top Image Systems. [Online] 2008. [Citace: 13. 2 2011.] http://www.topimagesystems.com/. [17]. Uživatelé Wikipedia – http://cs.wikipedia.org/w/index.php?title=OEM_produkce&action=history. OEM produkce. Wikipedia. [Online] 24. 11 2010. [Citace: 10. 1 2011.] http://cs.wikipedia.org/wiki/OEM_produkce. [18] Uživatelé Wikipedia – http://cs.wikipedia.org/w/index.php?title=ASCII&action=history. OEM produkce. Wikipedia. [Online] 5.4.2011. [Citace: 14.4.2011.] http://cs.wikipedia.org/wiki/ASCII [19] Uživatelé Wikipedia – http://cs.wikipedia.org/w/index.php?title=DPI&action=history. OEM produkce. Wikipedia. [Online] 4.4.2011. [Citace: 14.4.2011.] http://cs.wikipedia.org/wiki/Dpi [20] Uživatelé Wikipedia – http://cs.wikipedia.org/w/index.php?title=Tagged_Image_File_Format&action=his tory. OEM produkce. Wikipedia. [Online] 8.2.2011. [Citace: 14.4.2011.] http://cs.wikipedia.org/wiki/TIFF [21] Uživatelé Wikipedia – http://cs.wikipedia.org/w/index.php?title=Portable_Document_Format&action=his tory. OEM produkce. Wikipedia. [Online] 8.1.2011. [Citace: 14.4.2011.] http://cs.wikipedia.org/wiki/Pdf [22]. WebFinance. Business dictionary. Business dictionary. [Online] 2011. [Citace: 22. 3 2011.] http://www.businessdictionary.com/definition/optical-characterrecognition-OCR.html. [23]. Worldwide Market for Document Capture Software. Spencer, Harvey. 2010. [24]. Xerox. Dokumenty efektivně. [Online] Xerox Czech Republic, 2010. [Citace: 25. 1 2011.] http://www.dokumentyefektivne.cz. [25]. Xerox. Office products. Xerox Scanners. [Online] [Citace: 25. 1 2011.] http://www.xeroxscanners.com/en/en/.
69
12 Definice pojmů a zkratek V následující tabulce 16 jsou uvedeny definice pojmů a zkratek používaných v této práci. Tabulka 16 – Definice pojmů a zkratek
Pojem American Standard for Information Interchange
Zkratka ASCII
Comma Separated Value
CSV
Dokument
-
Dots per Inch
DPI
Finanční doklad nebo jen doklad
-
Images per minute
ipm
Kofax Capture
KC
Kofax Transformation Modules
KTM
Kofax VirtualReScan List
VRS -
Optical Character Recognition
OCR
Original Equipment Manufacturer OEM
Pages per minute
ppm
Portable Document Format
PDF
Service Level Agreement
SLA
70
Popis Kódová tabulka, která definuje znaky anglické abecedy, a jiné znaky používané v informatice [18] Soubor, kde každému záznamu databáze odpovídá jeden řádek, a jednotlivá pole jsou oddělená čárkou nebo středníkem [8] Dokument je ucelený celek, který se skládá z jednoho nebo z více listů. Údaj určující, kolik obrazových bodů (pixelů) se vejde do délky jednoho palce [19] Typický představitel jednoho typu dokumentu. Do této skupiny patří faktura, dobropis. Jednotka používaná pro uvedení rychlosti skenerů. Hodnota udává počet naskenovaných stran za minutu. Software pro digitalizaci a vytěžování dokumentů Nadstavbový modul pro Kofax Capture Software pro optimalizaci obrazů List je dílčí částí dokumentu a skládá se ze dvou stran, přičemž jedna z nich může být prázdná. Optické rozpoznání znaků je metoda převodu obrázků s textem na jednotlivé znaky. [22] Způsob licencování software, kdy při zakoupení hardware získává zákazník automaticky zdarma i licenci na daný software. [17] Jednotka používaná pro uvedení rychlosti skenerů. Hodnota udává počet naskenovaných listů za minutu. Souborový formát vyvinutý firmou Adobe pro ukládání dokumentů nezávisle na softwaru i hardwaru, na kterém byl pořízen [21] Dohoda o úrovni poskytovaných služeb [7]
Pojem Strana Tag Image File Format
Zkratka TIF
Popis Strana je dílčí částí listu. Jeden ze souborových formátů pro ukládání rastrové počítačové grafiky [20]
Zdroj: Vlastní zdroj
71
13 Seznam použitých tabulek, schémat, obrázků, grafů a příloh 13.1 Seznam použitých tabulek Tabulka 1 - Metaznaky regulárních výrazů .................................................................... 30 Tabulka 2 - Přehled vytěžovaných údajů ....................................................................... 35 Tabulka 3 - Průměrný počet stran .................................................................................. 45 Tabulka 4 – ISO kódy měn ............................................................................................. 53 Tabulka 5 – Kódy daně................................................................................................... 53 Tabulka 6 – Druh dokladu .............................................................................................. 53 Tabulka 7 - Měsíce ......................................................................................................... 54 Tabulka 8 – Garantovaná dostupnost služby .................................................................. 63 Tabulka 9 – Penalizační model....................................................................................... 63 Tabulka 10 – Parametry kvality a chybovosti ................................................................ 64 Tabulka 11 – Penalizační model pro parametr kvalita obrazu ....................................... 64 Tabulka 12 – Penalizační model pro parametr hlavičkové údaje mimo částky ............. 65 Tabulka 13 – Penalizační model pro parametr textové údaje ......................................... 65 Tabulka 14 – Penalizační model pro parametr číselné údaje ......................................... 65 Tabulka 15 – Ocenění penalizačních stupňů .................................................................. 65 Tabulka 16 – Definice pojmů a zkratek.......................................................................... 70
13.2 Seznam použitých schémat Schéma 1 – Organizační struktura .................................................................................. 32 Schéma 2 – Proces toku finančních dokladů v rámci digitalizačního centra ................. 33 Schéma 3 – Proces validace............................................................................................ 40
13.3 Seznam použitých obrázků Obrázek 1 – Původ důvodů pro outsourcing .................................................................. 11 Obrázek 2 – Čárový kód typu Code 128 ........................................................................ 17 Obrázek 3 – Čárový kód typu Code 39 .......................................................................... 17 Obrázek 4 – Čárový kód typu Interleaved 2 of 5 ........................................................... 18 Obrázek 5 – Proces práce s dokumenty v externí archivní spisovně.............................. 20 Obrázek 6 – Archivační krabice ..................................................................................... 21 Obrázek 7 – Schéma detekce dvojího podání ................................................................. 22 Obrázek 8 – Originální dokumenty ................................................................................ 25 Obrázek 9 – Dokumenty naskenovány bez VRS............................................................ 26 Obrázek 10 – Dokumenty naskenovány s VRS.............................................................. 26 Obrázek 11 – Ukázka definice hledaného řetězce pomocí regulárních výrazů .............. 29 Obrázek 12 – Ukázka definice klíčových slov a jejich pozice ....................................... 29 Obrázek 13 – Ukázka definice oblasti hledání ............................................................... 29 Obrázek 14 – Výsledek Fuzzy Search ............................................................................ 37 72
Obrázek 15 – Definice typu finančního dokladu ............................................................ 39 Obrázek 16 – Příklad výstupu exportovaných dat na adresářové struktuře ................... 41 Obrázek 17 – Návrh infrastruktury................................................................................. 48 Obrázek 18 – Nevalidní pole .......................................................................................... 55 Obrázek 19 – Validní pole .............................................................................................. 55 Obrázek 20 – Harmonogram projektu ............................................................................ 57
13.4 Seznam použitých grafů Graf 1 – Proč společnosti volí outsourcing digitalizace dokumentů .............................. 11 Graf 2 - Předmět outsourcingu v oblasti digitalizace ..................................................... 12 Graf 3 - Tržní podíl dokumentových skenerů v Evropě (2007) ..................................... 23 Graf 4 – Tržní podíl jednotlivých společností na trhu v dávkovém zpracování............. 27 Graf 5 – Přehled přijatých faktur po měsících................................................................ 43 Graf 6 - Počet přijatých faktur za rok ............................................................................. 44 Graf 7- Počet přijatých faktur za jednotlivé roky ........................................................... 45
13.5 Seznam příloh Příloha 1 – Specifikace vytěžovaných polí
73
