De CSV die elke maand net iets anders is

Het document dat het CSV-formaat beschrijft, RFC 4180, begint met de opmerking dat het formaat nooit formeel is vastgelegd, en noemt zichzelf nadrukkelijk geen standaard. Het laat een kopregel toe maar verplicht die niet, en zegt over het aantal velden per regel dat het gelijk hoort te zijn, niet dat het moet. Wie maandelijks een CSV van een andere partij inleest en merkt dat het bestand telkens anders is, heeft dus geen uitzonderlijk geval in handen.

De vraag is dan: hoe leest u zo'n bestand in zonder elke maand de koppeling te repareren?

Waarom het bestand verandert

Meestal is de CSV voor de partij die hem maakt geen koppelvlak maar een scherm dat als bestand wordt opgeslagen. De exportknop drukt dan af wat er in het overzicht staat: de kolommen in de volgorde waarin iemand ze de laatste keer heeft gezet, de datum in de notatie van diens regionale instellingen, soms met een titelregel erboven. Zet een medewerker daar een kolom bij, dan schuift alles rechts ervan een plek op. Niemand heeft daar iets mee gebroken, zolang niemand heeft afgesproken dat het bestand een vaste vorm heeft.

Ook aan de ontvangende kant wordt met die vrijheid gerekend. De importhulp van AFAS schrijft over het importbestand dat de eerste regel veldnamen mag bevatten, maar dat dit niet hoeft, en accepteert drie opbouwen: met scheidingsteken, met tabs, of met vaste kolombreedtes. Wie zo'n bestand inleest, moet dus zelf vastleggen wat hij verwacht.

Het antwoord

Het begint met lezen op kolomnaam in plaats van op positie. Een koppeling die "de vierde kolom is het ophaaladres" als uitgangspunt heeft, gaat stuk zodra iemand een kolom toevoegt, en op een stille manier: hij stopt niet, hij leest de verkeerde gegevens in het goede veld. Een koppeling die zoekt naar de kolom met de kop "Ophaaladres" vindt die ook als hij naar plek zes is verhuisd, zolang de kop zelf gelijk blijft. Dat vraagt een kopregel; ontbreekt die, dan is dat het eerste wat u de leverancier vraagt, en dat lukt niet bij elke leverancier.

Op naam lezen heeft alleen zin als de namen vóór het inlezen worden gecontroleerd. Voordat er één regel wordt verwerkt, vergelijkt de koppeling de kopregel met de lijst die hij verwacht. Ontbreekt er een kolom, dan stopt hij en meldt dat, in plaats van het veld leeg te laten en door te gaan. Een nieuwe kolom is een melding waard, geen fout: iemand beslist of die betekenis heeft. Begint het bestand met een titelregel in plaats van met koppen, dan slaat de koppeling die over en schrijft dat in het logboek, zodat zichtbaar blijft wat er die maand anders was.

Wat na die controle nog niet eenduidig is, hoort te worden voorgelegd, niet gegokt. Een datum als 03/04/2026 is 3 april of 4 maart, en als het hele bestand geen dag boven de twaalf bevat, valt dat niet uit het bestand zelf af te leiden. Een koppeling die dan gokt, maakt een fout die pas bij de klant opvalt. Beter is een aparte bak voor alles wat niet eenduidig is, met een mens die ernaar kijkt. Bij Taxi Zoetermeer Direct kwam de rittenexport van de vervoerscentrale elke maand net iets anders binnen: een kolom die van plek wisselde, een andere datumnotatie, een extra regel bovenaan. De eerste twee maanden viel daardoor een deel van de ritten in de uitzonderingenbak en liep iemand die na, tot de koppeling de varianten herkende. Dat was bewust: liever een rit die wordt voorgelegd dan een rit die verkeerd wordt gedeclareerd.

Waar dit niet meer helpt: als ook de kopnamen elke maand veranderen, of als het bestand er helemaal geen heeft. Dan verschuift de vraag van de techniek naar de afspraak. Een vaste exportdefinitie bij de leverancier, of een koppeling op de API in plaats van op het bestand, houdt dan langer stand dan elke slimmigheid in het inlezen. En het helpt evenmin als de uitzonderingenbak er wel is, maar niemand erin kijkt.

De koppeling die op posities leest, vertrouwt erop dat de leverancier niets verandert. De koppeling die op namen leest en de koppen eerst controleert, gaat ervan uit dat er iets verandert en wil dat dan als eerste weten.