PDF verwerken naar Filemaker Pro

[elmystica]

Iedereen weet hoe vlot Filemaker PDF's creëert.

 

Maar nu is er een klant die in omgekeerde zin wil werken:

Hij ontvangt een bestelbon/factuur van zijn leverancier en wil die gaan verwerken in Filemaker Pro.

Niet gewoon inscannen en het document bewaren, maar effectief de gegevens van het document gebruiken.

Vaak zijn zo'n documenten tabelgebaseerd (Dankzij een FMP database? ) en moet dat ergens toch inleesbaar zijn.

 

BVB een bon met daarop "aantal, omschrijving, referentie, prijs per stuk zonder btw, btw-tarief, ..."

en die moeten dan ergens in de juiste velden gescript worden.

 

Probleem zit vooral in de eerste stap: heeft iemand al PDF's (of zelfs een OCR-scan) omgezet naar iets anders (al is het xls, csv, ...) waardoor die data kunnen verwerkt worden?

 

Dan hoor ik velen al zeggen: Ja, maar elke leverancier maakt andere structuren op!

Ja, maar die kunnen we dan wel scriptgewijs gaan bepalen.

Het gaat om een vrij beperkt aantal, vind ik.

Dan kiest de medewerker bvb eerst de leverancier, knopje "import bon" en loopt hij het juiste script door...

 

Maar vooral die eerste stap lijkt me wat zoeken, zonder al te veel naar compleet aparte programma's te moeten gaan voor de complete rimram.

[pjotter]

Ik zou er niet aan beginnen omdat je je eerst moet werken met een OCR scanner die omzet naar tekst en die tekst moet je gaan bewerken naar een database (import en filter) Als het maar om een paar gaat zou ik gewoon dit invoeren en de tijd niet steken in het inlezen/omzetten van die volgens jou beperkte aantallen.

komt bij als er meerdere leveranciers zijn dan heb je ook nog eens kans dat de PDF niet uniform is gemaakt.

[Felix]

.

Edited October 5, 2015 by Guest

[yamas]

Elmystica,

 

Misschien kan Scribe http://360works.com/filemaker-pdf-plugin/ van 360Works iets voor je betekenen?

[hans erik]

Ik verwerk wel de (via OCR verkregen) inhoud van PDF's in FileMaker, maar doe dat met een ander doel, namelijk via het herkennen van IBAN nummers, datums, postcodes, klantnamen e.d. Ik gebruik de plugin van Monkey Bread Software voor dit doel.

 

We gebruiken die gegevens om de PDF van een standaard codering te voorzien. Wat bijvoorbeeld goed gaat is het herkennen van een factuurdatum, klantnummer, contractnummer, postcode, IBAN.

 

Maar wat jij wilt is denk ik iets anders, nl. het omzetten in records en velden en van bijv. tabellen, of beter gezegd: structuren die op tabellen lijken.

 

Ik vrees dat dat een gebed zonder eind wordt. Als de PDF door een computer wordt gegenereerd (bijv. Excel exporteert een tabel naar PDF) dan hoeft de tekst niet door Acrobat oid herkend te worden, en is de kans aanwezig dat alle data netjes bij elkaar gegroepeerd blijft. Maar, garanties zijn er niet....

 

En als je PDFs ingescand worden en vervolgens door een OCR programma gaan, is het vrijwel onbegonnen werk. Het heeft allemaal te maken met de manier waarop een PDF wordt opgebouwd en een OCR programma te werk gaat en daar word je niet vrolijk van.

 

Mijn systeem van parsing is tot nu toe behoorlijk betrouwbaar, maar alleen voor het archiveren van het document, en niet voor het binnenhalen van de inhoud ervan. Bedenk ook dat de kans op een fout ingelezen getal vrij groot is en zie dat maar eens op te sporen.

 

Het mooiste zou zijn als je met het document ook een CSV- of XML-bestand meegestuurd krijgt!

 

Hans Erik

[pjotter]

Dat is ook de reden waarom ik meteen aangaf dat ik er niet aan zou beginnen als het maar om een enkel document zou gaan. Welke PDF is het en is de structuur altijd hetzelfde? Alles is te doen maar of dit echt de moeite van al dat werk voor enkele documenten?

[menno]

@ Elmystica

Je kan eens kijken naar tesseract, dat is ooit door HP en UNLV ontwikkeld. In 2006 is het door google opgenomen en sindsdien schijnt het erg te zijn verbeterd. Je kan op https://code.google.com/p/tesseract-ocr/ de benodigde info krijgen en e.e.a. downloaden. Het schijnt te werken op Linux, Windows en MacOSX, dus je kan zelf kiezen waar je je pdf-jes op gaat verwerken.

 

Laat je vooral niet tegenhouden door allerlei beren op de weg te zien. Dat gezegd hebbend: mijn ervaring met ocr-software (alweer ruim 10 jaar geleden en niet met tesseract) is dat kleine en "zwierige" lettertypen behoorlijk lastig zijn te herkennen voor ocr-software en dat je dan iedere scan zelf moet controleren, maar het is meestal wel sneller dan zelf overkloppen ... Als je het niet probeert, dan weet je het niet he? De gedachte om voor iedere leverancier (als dat inderdaad een enigszins beperkt aantal is) een eigen (stuk van de) verwerking te programmeren is denk ik een handige keuze.

[elmystica]

Dank jullie alvast voor de tips.

 

Ik ga vandaag eens samenzitten op te zien hoe "nodig" dit is, gezien toch wel de ruime implementatietijd die gaat nodig zijn.

Zondag zal studiedagje worden ...