Waarom pakbonnen een pijnpunt zijn
Een inkomende pakbon is zelden een netjes gestructureerd document. Leverancier A levert een PDF met een barcode en een artikelnummer dat overeenkomt met jouw inkooporder. Leverancier B stuurt een handgeschreven bon mee op de pallet. Leverancier C gebruikt zijn eigen productnummers, die je eerst moet vertalen naar jouw eigen artikelcodes. En leverancier D levert soms meer dan besteld, soms minder, zonder toelichting. De medewerker op de afdeling inkoop of magazijn moet dat allemaal uitzoeken, handmatig invullen in het ERP, en de inkooporder aansluiten. Dat kost tijd. Het vergroot ook de kans op fouten bij de factuurcontrole later: als de pakbon verkeerd is ingeboekt, klopt het drieweg-matchen (inkooporder, pakbon, factuur) niet meer.
Wat automatisch pakbonnen verwerken concreet oplost
dottle leest de inkomende pakbon, herkent de relevante velden (leverancier, artikelomschrijving, aantallen, leveringsdatum, referentienummer) en koppelt die automatisch aan de bijbehorende inkooporder in je ERP. Ontbreekt een artikelcode of gebruikt de leverancier een andere codering, dan markeert dottle het verschil. Een medewerker accordeert, corrigeert waar nodig, en de bon wordt geboekt. Wat dat oplevert: geen overgetypte regels meer, directe signalering van afwijkingen in aantallen, en een pakbon die binnen minuten verwerkt is in plaats van later op de dag of de volgende ochtend. Dat is relevant als je met meerdere inkomende leveringen per dag werkt en de administratie anders achteropraakt op de magazijnontvangst.
Hoe werkt het matchen met inkooporders?
Het matchen is de kern van pakbonverwerking: de pakbon beschrijft wat er is geleverd, de inkooporder beschrijft wat er besteld was. dottle leest de pakbon en zoekt het bijbehorende inkoopordernummer op, via het ordernummer op de bon zelf, via het referentienummer van de leverancier, of via een combinatie van leverancier en artikelgegevens. Komt er een verschil naar boven, bijvoorbeeld een levering van 98 dozen terwijl er 100 besteld waren, dan wordt dat gemarkeerd. De medewerker beslist: bon opnemen zoals geleverd, of contact opnemen met de leverancier. Wat dottle niet doet: zelfstandig beslissen dat een afwijking acceptabel is. Dat is bewust. De beslissing blijft bij de gebruiker.
Wanneer is automatisering hier niet zinvol?
Eerlijk over de trade-offs: pakbonnen automatiseren loont niet in elke situatie. Bij minder dan twintig à dertig inkomende pakbonnen per week is de tijdwinst te klein om de implementatie te rechtvaardigen. Als pakbonnen van leveranciers structureel slecht leesbaar zijn, handgeschreven en onvolledig, dan is de kwaliteit van de brondata het probleem, niet de verwerking. Automatisering maakt dat niet beter. Ook als je artikelcodes per leverancier volledig afwijken en er geen vertaaltabel beschikbaar is, kost de mapping-stap zoveel handwerk dat de winst beperkt is. En als het proces zelf niet vaststaat, wie controleert wat, welke afwijkingen zijn acceptabel, dan moet je dat eerst vastleggen voor je automatiseert. Een systeem versterkt een bestaand proces, het repareert geen ontbrekend proces.
Welke formats kan dottle lezen?
Pakbonnen komen binnen als PDF (digitaal of gescand), als Excel-bestand, als afbeelding of soms als bijlage in een mail. dottle verwerkt al die formats zonder dat je per leverancier een sjabloon moet inrichten. Dat is relevant in de groothandel, waar leveranciersbases van tientallen of honderden partijen niet te beheren zijn met vaste templates per afzender. Nieuwe leveranciers worden toegevoegd zonder dat daar een implementatietraject voor nodig is.