Onderstaande artikel heeft betrekking op Procure to Pay (P2P) voor de volgende applicaties en/of module(s):
AP Automation
Wanneer een e-mail binnenkomt met meerdere bestanden wordt er bepaald of een bestand een bijlage is of als factuur verwerkt moet worden. Dit werkt als volgt:
Een aantal bestandsformaten worden direct gekenmerkt als bijlagen die genegeerd worden (bestanden met bijvoorbeeld .doc, .png, .xls). De te negeren bestandsformaten kunnen door een ISP-Consultant worden aangepast.
-
Controleer of de bijlagen een enkel paar vormen (PDF + XML). Als dat het geval is, wordt de PDF gekenmerkt als definitieve factuur en stopt het proces van controleren van bestanden. Als dat niet zo is, gaat het proces door met stap 2.
- Controleer of zich onder de bestanden PDF’s bevinden die gekenmerkt worden als definitieve factuur. Een PDF wordt gekenmerkt als definitieve PDF als:
-
Een nummer van de PDF-bestandsnaam correspondeert met een nummer in het e-mail onderwerp (het e-mail onderwerp dient met minstens 5 opeenvolgende cijfers gelijk te zijn aan de cijfers in de bestandsnaam van de PDF).
-
Een woord in de PDF-bestandsnaam correspondeert met een term van de “invoice inclusion words” (bijvoorbeeld ‘factuur’). Deze lijst met termen wordt onderhouden door de ISP-Consultant.
-
Ga verder met de volgende stap van het proces:
-
Als in stap 2 geen definitieve facturen worden gevonden, vervolg met stap 4 van het proces.
-
Als in stap 2 precies één definitieve factuur gevonden is, wordt geprobeerd hier een XML aan te koppelen. Alleen als er precies één andere XML is, worden de PDF en XML als een paar verder verwerkt. In alle andere gevallen wordt er niet gegokt maar gaat alleen de definitieve factuur door.
-
Als in stap 2 meer dan één definitieve factuur wordt gekenmerkt, wordt bekeken of sommige gekenmerkt kunnen worden als ‘extra’ (definitief niet een factuur). Dit wordt gedaan door te controleren of een woord van de bestandsnaam voorkomt in de lijst van termen “invoice exclusion words” (bijvoorbeeld ‘bijlage’). Deze lijst met termen wordt onderhouden door de ISP-Consultant.
Als er op deze manier slechts één PDF over blijft, wordt deze gekenmerkt als de definitieve factuur en wordt een bijbehorende XML gezocht. Alleen als er precies één XML aanwezig is, worden zij samen als een paar verder verwerkt. In alle andere gevallen wordt er niet gegokt, maar gaat alleen de definitieve factuur door en stopt het proces van controleren van bestanden.
Wanneer er niet één definitieve factuur uitkomt, gaat het proces verder met stap 4. -
De bijlagen worden gegroepeerd op basis van bestandsnamen en bijgehouden wordt of het soort bestand voorkomt in de groep (zie voorbeelden onderaan deze pagina). Per groep wordt gecontroleerd of er een PDF en/of XML-bestand aanwezig zijn. Andere bestandsformaten worden gekenmerkt als “extra”. Als er geen PDF-bestand bij zit, wordt ook het XML-bestand gekenmerkt als “extra”. Indien er een PDF en XML aanwezig zijn worden deze gezien als een paar en samen verder verwerkt. Indien er alleen een PDF aanwezig is wordt dit gezien als een factuur.
-
De facturen uit stap 4 worden verwerkt. PDF/XML paren worden verzonden naar het ‘mapping framework’ en daarna naar de BRE (Business Rules Engine). De PDF-facturen zonder XML gaan verder naar ISP-Smartscan. De “extra's” worden in ISP-Classification gekenmerkt als “errored”.
Voorbeelden:
Een e-mail bevat de volgende bijlagen:
foo.pdf
bar.xml
bar.jpg
baz.pdf
foo.xml
foo.png
baz.xls
qux.pdf
qux.doc
Aangenomen dat de .doc en de .jpg genegeerd worden, bevatten de groepen de volgende bestandsformaten:
foo: bar: baz: qux:
pdf xml pdf pdf
xml xls
png
foo.pdf en foo.xml gaan door als paar. foo.png wordt gekenmerkt als “extra”
bar.xml heeft geen bijbehorende pdf, en wordt daarom gekenmerkt als “extra”
baz.pdf wordt verwerkt als factuur zonder bijbehorende xml. baz.xls wordt gekenmerkt als “extra”
qux.pdf wordt verwerkt als factuur zonder bijbehorende xml.