Je ERP-versie bepaalt welke velden bestaan

Je vindt online een voorbeeld van hoe je een bepaald veld uit je ERP haalt. Iemand heeft het netjes uitgeschreven, het ziet er logisch uit, je neemt het over.

En het werkt niet.

Niet omdat je een fout maakte. Omdat dat veld in jouw versie niet meer bestaat.

Wat er gebeurt bij een versiesprong

ERP-leveranciers die in de cloud draaien, brengen regelmatig nieuwe versies uit. Daarbij verdwijnen er velden, komen er velden bij, en verandert de betekenis van bestaande velden.

Voor wie de applicatie gebruikt, merk je daar weinig van. De schermen blijven werken, er komt iets bij, er valt iets weg.

Voor wie er data uit haalt, is het ingrijpend. Jouw script vraagt om een veld met een bepaalde naam. Bestaat dat niet meer, dan krijg je een foutmelding als je geluk hebt, en stille onzin als je dat niet hebt.

Ik ben dat concreet tegengekomen op een recente cloudversie: een veld dat in oudere versies op de rekeningentabel stond om aan te duiden dat een rekening niet meer gebruikt werd, bestaat daar niet meer. Elk voorbeeld van voor die versie dat dat veld gebruikt, faalt.

De gewoonte die het oplost

Vraag aan het systeem zelf welke velden er zijn, voor je iets opvraagt.

Elke fatsoenlijke API heeft daar iets voor. Je stuurt een vraag naar het model waar je in geïnteresseerd bent en je krijgt de lijst van velden terug, met hun type. Dat kost je één bevraging en het maakt het verschil tussen gokken en weten.

Doe dat aan het begin van elk traject, en doe het opnieuw na elke versiesprong van je bron. Bewaar die lijst ergens, zodat je bij een probleem kan vergelijken met hoe het was.

Het zwaardere geval: hetzelfde veld, andere betekenis

Een verdwenen veld merk je. Dat is lastig maar eerlijk.

Het gevaarlijke geval is een veld dat blijft bestaan maar anders ingevuld wordt. Dan draait alles door, je rapport toont getallen, en niemand weet dat er iets verschoven is. Die ontdek je pas als iemand een totaal herkent dat niet klopt, en dat kan maanden duren.

Daar is maar één verdediging tegen: een controle die je elke keer meedraait. Tel het aantal rijen dat je ophaalt en vergelijk met de vorige keer. Tel je omzet op en vergelijk met een totaal uit de bron zelf. Wijkt het meer af dan een drempel, dan wil je een signaal, ook al lijkt er niets mis.

Dat is tien minuten werk bij het opzetten en het vangt het enige soort fout dat je anders niet ziet.

Waarom dit vaker gaat gebeuren

Cloudversies van bedrijfssoftware verversen sneller dan de versies die bedrijven vroeger jarenlang lieten staan. Dat is op zich goed nieuws, want je krijgt verbeteringen zonder migratieproject.

Maar het betekent ook dat de afspraak tussen jouw koppeling en je bron niet meer stilstaat. Wat je vandaag bouwt, draait op een bron die volgend jaar anders is. Bouw dus alsof dat gaat gebeuren, in plaats van te hopen van niet.

Praktisch: zet je ophaallogica op één plek in plaats van verspreid over rapporten, zodat een aanpassing één ingreep is. Log welke versie je bron draait bij elke uitvoering, zodat je achteraf kan zien wanneer er iets kantelde.

De stelling

Een koppeling is geen installatie maar een afspraak met een bron die blijft bewegen. Wie dat als eenmalig werk begroot, krijgt de rekening later, op het moment dat de cijfers al een tijdje fout zijn.