blog·4 min lezen

Case: een drankengroothandel van leveranciersfactuur tot Exact Online in een maand

Een drankengroothandel met slijterij legde elke leveranciersfactuur met de hand naast Exact Online. Een maand later leest een eigen app de facturen van tien leveranciers, rekent ze na en zet na akkoord artikelen en inkooporders in Exact.

Ik wil niet meer elke leveranciersfactuur regel voor regel naast Exact
leggen. Laat me alleen zien wat niet klopt, en zet de rest erin.

Dat was de vraag van een drankengroothandel met een eigen slijterij. Ze werken met Exact Online, kopen in bij een stuk of tien vaste leveranciers en verkopen aan horeca, aan wederverkopers en in de eigen winkel. Een maand later draait er een eigen app die het inkoopwerk grotendeels overneemt, plus een bestelportaal voor hun horecaklanten.

Dit is wat er gebouwd is, in welke volgorde, en wat we anders zouden doen. De klant blijft anoniem en er staan hier geen bedragen, prijzen of marges.

Het startpunt: alles met de hand naast elkaar

Elke leverancier stuurt een factuur in zijn eigen opmaak. Daar staan nieuwe artikelen op die nog niet in Exact bestaan, prijzen die net anders zijn dan vorige keer, toeslagen die alleen in de voettekst staan, en gratis flessen die op een eigen regel verrekend worden. Iemand legde dat regel voor regel naast Exact, maakte nieuwe artikelen met de hand aan en typte de inkooporder over.

Daarnaast lagen er tienduizenden klantprijsafspraken in Exact die niemand meer naliep. Of een klant onder de kostprijs kocht, wist je pas als je het toevallig zag.

Eerst een prototype van vier dagen

De eerste versie was een klein script dat drie leveranciers kon lezen en alleen uit Exact las. Het draaide vier dagen. Genoeg om te zien dat het kon, en om te ontdekken waar de echte moeilijkheden zaten.

Daarna is de app opnieuw opgezet, met een echte database, inloggen met twee stappen, rollen en meldingen. De uitkomsten van het prototype werden de testset voor de nieuwe app: elke factuur die het script goed las, moest de nieuwe app net zo goed lezen. Zo begon de herbouw niet bij nul, maar bij een lat.

Wat er nu draait

Facturen inlezen en narekenen. PDF of UBL van tien leveranciers, elk met een eigen lezer. Elke factuur wordt regel voor regel nagerekend; ongeveer 97 procent sluit tot op de cent. Wat niet sluit, staat bovenaan met de regel erbij. Facturen mailen naar een eigen adres per leverancier, waarna de app ze zelf ophaalt, draait inmiddels op een testdomein.

Nieuwe artikelen. Een product dat nog niet in Exact staat, wordt een voorstel: naam in de stijl die de groothandel zelf gebruikt, leveranciersartikel, inkoopprijs en een verkoopprijs. Na akkoord staat het in Exact.

Inkooporder uit de factuur. Na controle gaat de factuur als inkooporder naar Exact, met retouren als negatief aantal. Een drukke API of een time-out wordt vanzelf opnieuw geprobeerd, maar pas nadat de app heeft gecontroleerd dat de order er nog niet staat.

Prijslijsten en marges. Alle prijsafspraken staan in een eigen kopie. Rood is een klantprijs onder de kostprijs, oranje een marge onder het minimum dat de groothandel zelf instelt.

Voorraad en kassa. De voorraad per magazijn komt elk kwartier binnen. De kassa van de winkel levert een weekexport; die wordt één verplaatsing van het groothandelsmagazijn naar het winkelmagazijn in Exact.

Bestelportaal. Horecaklanten bestellen zelf tegen hun eigen prijslijst, zien wat ze eerder bestelden en krijgen een mail als iets weer op voorraad is. Na akkoord gaat de order naar Exact, en Exact rekent de prijs.

Meldingen. Een factuur die niet sluit, een artikel zonder leveranciersnummer, een prijs onder de kostprijs. Per medewerker in te stellen, met een dagoverzicht in de mail.

De cijfers

Leveranciers met een eigen factuurlezer 10
Facturen die op de cent sluiten ongeveer 97%
Inkoopfacturen uit drie jaar archief ingelezen ruim 1.800
Benoemde schrijfacties naar Exact 8
Tijd tussen twee voorraadstanden 15 minuten
Automatische tests ruim 1.900, in ongeveer 35 seconden

Die drie jaar archief zijn niet alleen voor de historie. Ze waren de zwaarste test die we de lezers konden geven: elke oude opmaak, elke creditnota, elke uitzondering kwam langs. Wat niet gelezen kon worden, staat in een lijst onder de cijfers, zodat je weet hoe volledig ze zijn.

Hoe er gebouwd werd

In kleine stappen, met de eigenaar die meekeek. Elke wijziging gaat pas live als alle tests groen zijn, en dan binnen een minuut. Dat maakt het mogelijk om op een dinsdag een wens te horen en hem op woensdag te laten zien.

Schrijven naar Exact kwam er stap voor stap bij. Het prototype las alleen, en elke schrijfactie in de nieuwe app is een eigen opdracht geweest, met een eigen test die bewaakt dat er niet ongemerkt een bij komt. Hoe dat werkt, staat in acht schrijfacties en geen negende. De ontwikkelomgeving praat nooit met Exact, alleen met een kopie.

Wat nog komt

De kassa per bon in plaats van per week: de webhook die de kassa na elke verkoop stuurt, hebben we op onze eigen testkassa werkend. Verder tellen met de telefoon, schapkaartjes printen vanuit de app, en meldingen ook via Telegram. Die staan gepland, niet af.

Veelgemaakte fouten bij zo'n project

Beginnen met het hele systeem. Begin met het knelpunt dat elke week terugkomt. Bij deze klant was dat de inkoopfactuur. Alles daarna bouwde op dezelfde koppeling.

Alle leveranciers tegelijk. Elke leverancier heeft zijn eigen eigenaardigheden. Begin met de drie grootste, maak die goed, en voeg de rest een voor een toe.

Meteen alles laten schrijven. Begin met lezen en voeg schrijfacties een voor een toe, elk met een eigen akkoord. Je leert dan hoe de gegevens echt in elkaar zitten, en de eigenaar leert de app vertrouwen voordat die iets mag boeken.

Testen met drie facturen. De echte uitzonderingen zitten in oude opmaak, creditnota's en scans. Een archief van een paar jaar is de beste testset die er is.

Meer over wat een Exact-koppeling kan, staat op Exact Online koppelen. Over de bouwstenen achter deze app schreven we eerder meer dan facturen.

MK
Maarten Keizer

Oprichter van Invoker. Ruim twintig jaar hosting, systeembeheer en webdevelopment; bouwt de Claude-hosting zelf en test alles eerst op de eigen servers.

over maarten