Tien formats, drie mailboxen, en niemand die nog overtypt

Kort antwoord. Orders uit een leveranciersportaal lees je automatisch in door de bron uit te lezen (portal, EDI of vrije-tekst e-mail), de regels te normaliseren naar jouw artikelnummers en die als gestructureerde orderregels in je ERP te zetten. Standaard-imports dekken één format. Bij tien formats en drie mailboxen bouw je een laag die elk format herkent en afwijkingen apart zet.

Een inkoper bij een groothandel typt geen orders over omdat hij dom is. Hij typt over omdat de orderbevestiging van leverancier A een PDF in het Duits is, die van leverancier B een Excel met andere kolomvolgorde, en die van leverancier C alleen leesbaar is als je inlogt op hun portaal en daar handmatig de regels overneemt.

Dat is het echte probleem. Niet de hoeveelheid orders, maar de hoeveelheid varianten. Elke leverancier heeft zijn eigen idee van hoe een orderregel eruitziet, en jouw ERP heeft er maar één.

Waarom de standaard-import van je ERP hier stopt

AFAS, Exact en Microsoft Dynamics 365 Business Central kunnen prima orders importeren. Ze verwachten alleen één vast format: een vaste kolomindeling, jouw artikelnummers, een schoon bestand. Dat is het gelukspad.

De praktijk in de groothandel is geen gelukspad. Je leverancier stuurt zíjn artikelnummer, niet die van jou. De prijs op de bevestiging wijkt af van wat je inkocht. De levertijd staat in een vrije-tekstregel onderaan de mail. Een orderbevestiging is iets anders dan een inkooporder: de inkooporder verstuur jij, de bevestiging stuurt de leverancier terug, en die twee moeten op elkaar passen (Scan Sys legt dat onderscheid duidelijk uit).

Zodra er meer dan een handvol leveranciers in het spel zit, valt het buiten wat een standaard-import aankan. Niet omdat de software slecht is, maar omdat de variatie aan de bron niet in één importprofiel past.

Doel: regels die kloppen, niet alleen minder typen

Het punt is niet de tijd die overtypen kost, al is dat al zonde. Het punt is dat handmatig overtypen je cijfers vervuilt.

Een verkeerd overgenomen aantal betekent een voorraadstand die niet klopt. Een gemiste prijswijziging op de bevestiging betekent dat je marge stilletjes wegloopt en je het pas ziet bij de factuur, of helemaal niet. Een levertijd die in iemands hoofd blijft hangen in plaats van in het systeem betekent dat je inkoopplanning op lucht draait.

Wat je echt wilt is grip: orderregels die direct kloppen in je ERP, afwijkingen die zichtbaar worden op het moment dat ze ontstaan, en een inkoper die naar uitzonderingen kijkt in plaats van naar elke regel.

Eerst het proces doorlichten, dan pas bouwen

Voordat ik iets bouw, kijk ik waarom die tien formats er zijn. Vaak is een deel ervan onnodig.

Een paar leveranciers blijken al EDI te ondersteunen, maar er is nooit aangezet omdat het ooit te veel gedoe leek. Voor die leveranciers is een EDI-koppeling de schonere route: de inkooporder (ORDERS) gaat gestructureerd heen, de bevestiging (ORDRSP) komt gestructureerd terug, geen parsing nodig. Andere leveranciers sturen drie verschillende mailtjes voor wat één bevestiging had kunnen zijn, simpelweg omdat het zo gegroeid is.

Soms kan een stap dus weg of slimmer. Dat is een bewuste keuze, geen reden om niets te doen. Want voor de leveranciers die geen EDI hebben en geen schoon bestand sturen, en dat zijn er in de groothandel altijd, lost geen enkel standaardpakket het volledig op. Daar zit het werk.

De slimmere oplossing: één inleeslaag voor alles

Wat ik bouw is een laag die vóór je ERP zit en elke bron afhandelt. Concreet:

• Drie mailboxen leeglezen. Een workflow die de inbox(en) bewaakt, bijlagen en vrije-tekst eruit haalt en per leverancier het juiste format herkent. Voor PDF's en mails met losse opmaak gebruik ik AI-extractie die de orderregels eruit leest, vergelijkbaar met wat Whitevision en Virtual Workforce voor orderbevestigingen aanbieden, maar afgestemd op jouw set leveranciers.
• Portals uitlezen. Voor leveranciers die alleen via hun portaal werken, een geautomatiseerde stap die daar inlogt en de orders ophaalt in plaats van een medewerker.
• Normaliseren naar jouw nummers. Een vertaaltabel die het artikelnummer van de leverancier omzet naar dat van jou. Dit is precies de stap die een standaard-import niet doet en die jouw situatie wel vraagt.
• Matchen en afwijkingen apart zetten. De bevestiging wordt gekoppeld aan de openstaande inkooporder. Klopt aantal, prijs en levertijd, dan gaat de regel door. Wijkt iets af, dan komt de regel in quarantaine met een melding, zodat een mens alleen naar de uitzonderingen kijkt. Dat afwijkingenprincipe is gangbaar in de markt (Scan Sys beschrijft het zo).

Het resultaat is dat de inkoper niet langer regels overtypt, maar beslist over de paar regels die er echt toe doen. De rest staat al goed in je ERP.

Build versus buy: waar de grens ligt

Koop standaard wat standaard is. Heb je leveranciers die netjes EDI of een schoon vast format leveren, gebruik dan de koppeling of import die er al is. Daar bouw je niks.

De grens ligt bij je uitzonderingen. Een standaardpakket dekt het gelukspad: één format, jouw nummers, geen afwijkingen. Het dekt niet de tien formats, de leverancier-artikelnummers die niemand heeft gemapt, en de kostentoerekening die jij specifiek doet. Dat is de moat. De inleeslaag die jouw varianten kent is geen product dat je van de plank koopt, het is iets wat op jouw operatie is gebouwd.