UNIVERSITEIT VAN AMSTERDAM JANUARI, 2011 Versie 0.7
Automatisch informatie verkrijgen uit kassabonnen
Bachelorscriptie Informatiekunde Faculteit der Natuurwetenschappen, Wiskunde en Informatica Januari 2011
Rogier Schutte Student ID 5801850
[email protected]
W. N. H. Jansweijer Scriptiebegeleider
[email protected]
SAMENVATTING Het blijkt dat het automatisch uitlezen van kassabonnen een handige toevoeging kan zijn voor het ontwikkelen van een declaratiesysteem. Qua literatuur blijkt dat er geen direct onderzoek gedaan is naar het automatisch uitlezen van bonnen. Facturen en wetenschappelijke artikelen worden echter wel al op grote schaal automatisch uitgelezen en hier was dan ook reeds wetenschappelijk onderzoek naar gedaan. Het blijkt echter dat het commerciële belang van deze oplossingen een rol speelt in de hoeveelheid informatie die erover beschikbaar is. De literatuur die er namelijk over geschreven is blijkt zich zeer op de vlakte te houden. Er wordt nergens ingegaan op de details van de systemen. Wel bleek dat er gebruik wordt gemaakt van zones binnen de documenten. Deze zones helpen om een verwachting uit te spreken over de inhoud ervan. Dit is ook wat ik geprobeerd heb voor het automatisch uitlezen van bonnen. Door het ontdekken van zones binnen de bonnen kon ik een verwachting uitspreken over de inhoud ervan en dat hielp bij het automatisch uitlezen van de bonnen. Voor declaraties blijkt het handig om een lijst met producten uit een bon te kunnen halen. Op deze manier is het namelijk mogelijk om een declaratiecategorie te ontdekken en daarvoor een suggestie te geven bij het indienen van een onkosten declaratie. Het bleek dat zones hielpen bij het ontdekken van een lijst met producten nadat er in de bonnen drie zones waren ontdekt. Uiteindelijk kon ik analyseren hoe deze technieken geïntegreerd konden worden in het declaratiesysteem.
2
Inhoud 1. INTRODUCTIE ...................................................................................................... 5 2. ONDERZOEKSVRAGEN EN DOELEN .............................................................. 7 3. ACHTERGROND ................................................................................................ 10 3.1 OCR ................................................................................................................ 10 3.2 Declaraties....................................................................................................... 10 3.3 Bonnetjes......................................................................................................... 11 3.4 Declaraties....................................................................................................... 11 3.5 Informatie extractie uit facturen...................................................................... 11 3.6 Informatie extractie uit wetenschappelijke artikelen ...................................... 13 3.7 Informatie extractie uit kassabonnen .............................................................. 13 3.8 Een bevredigend resultaat ............................................................................... 14 4. METHODE (algemeen) ........................................................................................ 15 4.1 Data verzameling ............................................................................................ 15 4.2 Oefenset / Testset ............................................................................................ 16 5. METHODE (totaalbedragen) ................................................................................ 16 5.1 Totaalbedragen in bonnen ............................................................................... 16 6. RESULTATEN (totaalbedragen).......................................................................... 17 7. CONCLUSIE (totaalbedragen) ............................................................................. 17 8. METHODE (zones) .............................................................................................. 18 8.1 Lijst met producten ......................................................................................... 20 8.2 Bedrijfsnaam ................................................................................................... 21 9. RESULTATEN (zones) ........................................................................................ 21 9.1 Zones ontdekken ............................................................................................. 21 9.1.1 Soorten problemen: .................................................................................. 21 9.2 Lijst met producten (met zonering): ............................................................... 22 9.2.1 Soorten problemen ................................................................................... 22 9.3 Lijst met producten (zonder zonering):........................................................... 22 9.4 Resultaten voor bedrijfsnaam ......................................................................... 23 10. CONCLUSIE ...................................................................................................... 23 10.1 Zones ............................................................................................................. 23 10.2 Producten (met zones)................................................................................... 24 10.3 Producten (zonder zones) .............................................................................. 25 10.4 Bedrijfsnamen ............................................................................................... 26 11. DISCUSSIE ........................................................................................................ 27 12. REFERENTIES .................................................................................................. 28 13. BIJLAGEN ......................................................................................................... 28 3
13.1 Bijlage 1: Aanbieders van automatisch uitlezen van bonnen ....................... 28 13.1.1 NeatReceipts .......................................................................................... 28 13.1.2 Shoeboxed.com ...................................................................................... 29 13.1.3 ProOnGo ................................................................................................ 30 13.2 Bijlage 2: Pseudocode ................................................................................... 30
4
1. INTRODUCTIE In februari 2010 begon SecuReceipt met het automatiseren van het declaratieproces binnen bedrijven. Door het maken van een foto kan een werknemer de gemaakte kosten declareren bij zijn baas. Vervolgens moeten in de mobiele applicatie (SR//Expenses) de declaratiegegevens worden ingevuld. De foto van de bon in combinatie met de declaratiegegevens wordt vervolgens opgestuurd naar een online systeem. Hier vindt de rest van de workflow plaats waar een manager is aangewezen om de declaraties goed te keuren. De belangrijkste kracht van deze methode is de snelheid waarmee het declareren via SR//Expenses gebeurt. De ouderwetse declaratiemethodes werken vaak met papieren declaratieformulieren die door veel handen binnen een bedrijf. Nu is er tijdwinst te behalen bij de werknemer die minder tijd hoeft te steken in het invullen van de declaratieformulieren. Ook een manager zal een tijdsbesparing krijgen doordat de declaraties veel sneller geaccordeerd kunnen worden. De grootste tijdsbesparing ligt echter bij de administratie die nu geen declaraties handmatig meer hoeft in te voeren in bedrijfssoftware. Toch zou de snelheid van declareren nog verder verhoogd kunnen worden. De gebruikersvriendelijkheid voor de werknemer zou namelijk verhoogd worden wanneer er suggesties gegeven kunnen worden voor de declaratiegegevens. Hierdoor hoeft de gebruiker op zijn mobiele telefoon minder handelingen te doen doordat het invullen van de declaratiegegevens reeds automatisch zijn verkregen uit de bon. Een belangrijk item binnen de Human-Computer Interaction is ‘efficiency’ (Holzinger, 2005). In de applicatie van SR//Expenses is het op dit moment nodig om gegevens zoals het totaalbedrag, categorie, valuta en datum in te vullen. De ‘efficiency’ van deze handeling wordt verkleind doordat het toetsenbord kleiner is dan een toetsenbord van een desktop computer of laptop, maar ook doordat het toetsenbord minder feedback geeft aan de gebruiker.
5
Qua gebruikersvriendelijkheid zou het dus een vooruitgang kunnen betekenen wanneer er minder gegevens hoeven worden ingevuld in de mobiele applicatie. Het automatisch uitlezen van kassabonnen is voor het doen van declaraties dus een goede toevoeging. Ik wil in dit project dan ook bijdragen aan het onderzoek naar het automatisch uitlezen van bonnen. In de volgende sectie (2) van dit verslag zal ik uitweiden over het doel van mijn onderzoek en de daaraan gekoppelde onderzoeksvragen. Door in sectie 3 een theoretisch kader te scheppen zal ik antwoorden krijgen op een deel van de onderzoeksvragen die gesteld zijn in sectie 2. In sectie 4 zal ik beknopt ingaan op de methodologie die gebruikt is om kassabonnen automatisch uit te lezen. Vervolgens zal ik in sectie 5 en 6 ingaan op respectievelijk de resultaten en de conclusies die ik daaruit kan trekken terwijl ik kijk naar de doelen die ik in dit project gesteld heb.
6
2. ONDERZOEKSVRAGEN EN DOELEN Dit onderzoek is opgezet om bij te dragen aan het onderzoek naar het uitlezen van bonnen. Aangezien er weinig tot geen wetenschappelijke artikelen zijn verschenen omtrent het automatisch uitlezen van bonnen zal dit een onderzoek moeten worden waarin ik exploratief te werk ga en technieken en algoritmes zal proberen te gebruiken uit aangrenzende vakgebieden. Zo zal ik kijken naar het automatisch uitlezen van facturen en het uitlezen van wetenschappelijke artikelen. Om sturing te geven aan mijn onderzoek zijn er een aantal onderzoeksvragen opgesteld. Mijn hoofdvraag zal zich vooral richten op bonnen in het algemeen en herbergt ook gelijk mijn doelstelling: OV1: Kan ik automatisch informatie uit kassabonnen lezen? Uit de literatuur over facturen (Dengel & Klein, 2002) en wetenschappelijke artikelen (Hollingsworth, Lewin, & Tidhar, 2005) blijkt dat de inhoud van deze documenten voorafgaand aan het uitlezen ervan in zones wordt opgedeeld. Ook blijkt dat hierdoor verwachtingen kunnen worden uitgesproken over de inhoud van deze zones. Met deze wetenschap in mijn achterhoofd heb ik ook het verloop van mijn onderzoek bepaald. Maar alvorens over te gaan op het specifiek uitlezen van de bonnen is het nodig na te denken over de prestaties waaraan de scripts moeten voldoen om in de praktijk te worden toegepast. Mijn deelvraag luidt hier dan ook: OV1.1: Wanneer is er sprake van bevredigende prestaties bij het correct uitlezen van informatie uit bonnen? Om dit te onderzoeken zal ik rekening houden met de literatuur en het systeem waarin het later geïntegreerd zou moeten worden. Na het onderzoeken van de prestaties
7
(bijvoorbeeld succespercentage) van het te ontwikkelen systeem zal ik mij concentreren op het uitlezen van de bonnen zelf. Voordat ik onderzoek kan doen naar het nut en de mogelijkheden van zones in bonnen wil ik een aantal voorbereidingen doen. Het exploratieve karakter van dit onderzoek zorgt tegelijkertijd voor een nogal open einde en daarmee dus een breed onderzoeksgebied. Omdat ik hierdoor niet goed een einddoel kan bepalen heb ik ervoor gekozen om eerst een aantal voorbereidingen te treffen en daarop mijn verdere onderzoek te baseren. Om handigheid te krijgen met bonnen en het uitlezen ervan en om een fundament te leggen voor de rest van mijn onderzoek wil ik eerst kijken naar totaalbedragen in bonnen. Mijn deelvraag wordt dan ook: OV2: Kan ik automatisch totaalbedragen uit kassabonnen lezen? Dit gedeelte zal mij veel informatie verschaffen over de rest van mijn onderzoek omdat ik hiermee familiair raak met bonnetjes en een kans krijg om de mogelijkheden te bekijken. Het is handig om eerst eens goed te kijken naar de bonnetjes zelf. De volgende vraag is dan handig om mijzelf af te vragen: OV2.1: Hoe kan de context binnen de bon gebruikt worden bij het destilleren van het totale geldbedrag? De ervaringen en resultaten uit het onderzoek tot dan toe zijn gebruikt bij het vaststellen van de onderzoeksvragen voor de rest van mijn onderzoek. Samen met de wetenschappelijke literatuur over het automatisch uitlezen van wetenschappelijke artikelen en facturen (Sectie 3) zorgde dit voor mijn keuze voor zones in bonnen. Dit onderdeel van mijn onderzoek is het belangrijkste maar ook gelijk het meest exploratieve deel. In dit onderdeel maak ik gebruik van de inspiratie uit de wetenschappelijke literatuur maar is geen van de stappen letterlijk theoretisch onderbouwd.
8
Mijn eerste vraag op dit gebied is dan ook een zeer algemene vraag. OV3: Helpen zones bij het automatisch uitlezen van bonnen? Om dit te bepalen zal ik eerst moeten onderzoeken of het überhaupt mogelijk is zones te herkennen in bonnen. OV3.1: Is het mogelijk om zones te herkennen in bonnen? Dit onderdeel zal bestaan uit het ontwikkelen van een methode om zones te herkennen. Hiervoor zal ik ten eerste moeten vaststellen hoeveel zones ik wil ontdekken en aan welke eisen deze zones moeten voldoen. Vervolgens moet ik een methode bedenken en implementeren. Dit zal hoogstwaarschijnlijk gepaard gaan met veel ‘trial and error’ aangezien hier nog geen documentatie over beschikbaar is. Wanneer ik zones heb ontdekt op de bonnen wil ik deze gaan gebruiken in mijn zoektocht naar informatie op bonnen. Uit onderzoek over het automatisch categoriseren van declaratiebonnen (Bothof, 2011) blijkt dat de declaratiecategorie te bepalen is aan de hand van een lijst met producten. Om deze producten automatisch uit een bon te lezen wil ik gaan onderzoeken of de zones bij deze actie een wezenlijk verschil maken ten OV3.2: Helpt het bepalen van zones in bonnen bij het verkrijgen van een lijst met producten? Ook blijkt uit het onderzoek van Mark Bothof (Bothof, 2011) dat de aanbieder van de bon (‘vendor’) een handige indicator kan zijn voor de zoektocht naar de declaratiecategorie. Dit lijkt mij dan ook een interessant onderdeel. OV3.3: Helpt het bepalen van zones in bonnen bij het verkrijgen van een bedrijfsnaam uit de bon?
9
3. ACHTERGROND 3.1 OCR Optical Character Recognition (OCR) is een techniek om tekst te herkennen op afbeeldingen. Hiernaar wordt al ongeveer 20 jaar onderzoek gedaan. Dit blijkt bijvoorbeeld uit een onderzoek uit 1992 (Pieraccini, 1992) Hierin worden technieken uit Automatic Speech Recognition (ASR) gebruikt bij het onderzoek naar OCR. De technieken voor OCR zijn in de loop der jaren steeds verbeterd. Zo is het onderzoek van Pieraccini voortgezet en zijn de technieken overgenomen in recentere onderzoeken (Bazzi, Schwartz, & Makhoul, 1999). Toch is het nog geen perfecte techniek. Vooral wanneer de bonnen scheef, onderbelicht of onscherp op de foto staan zal deze techniek moeite hebben met het herkennen van tekst. De foto’s in het systeem van SR//Expenses zullen waarschijnlijk regelmatig van deze kwaliteit zijn omdat ze grotendeels met de camera van een mobiele telefoon gemaakt zijn. Om het onderzoek naar de algoritmes voor het automatisch uitlezen van kassabonnen te bevorderen zal ik hier geen rekening houden met de gebreken van OCR. In sectie 4 zal ik uitweiden over de gevolgen daarvan in mijn onderzoek.
3.2 Declaraties Om een declaratie met het systeem van SR//Expenses te doen zijn standaard een aantal gegevens nodig. Een opsomming: •
Valuta
•
Totaalbedrag
•
Btw-bedrag(en)
•
Categorie
•
Omschrijving (Voor welk bedrijf/project de kosten zijn gemaakt)
•
Datum
•
Betaalmethode
In het ideale geval wordt er een systeem gemaakt waarbij al deze gegevens automatisch worden herkend en ingevuld voor de gebruiker. Echter, om al deze gegevens van een bon te halen zullen we te maken met een aantal problemen.
10
3.3 Bonnetjes In dit onderzoek richt ik mij op kassabonnen. Bij een declaratie is het namelijk noodzakelijk de kassabon in te dienen als bewijs van de onkosten. Dus zal het voor SR//Expenses het handigst zijn om automatisch kassabonnen uit te lezen. Op kassabonnen staat over het algemeen veel informatie. We onderscheiden bijvoorbeeld bedragen, een datum, en tijd, een btw aanduiding, het bedrijf (vendor), de contactgegevens van het bedrijf, de slogan van het bedrijf, et cetera. De verschillen tussen bonnen zijn groot. Zo kan het per bon verschillen welke informatie erop staat, maar ook waar de informatie staat op de bon
3.4 Declaraties Voor een declaratie is maar een beperkte hoeveelheid van deze informatie nodig. Om het totaalbedrag van een bonnetje af te lezen zullen bijvoorbeeld een keuze moeten maken uit meerdere bedragen. Er staan immers niet alleen bedragen op een bon om het totaalbedrag weer te geven maar ook om subtotalen, btw, kortingen, wisselgeld, productprijzen, et cetera te vermelden. Voor een declaratie zijn deze gegevens verplicht en we gaan er dan ook vanuit dat ze op de bon staan. Ook zijn er gegevens belangrijk voor een declaratie die niet letterlijk op een bon staan vermeld. Een categorie of omschrijving van een declaratie is over het algemeen lastig te bepalen. Om een categorie te bepalen zou het helpen om een lijst met producten uit de bon te scannen of om aanbieder van de bon (‘vendor’) te gebruiken (Bothof, 2011).
3.5 Informatie extractie uit facturen Facturen hebben op het eerste gezicht veel overeenkomsten met bonnen. In dit onderzoek gaat het om bonnen en de reeds bestaande systemen voor het uitlezen van facturen zouden daarbij kunnen helpen. Zulke systemen worden Invoice Reading Systems (IRS) genoemd. Het is echter zo dat er weinig gepubliceerd is op wetenschappelijk niveau. Waarschijnlijk speelt daar het commerciële belang van de technieken een grote rol. Men probeert waarschijnlijk de dieperliggende technologieën geheim te houden. Het gevolg hiervan is dat er op het gebied van 11
facturen een vrij oppervlakkig inzicht wordt gegeven in de gebruikte methodes en technieken. Hierdoor krijgen we alleen een soort overzicht van veelgebruikte systemen (Klein, Agne, & Dengel, 2004) en een globale uitleg met ‘flowchart’ van een van die systemen (Dengel & Klein, 2002). Het onderzoek naar de veelgebruikte systemen (Klein, Agne, & Dengel, 2004) geschiedde op de Duitse markt en bracht een elftal aanbieders van dergelijke ‘invoice-reading’ software naar boven. De uitleg van het systeem smartFIX (Dengel & Klein, 2002) was nuttig bij het begrip van de systeemarchitectuur. Ook werd duidelijk wat de stappen waren die achtereenvolgens werden genomen om van een gescande afbeelding tot een volledige analyse van de data te komen. Hieronder een stappenplan: 1. Image pre-processing: De foto wordt verbeterd door lijnen te verwijderen, de foto recht te zetten (deskew) en de fotot in de goede richting (rotation) te plaatsen. 2. Classification: Hier wordt in documenten onderscheid gemaakt door ontwerpovereenkomsten, herkenning van tabellen of patronen die door ‘machine-learning’ of ‘user-definitions’ zijn toegevoegd. Ook kijken ze naar semantische overeenkomsten met deze patronen en naar lettergrootte. 3. Information extraction: hier wordt door middel van scripts informatie verkregen uit de documenten. De scripts worden onderverdeeld in simpele-, matig complexe – en complexe scripts. 4. Improvement: hierin wordt ‘redeneerbare informatie’ toegeveogd en worden mensen ingezet om resultaten te verbeteren. Bij redeneerbare informatie kunnen we bij facturen bijvoorbeeld denken aan een koppeling met een database waarin alle aankopen van een bedrijf staan vermeld.
Op deze manier krijgen we een globaal overzicht van de stappen die worden doorlopen om een factuur te verwerken. Echter, helaas gaan de wetenschappelijke publicaties niet verder in op de dieperliggende technologieën. Deze technologieën blijven waarschijnlijk geheim vanwege de commerciële voordelen die dat oplevert. Met deze technieken is immers veel geld te verdienen omdat ze voor grote bedrijven 12
een enorme besparing kunnen opleveren. We kunnen dus alleen een aantal lessen trekken uit de globale termen die er gebruikt worden. In het artikel van Klein et al. (2005)wordt onderscheid gemaakt in twee vormen van ‘Information Spotting’. We kunnen namelijk kijken naar de ‘template’ of de ‘freeform’. De template handelt over de verschillende onderdelen in een factuur en de plaatsing daarvan. De freeform bekijkt hoe het onderdeel er daadwerkelijk uitziet. Het menselijk brein kan deze twee manieren goed combineren en er dus een redelijk nauwkeurige analyse van maken. Mensen kunnen dus gemakkelijk de benodigde informatie eruit lezen. De systemen die gemaakt zijn om automatisch informatie uit facturen te lezen zullen dus als doel hebben om deze twee vormen van ‘information spotting’ zo goed mogelijk te combineren (Summers, 1998).
3.6 Informatie extractie uit wetenschappelijke artikelen Wetenschappelijke artikelen worden meer en meer op het web gepost (Hollingsworth, Lewin, & Tidhar, 2005). De digitale universiteitsbibliotheken zijn hier een voorbeeld van. Ook Google Scholar is een voorbeeld. Meestal worden de documenten in PDF aangeboden (Hollingsworth, Lewin, & Tidhar, 2005) In de wetenschap wordt er veel door specialisten gezocht in literatuur op specifieke vakgebieden. Een voorbeeld hiervan zijn de medische specialisten. Hollingsworth et al. bespreken een processing framework (PTX) om hiërarchische tekststructuren te ontdekken in wetenschappelijke artikelen. Er wordt hier gebruik gemaakt van een stappenplan om dit te bewerkstelligen. Men probeert eerst de documenten om te zetten in tekst door middel van OCR (stap 1), vervolgens wordt geprobeerd om regio´s en zones te ontdekken door gebruikt te maken van ´autozoning’(stap 2). Als laatste worden specifieke templates van wetenschappelijke tijdschriften vergeleken met de zones en regio’s uit stap twee (stap 3).
3.7 Informatie extractie uit kassabonnen Literatuur over OCR van bonnen in het bijzonder is er niet. Dergelijke technologieën worden wel degelijk toegepast. Dat blijkt uit de lijst met bedrijven die dit 13
commercieel hebben toegepast (zie bijlage 1). Ook hier zal waarschijnlijk het commerciële belang een rol spelen. Het zijn immers commerciële bedrijven en met het automatisch uitlezen van bonnen wordt geld verdiend omdat het een besparing oplevert voor potentiële klanten. Zonder literatuur uit dit specifieke vakgebied is het lastiger om een begin- en eindpunt te bepalen voor dit onderzoek. De aard van dit onderzoeken zal dientengevolge dan ook veel exploratiever zijn dan onderzoeken in vakgebieden waarin door andere onderzoekers al veel onderzoek verricht is. Een exploratief karakter komt vaker voor bij het onderzoeken in gebieden waarover nog niet veel over gepubliceerd is (Steinert, 2009). Het gebrek aan literatuur uit dit vakgebied zorgt er ook voor dat er een breed gebied ontstaat waarin ik zou kunnen onderzoeken. Samen met het exploratieve karakter van dit onderzoek zal het nodig zijn om bij voorbaat mijn onderzoek af te bakenen. In de volgende sectie zal ik hier verder op ingaan.
3.8 Een bevredigend resultaat De aanleiding van dit onderzoek ligt bij het systeem van SR//Expenses. Als ik rekening houdt met de implementatie van deze technieken is het nodig om mezelf af te vragen hoe goed dit OCR-systeem zou moeten werken om te kunnen worden geïmplementeerd in SR//Expenses. Het is dus nodig om af te vragen op welke manier dergelijke systemen zullen worden geïmplementeerd in het declaratiesysteem. De functionaliteit bestaat nu uit het maken van een foto van een bon en het opsturen van deze foto met informatie die door de gebruiker zelf is toegevoegd. Een gebruiker krijgt na het maken van een foto van het bonnetje een scherm waarin allerlei gegevens ingevuld dienen te worden om de declaratie te completeren. De invulvelden zullen leeg zijn zodra de gebruiker het scherm ziet. Vervolgens is het nodig het toetsenbord te gebruiken om de gegevens aan te vullen. We zouden het OCR-systeem kunnen zien als een tool om suggesties te geven. Na het maken van de foto van de bon wordt deze geanalyseerd door het systeem van SR//Expenses en zouden er suggesties gedaan kunnen worden voor de informatie die 14
moet worden ingevuld. In het geval van een foute suggestie zullen er geen extra handelingen plaatsvinden om dit ongedaan te maken behalve het eventueel deleten van de suggestie. Wanneer er echter een goede suggestie gedaan wordt dan hoeft de gebruiker bij dat veld helemaal geen handelingen uit te voeren en kan er verder gegaan worden met het completeren van de informatie. Alleen wanneer we te maken krijgen met een ‘luie’ gebruiker kunnen de suggesties problemen gaan geven. Een luie gebruiker kijkt dan niet naar de ingevulde gegevens en stuurt de declaratie gelijk op. Wanneer er dus een foute suggestie gegeven wordt dan verzendt de gebruiker verkeerde gegevens naar zijn manager. Op voorhand lijkt me dit echter gemakkelijk op te vangen door duidelijke instructies en feedback van de applicatie. In principe kan het dus geen kwaad wanneer er een foute suggestie gedaan wordt en is het een aanwinst voor het declaratiesysteem wanneer het OCR-systeem een goede suggestie geeft. We hebben dus al een voldoende resultaat wanneer er zeer kleine percentages goed zijn. Toch willen we ook een bevredigend resultaat en dat is, gebaseerd op inschattingen met betrekking tot de investering en de tijdswinst die het oplevert voor een gebruiker, rond de 70 procent (OV1.1). Dit percentage is vrij hoog omdat we in dit onderzoek geen rekening zullen houden met de gebreken van OCR.
4. METHODE (algemeen) 4.1 Data verzameling De data die ik heb gebruikt voor mijn onderzoek bestaat uit een database met daarin 56 bonnen. Ik heb mijn onderzoek afgebakend door selectief te zijn in welke bonnen ik gebruikt heb en ook hoe ik ze gebruikt heb. Ik zal mij namelijk niet bezighouden met de kwaliteit van de omzetting van afbeelding naar tekst (OCR). Dit doe ik omdat ik alleen de gratis tools op internet tot mijn beschikking heb en daarvan de kwaliteit achterloopt op de betaalde systemen. Daarom zal ik gaan werken met de perfecte tekst op de kassabonnen. In de praktijk betekent dat er nog aardig wat werk is gaan zitten in 15
het perfectioneren hiervan. Ik heb immers wel gebruik gemaakt van OCR systemen om mijn bonnen uit te lezen, maar om de perfecte tekst te krijgen waren er nog veel verbeteringen nodig. Een verdere afbakening zal ik doen door mij alleen te focussen op bonnen met Nederlandse taal. Naast een manier om mijn onderzoek af te bakenen is het ook gemakkelijker om aan Nederlandse bonnen te komen dan buitenlandse.
4.2 Oefenset / Testset In de database zal ik onderscheid maken in twee sets met bonnen. Ik krijg zo een oefenset en een testset. De 20 bonnen in de oefenset zal ik gebruiken om algoritmes te bedenken en te implementeren waarmee ik de benodigde informatie uit bonnen kan halen. Vervolgens zal ik deze algoritmes nog eens testen op 36 bonnen uit de testset. Deze zullen zorgen voor de resultaten.
5. METHODE (totaalbedragen) 5.1 Totaalbedragen in bonnen Allereerst wil ik bekijken hoe het mogelijk is om zo simpel mogelijk geldbedragen uit bonnen te halen. In bijlage 1 heb ik in pseudocode een overzicht gegeven van de scripts die ik heb geschreven. Hierin is te zien dat ik als eerst zoek naar 5 strings (woorden) in een bon: • te betalen • totaal • tot. • tl • tota Zodra het script een van deze woorden vindt wordt er gekeken of er een bedrag op dezelfde regels staat als het gevonden woord. Voor het bedrag zoekt het script naar 1 of meer getallen gevolgd door een komma of een punt, die vervolgens gevolgd worden door twee getallen. Het zou echter kunnen zijn dat de combinatie van een van de woorden met een bedrag meerdere keren voorkomt. In dat geval wordt er gekeken naar het hoogste bedrag en dat wordt vervolgens als totaalbedrag aangemerkt. 16
Het zou natuurlijk kunnen zijn dat er geen combinatie van een bedrag en een van de bovenstaande zoekwoorden wordt gevonden. In dat geval wordt er gekeken naar een van de volgende zoekwoorden in combinatie met een bedrag: • contant • kontant • eur • pin Hierna word took weer het hoogste bedrag gezocht voor het bepalen van het totaalbedrag. Door te zoeken naar twee sets met woorden was het mogelijk om een hiërarchie aan te brengen in de zoekwoorden. Ik wil dus liever zoeken naar de eerste 5 woorden dan de laatste 4. Mijn resultaten heb ik verkregen door een vergelijking te maken met het, door mijzelf bepaalde, goede bedrag. Om een waarde aan de resultaten te geven werk ik in dit geval met slagingspercentage.
6. RESULTATEN (totaalbedragen) Het belangrijkste doel bij dit onderdeel was, naast het uitlezen van de totaalbedragen, dat dit gold als een vingeroefening voor de volgende onderdelen van mijn onderzoek. Samen met de resultaten zouden de ervaringen moeten gaan zorgen voor een goed voorstel voor mijn vervolgonderzoek. De methode voor dit onderdeel bleek verassend goed te werken. Na de eerste keer draaien behoefte het algoritme overigens nog wat aanpassingen maar het resultaat was zeer bevredigend. In 92% ( n = 36 ) procent van de gevallen bleek het correcte bedrag te worden gevonden. Na analyse van de gevallen waarin het fout ging bleken de problemen vooral te liggen aan de reguliere expressies. Dezen zijn dus nog voor verbetering vatbaar.
7. CONCLUSIE (totaalbedragen)
17
Om automatisch totaalbedragen uit te lezen heb ik een algoritme gebruikt wat goed werkte. Het percentage van goede totaalbedragen was hoog (91,7%) en dat was een bevredigend resultaat (zie sectie 3.8). Met een aantal aanpassingen zou het echter nog beter kunnen werken. Zo zouden de reguliere expressies nog verder kunnen worden verbeterd om woorden en bedragen nog beter te kunnen vinden. Het is dus mogelijk om totaalbedragen uit bonnen te halen door ze automatisch uit te lezen (OV2). De context rondom het totaalbedrag is duidelijk gebruikt door naar woorden te kijken die op dezelfde regel staan als het daadwerkelijke totaalbedrag. Ik kijk bijvoorbeeld naar het woord totaal en zoek daarbij op dezelfde regel naar een bedrag. Bij meerdere combinaties hiervan zoek ik naar het hoogste bedrag. (OV2.1) Ik heb dus antwoorden kunnen krijgen op deze onderzoeksvragen. Ook zijn de prestaties van het script voor totaalbedragen bevredigend. Ik ben daarna begonnen aan het schrijven aan het onderzoeksvoorstel voor het tweede gedeelte van mijn onderzoek. Op het idee gebracht door de manier waarop wetenschappelijke artikelen worden uitgelezen (Hollingsworth, Lewin, & Tidhar, 2005) wilde ik me gaan bezighouden met zones in bonnen.
8. METHODE (zones) Allereerst wilde ik kijken of het überhaupt mogelijk is om bonnen onder te verdelen in zones. Echter, het was nog totaal niet duidelijk waaraan de zones zouden moeten voldoen. Ik werd geïnspireerd door het begrip auto-zoning van Hollingsworth (Hollingsworth, Lewin, & Tidhar, 2005) en de manier van aanbrengen van 3 zones (top, body, footer). Verder was het enerzijds nodig dat er een voorspelling gedaan kon worden van de inhoud per zone. Anderzijds was het nodig om aan de hand van de tekst een altijd consistente zone-verdeling te krijgen. De eerste scripts keken naar het eerste en laatste bedrag op de bon. De regels waarop deze bedragen stonden werden respectievelijk de eerste en de laatste regel van de middelste zone van de bon. Hierna was het calculeren van de bovenste en onderste zone niet moeilijk meer. Voor de 18
bovenste zone namen we namelijk de bovenste regels van de bon tot de regel boven de eerste regel van de middelste zone. De eerste regel na de laatste regel van de middelste zone gold als eerste regel van de onderste zone. De laatste regel van de bon gold ook als laatste regel van de onderste zone. Voor de zones heb ik zelf de eisen bepaald. Over het algemeen wilde ik in de middelste zone de informatie die specifiek voor de desbetreffende bon is. Deze middelste zone gold als belangrijkste onderdeel omdat op basis van deze zone de andere zones werden berekend. Doordat ik voor deze aanpak gekozen had was het nodig om van tevoren te bepalen welke onderdelen ik per bon in de middelste zone verwachtte. Zo verwacht ik dat een van de volgende onderdelen in de middelste zone: • • • • •
Productinformatie Prijzen Totaalbedragen Subtotaalbedragen Btw-specificatie
Verder verwacht ik dat de volgende onderdelen in de header of footer staan: • • • • • • • •
bedrijfsnaam, logo contactgegevens datum slogan aanbiedingen woord van dank informatie met betrekking tot het ruilen van artikelen
Wanneer onderdelen niet in de verwachtte zone staan dan blijkt er iets fout. Bij alle foute onderdelen is het probleem geanalyseerd en is het onderverdeeld in groepen. Op deze manier kreeg ik een overzicht van de problemen en hun voorkomen (in percentages). Om te ontdekken of de zones daadwerkelijk van nut kunnen zijn bij het uitlezen van informatie ben ik gaan kijken of ik zones kon gebruiken bij het destilleren van een lijst met producten.
19
8.1 Lijst met producten Om een lijst met producten uit een bon te halen heb ik gebruik gemaakt van mijn onderverdeling in zones. Geïnspireerd door het onderzoek van Mark Bothof (Bothof, 2011) ben ik daarmee begonnen. Om aan deze doelstelling te voldoen verwachtte ik dat de lijst met producten in de middelste zone zou staan. Dit omdat alle bedragen ook in deze zone staan en de producten vaak worden vergezeld door een bedrag op dezelfde regel of de regel eronder. Met deze middelste zone ben ik aan de slag gegaan door te gaan zoeken op woorden van 3 letters of langer. Het gevolg hiervan was dat ik gelijk alle cijfers (bedragen, productcodes en stuksaanduiding) eruit haalde. Ook leestekens werden hierin niet meegenomen. De overgebleven lijst werd nog wel ‘vervuild’ door woorden die niet door konden gaan als onderdeel van de lijst met producten. Er bleek echter een goede mogelijkheid om de vervuilende woorden eruit te halen. Het filteren van deze woorden werd namelijk vergemakkelijkt doordat er in de middelste zone veel standaard woorden worden gebruikt die vaak te maken hebben met het eindbedrag, btw-bedrag of betaling. Woorden als totaal, pinbetaling en BTW zijn vrij standaard voor bonnen en de lijst met woorden die eruit worden gefilterd is dus niet erg lang. De resultaten die ik hieruit kreeg heb ik vergeleken met mijn eigen waarneming van producten op de bonnen. Vervolgens wilde ik bekijken of de zones een rol hadden gespeeld bij het verkrijgen van deze lijst. Dit heb ik gedaan door een script te schrijven die de lijst probeerde te verkrijgen door te kijken naar de volledige tekst van de bon. De verschillen heb ik opgenomen in mijn resultaten. Uit onderzoek (Bothof, 2011) blijkt dat ook de bedrijfsnaam op de bon (aanbieder van de bon) een goede indicatie kan zijn voor het bepalen van de declaratiecategorie. Dus heb ik mij gericht op het automatisch uitlezen van bedrijfsnamen op bonnen.
20
8.2 Bedrijfsnaam Om de bedrijfsnaam te vinden heb ik gekeken naar de top en footer. Uit eigen onderzoek blijkt dat deze twee zones de bedrijfsnaam herbergen. Om de bedrijfsnaam te vinden heb ik gekeken naar het webadres die op de bon stond vermeld. Hieruit kon ik, als er überhaupt een url op stond, de bedrijfsnaam uit afleiden. Verder dan dit is mijn onderzoek echter niet gegaan. In mijn conclusie geef ik nog suggesties om hierop verder te onderzoeken.
9. RESULTATEN (zones) Mijn resultaten laten zich kenmerken door percentages gekoppeld aan de prestatie van de scripts. Met behulp van de data en de scripts die ik in de vorige sectie besproken heb zijn de resultaten tot stand gekomen.
9.1 Zones ontdekken Om te analyseren wat de prestaties waren van het algoritme en de scripts heb ik gekeken naar de problemen die optraden bij het uitvoeren van de scripts om zones te ontdekken. 9.1.1
Soorten problemen:
De problemen zijn onder te verdelen in twee categorieën. Zo zijn er problemen die te maken hebben met het algoritme. In die gevallen is het algoritme niet toereikend. Ook zijn er problemen die veroorzaakt worden door fouten in de scripts waarin het algoritme geïmplementeerd is. Twee problemen werden veroorzaakt doordat het algoritme niet toereikend was. Zo waren er 6 gevallen (17%) waar het product hoger stond dan het eerste bedrag. Hierdoor kwam het product niet in de middelste zone. Dat was echter wel het doel. Ook werden er soms bedragen gevonden die niet relevant waren voor de middelste zone. Hierdoor kwam er in 2 gevallen (16%) informatie in de middelste zone die daar niet thuishoorde. Een voorbeeld hiervan was een vermelding van een aanbieding van een cd met bijbehorende prijs. Deze informatie was in de footer geplaatst maar kwam door de vermelding van het bedrag toch in de middelste zone terecht.
21
Ook waren er fouten in het script te bespeuren. Zo bleek in 6 gevallen (17%) geen goede bedragen gevonden door de reguliere expressies in het script. Hierdoor werd er in de middelste zone informatie geplaatst die er niet in hoorde of werd er te weinig informatie in de middelste zone vermeld. Om te kijken of de zones ook echt nuttig waren heb ik geprobeerd om uit de bon een lijst met producten te krijgen waarvoor ik gebruik maakte van de zonering van de bon.
9.2 Lijst met producten (met zonering): Voor het ontdekken van de lijst met producten ging ik ervan dat uit de lijst met producten zich in de middelste zone bevond. Door deze aanname waren veel fouten in de lijst het gevolg van problemen bij het ontdekken van zones.
9.2.1
Soorten problemen
In deze lijst met problemen zullen we dan ook vaak dezelfde percentages tegenkomen als bij de zonering. Zo ontbreken er producten in de lijst (17%) waardoor deze niet compleet is. Dit is dus het gevolg van de een fout bij het ontdekken van de zones. Vaak ontbreekt bij deze fouten namelijk het eerste product. In die gevallen is het dus een probleem dat het algoritme voor de zonering niet toereikend is en er producten hoger staan dan het eerste bedrag in de bon. Ook blijkt er vervuiling opgetreden in de middelste zone als gevolg van fouten die opgetreden waren bij het bepalen van zones. Doordat er soms meer informatie in de middelste zone wordt opgenomen dan verwacht treedt er hierdoor vervuiling op. De vervuiling bestaat uit woorden die niet in de productenlijst horen en die ook niet in de lijst met woorden staan die eruit worden gefilterd. Dit gebeurde in 17% van de gevallen.
9.3 Lijst met producten (zonder zonering): Om te bekijken of het gebruik van zones zou helpen bij het verkrijgen van een lijst met producten, heb ik ook geprobeerd om dit te doen door te kijken naar de gehele tekst van de bon. 22
De vervuiling was bij deze manier van werken stukken groter. Zo hadden we in 72% van de gevallen de bedrijfsnaam, in alle gevallen adresgegevens, in 19% van de gevallen een slogan in 58% van de gevallen een url, in 56% van de gevallen een bedankje, bij 58% van de gevallen werd er informatie gegeven over het ruilen van producten en in 72% van de gevallen was er sprake van een aanbieding, naam van medewerker of andere informatie.
9.4 Resultaten voor bedrijfsnaam Het uitlezen van de bedrijfsnaam door middel van de url (webadres) was door de specifieke vorm goed te herkennen en gaf voor zowel de zonering als de volledige tekst hetzelfde resultaat. In 56% van de gevallen was er namelijk sprake van een goed uitgelezen url.
10. CONCLUSIE Is het mogelijk om automatisch informatie te lezen uit kassabonnen? Uit het eerste deel van mijn onderzoek blijkt al dat totaalbedragen zijn uit te lezen door te kijken naar het de tekst in de bonnen. Door handig gebruik te maken van de context is het mogelijk om ze automatisch uit te lezen. Het is dus mogelijk om informatie automatisch uit te lezen uit kassabonnen (OV1). Ook wil ik weten of zones helpen bij het automatisch uitlezen van informatie.
10.1 Zones Bij het onderzoeken van de zones bleek dat de prestaties van het script belangrijk zijn voor de rest van mijn onderzoek. Dit werkt immers door in de rest van het onderzoek omdat dit in zijn geheel op de zones gebaseerd is. Verder in het onderzoek ga ik namelijk kijken of ik een lijst met producten en een bedrijfsnaam automatisch kan lezen uit de bon met behulp van zones. Dit is ook om te kijken of zones kunnen helpen bij het uitlezen van informatie.
23
Het algoritme bleek goed te werken om zones te ontdekken. Toch waren de prestaties niet zo goed als bij totaalbedragen. Dit komt vooral doordat het geheel ingewikkelder en meer experimenteel is. Toch is duidelijk te stellen dat het mogelijk is om zones te herkennen in bonnen (OV3.1). Hoewel dit geïnspireerd is door de literatuur, werd het ontdekken van zones alleen maar mogelijk gemaakt doordat ik zelf de zones gedefinieerd heb (zie sectie 8). Er was immers geen standaard voor beschikbaar vanuit de literatuur. Het doel was om de zones van nut te laten zijn bij het automatisch uitlezen van bonnen. Dit kon alleen maar getoetst worden door het te implementeren en bijvoorbeeld te proberen een lijst met producten uit de bon te halen.
10.2 Producten (met zones) Bij het genereren van een lijst met producten heb ik als eerste gebruik gemaakt van de zones die ik heb ontdekt. Ik verwachtte de producten in de middelste zone en dit was dus ook het gedeelte van de bon dat ik heb gebruikt voor het genereren van deze lijst. De lijsten met producten bleken een goede weergave te geven van de producten die daadwerkelijk op de bon te lezen waren. Door het gebruik van de zones werden ook de problemen die daarbij kwamen kijken overgeërfd. Al gauw werd het duidelijk welke problemen vanuit de zones van invloed waren op de lijsten met producten. Zo waren vooral de problemen waar het algoritme niet toereikend was goed terug te vinden. Een voorbeeld hiervan is het missen van producten aan de bovenkant van de lijst. De lijst is in sommige gevallen korter doordat de zones producten missen. Deze zones missen de eerste producten omdat de regel met daarop het bedrag soms onder het product staat waarop het van toepassing is. Op deze manier werd het bovenste product dus niet weergegeven en verscheen deze dus ook niet in de lijst. Maar ook waren er problemen doordat er ‘niet relevante bedragen’ gevonden werden (zie sectie 9.1.1). Door dit problemen werden er bedragen (en dus ook producten) gevonden die niet relevant bleken voor de middelste zone. Een voorbeeld hiervan is de aanbieding van en cd met de prijs erbij vermeld. Dit product was niet gekocht maar 24
gold als reclame op de bon. Deze aanbieding verscheen in de middelste zone omdat er een bedrag onder vermeld stond. Hierdoor werd de lijst met producten vervuild met de cd terwijl deze niet gekocht was. Toch blijkt het script voor de producten goed te werken en zou het een goede toevoeging kunnen zijn aan het onderzoek omtrent het automatisch uitlezen van de declaratiecategorie (Bothof, 2011). Om mijn onderzoeksvraag omtrent de zones te kunnen beantwoorden is het nodig om een vergelijking te maken. Deze vergelijking gaat tussen het genereren van een lijst met producten met en zonder gebruik van zones. Door dit te vergelijken kunnen we verschillen waarnemen in prestaties van beide methoden.
10.3 Producten (zonder zones) Bij het analyseren van deze resultaten zonder het gebruik van zones bleek er al snel dat er veel vervuiling was opgetreden. Deze vervuiling bestond uit voornamelijk onderdelen die niet gemakkelijk weg zijn te filteren. Het verschijnen van contactgegevens, slogans, bedrijfsnamen enzovoorts zorgt ervoor dat de lijsten met filter-woorden aanzienlijk langer zou moeten worden dan de lijst die nu gebruikt is (zie bijlage 2). Het voorkomen van alleen al plaatsnamen zou ervoor zorgen dat de lijst zou moeten worden uitgebreid met alle plaatsnamen in Nederland. Het werd dus al snel duidelijk dat zones voor dit onderdeel van de bon wel degelijk hielpen bij het uitlezen van producten (OV3.2). Het blijkt een toevoeging dat we kijken naar de middelste zone. Wel zal voor implementatie nog een aantal verbeteringen moeten worden doorgevoerd. Zo zullen de scripts voor het herkennen moeten worden aangepast aan het feit dat OCR niet altijd perfecte tekst aflevert. Ook is er nog verbetering mogelijk bij het ontdekken van de zones en het vervolgens destilleren van de lijst met producten uit de middelste zone. Het algoritme voor het ontdekken van zones blijkt niet altijd voldoende krachtig om goede zones te ontdekken. Zo zal er goed moeten worden gekeken naar het probleem met de producten die hoger staan dan het eerste bedrag op de bon. Ook zou het een 25
grote toevoeging zijn wanneer de onderdelen herkend worden die niet relevant zijn voor de middelste zone.
10.4 Bedrijfsnamen Bij het onderzoek naar bedrijfsnamen ben ik helaas niet verder gekomen dan het ontdekken van de url in de bon. Het bleek dat het niet uitmaakte voor de prestaties van dit script of er werd gewerkt met of zonder zones. Het ontdekken van de bedrijfsnaam met behulp van de url zou echter maar een klein gedeelte het OCR-systeem moeten betekenen. Voor verder onderzoek zou het zeer nuttig zijn om te kijken naar de context in de bon om te herkennen welke bedrijfsnaam erop staat. Vaak is het namelijk zo dat de bedrijfsnamen veel slechter worden herkend door de OCR-software dan andere onderdelen van de bon. Dit komt omdat deze bedrijfsnamen vaak verwerkt zitten in een logo. Deze logo’s zijn lastig voor OCR-software. Wanneer we kijken naar het uitlezen van de bedrijfsnaam door middel van de url blijkt het geen toegevoegde waarde dat we gebruik maken van zones. (OV3.3) Wanneer het nodig is om de resultaten te verbeteren op dit gebied zal er waarschijnlijk gebruik moeten worden gemaakt van andere bronnen. Deze optie zou handig zijn bij het analyseren van de adresgegevens (die meestal beter te lezen zijn voor OCR-software). De adresgegevens zouden bijvoorbeeld kunnen worden gekoppeld aan een bedrijfsnaam wanneer ze worden vergeleken met andere databases zoals Google Maps. Ook wordt de kans op het vinden van een bedrijfsnaam nog vergroot door niet alleen te kijken naar de url maar ook te kijken naar het emailadres. Hierin wordt immers ook vaak achter het @-teken een bedrijfsnaam gebruikt. Wanneer we kijken naar het nut van de zones bij het automatisch uitlezen van bonnen blijkt dat zones weldegelijk werken voor een lijst met producten maar niet voor het ontdekken van bedrijfsnamen zoals ik dat hier gedaan heb (door alleen te kijken naar 26
de url). Bij het verkrijgen van informatie uit bonnen is het dus handig om zones te gebruiken (OV3).
11. DISCUSSIE In dit onderdeel zal ik methoden aandragen om mijn analyses uit de vorige sectie te verwerken in de praktijk. Vanuit de aanleiding komt hier SR//Expenses goed van pas. Het is namelijk handig om te bekijken of de onderzochte technieken en scripts kunnen worden geïmplementeerd in het declaratiesysteem van SR//Expenses. Voor het automatisch uitlezen van informatie uit kassabonnen waren eenvoudige algoritmes genoeg. Het blijkt een lichtgewicht oplossing voor het ontdekken hiervan. In een declaratieoplossing zoals SR//Expenses zou het gemakkelijk kunnen worden geïmplementeerd. Er moeten dan echter wel rekening worden gehouden met het draaien van een OCR-systeem op een client. Dit is immers een te zware applicatie om te kunnen draaien op een smartphone. Ook minder goede resultaten bij het overzetten van de afbeeldingen naar tekst (OCR) zijn belangrijk voor de implementatie. Hiervoor zullen er namelijk nog een aantal aanpassingen moeten worden gedaan aan het algoritme en het script. Zo zal de reguliere expressie iets ‘ruimdenkender’ moeten worden dan nu het geval is. Het komt namelijk nogal eens voor dat het OCR systeem een 0 voor een O aanziet of een 1 voor een kleine L. Voordat dit wordt ingebouwd moet er dus nog onderzoek gedaan worden naar veel voorkomende fouten bij het uitlezen van foto’s van bonnen. Deze zullen dan moeten worden opgenomen in het algoritme. Ook zou er nog een extra check in het algoritme kunnen worden ingebouwd. Uit eigen waarneming werd het duidelijk dat er regelmatig sprake is van een gedeelte in de bon waarin de pin betaling wordt uitgewerkt. Dit gedeelte dient in plaats van een losse pinbon en heeft meestal een consistente inhoud. Uit mijn waarnemingen blijkt ook dat hierin meestal maar 1 bedrag is vermeld, het totaalbedrag. Wanneer dit gedeelte dus herkend kan worden kunnen we ervan uitgaan dat het bedrag in dat gedeelte ook het
27
totaalbedrag is. We kunnen dan dus een check uitvoeren en vergelijkingen trekken met het eerder gevonden totaalbedrag.
12. REFERENTIES Bazzi, I., Schwartz, R., & Makhoul, J. (1999). An Omnifont Open-Vocabulary OCR System for English and Arabic. IEEE Transactions On Pattern Analysis and Machine Intelligence , 21 (6), 495 - 504. Bothof, M. (2011). OCR: Declaraties categoriseren. Bachelorscriptie University of Amsterdam. Amsterdam: University of Amsterdam. Dengel, A. R., & Klein, B. (2002). smartFIX: A Requirements-Driven System for Document Analysis and Understanding. Lecture Notes in Computer Scienc , 77-88. Greenlee, J., Fischer, M., Gordon, T., & Keating, E. (2007). An Investigation of Fraud in Nonprofit Organizations: Occurrences and Deterrents. 36, 676-694. Hollingsworth, B., Lewin, I., & Tidhar, D. (2005). Retrieving Hierarchical Text Structure from Typeset Scientific Articles -- a Prerequisite for E-Science Text Mining. University of Cambridge Computer Laboratory. Cambridge: University of Cambridge Computer Laboratory. Holzinger, A. (2005). Usability Engeneering Methods for Software Developers. 48 (1), 71-74. Klein, B., Agne, S., & Dengel, A. (2004). Results of a Study on Invoice-reading Systems in Germany. LNCS (3163), 70-79. Pieraccini, E. L. (1992). Dynamic Planar Warping For Optical Character Recognition. icassp , 92 (3), 149 - 153. Steinert, M. (2009). A dissensus based online Delphi approach: An explorative research tool. Technological Forecasting & Social Change , 76, 291 - 300. Summers, K. M. (1998). Automatic Discovery Of Logical Document Structure. Ithaca: Cornell University.
13. BIJLAGEN
13.1 Bijlage 1: Aanbieders van automatisch uitlezen van bonnen 13.1.1 NeatReceipts
Product:
28
hardware en software om bonnen uit te lezen. Een portable scanner die is aan te sluiten op de usb-poort van pc of mac. De volgende informatie wordt uitgelezen: •
Bedrijf
•
Categorie
•
Datum
•
Betaalmethode
•
BTW
•
Totaal bedrag
Bedrijf: The Neat Company Website: http://www.neatco.com
13.1.2 Shoeboxed.com
Product: De bonnetjes kunnen worden opgestuurd in een grote envelop of via een mobiele applicatie naar ShoeBoxed. Zij analyseren dan automatisch de bonnen in hun machines waar de bonnen worden geanalyseerd. Shoeboxed haalt een aantal gegevens uit de bon: •
Bedrijf
•
Bedrag
•
Credit Card info
•
Datum
Bedrijf: Shoeboxed.com Website: 29
http://www.shoeboxed.com
13.1.3 ProOnGo
Product: Met deze applicatie kunnen bonnen worden opgestuurd naar de server van ProOnGo. Hierna worden de bonnen uitgelezen en wordt de informatie in een persoonlijke account gezet. De volgende informatie wordt uitgelezen. •
Bedrijf
•
Bedrag
•
Datum
Bedrijf: ProOnGo Website: http://www.proongo.com
13.2 Bijlage 2: Pseudocode Totaalbedragen:
Foreach regel Match : te betalen |totaal | tot. | tl | tota IF: Match THEN Match: bedrag(en) IF: Match THEN: save in array, break ELSE: break ELSE Match: contant | kontant | eur | pin IF: Match THEN Match: bedrag(en) IF: Match THEN: save in array, break ELSE: Break ELSE: break
30
IF: bedrag in array THEN: zoek het hoogste bedrag in array(dit is totaal) ELSE: geen totaalbedrag gevonden
Zones:
Foreach: regel Match : bedrag IF: Match THEN: save in array, break ELSE: break //Middelste zone Eerste regel van arrat tot en metlaatste regel van array. //Top zone Eerste regel tot en met eerste regel van array – 1 //Bottom zone Laatste regel van array + 1 tot en met laatste regel Producten:
Get middelste zone uit database Foreach: regel Match: woorden van drie letters (case insensitive) IF: Match THEN: save in $matches ELSE: break Foreach: match Match: *wordslist IF: Match THEN: delete from $matches. (residu is productenlijst) Vendor Match: in top and bottom: url IF: Match THEN: url = vendor ELSE: no match
*wordslist: totaal
subtotaal betalen
betaald betaalwijze 31
betaalautomaat kontant contant reclameprijs wisselgeld btw over bonus kassanr referentie tlv xxx bank bet kenmerk aut heeft tot ziens boekingsperiode
pinnen terug sale total items eu euro exclusive stuks voordeel hoog artikelen pin verk retour datum tijd sub reductie aantal
gescande korting rekening tafel stuk omschrijving prijs nog excl code incl artikelnummer ontvangen abn amro afronding waarvan bedrag cash tax
32