Testgevallen voor het factuurformulier zijn de controles die bepalen of je factuurscherm contact met een echte zakelijke klant overleeft. Het scherm ziet er eenvoudig uit — een naam, een adres, een paar nummers — en het is waar de duurste defecten zich verschuilen, omdat de fouten stil zijn: een factuur die rendert, wordt verzonden, en verkeerd is.
Dit artikel zet uiteen wat een zakelijk factuurformulier werkelijk verzamelt, welke takken van het formulier het vaakst te weinig worden getest, hoe je een matrix met gevallen bouwt die ze dekt, en waar je op moet letten buiten het formulier zelf.
Wat verzamelt een zakelijk factuurformulier werkelijk?
Meer dan een consumentenafrekening, en in een andere vorm. Een consumentenfactuurformulier wil een naam en een adres. Een zakelijk factuurformulier wil weten welke organisatie wordt gefactureerd, in welke hoedanigheid, en onder welke fiscale behandeling.
De velden variëren per land, maar ze groeperen zich in bekende categorieën:
- Wie wordt gefactureerd — de juridische naam van het bedrijf, en vaak een handelsnaam die daarvan afwijkt.
- Identificaties — het bedrijfsregistratienummer, een fiscale identificatie, en een btw-nummer waar het land er een uitgeeft.
- Factuuradres — het adres dat de factuur moet tonen, wat niet altijd het afleveradres of de statutaire zetel is.
- Contact — een persoon aan wie de factuur wordt gestuurd, en vaak een apart adres voor factuuraflevering.
- Betalingsvoorwaarden — valuta, een inkoopordernummer, en wat de administratie van de klant ook vereist.
Het belangrijke structurele punt is dat hetzelfde scherm twee heel verschillende populaties bedient. Een zakelijke klant heeft de identificatievelden nodig; een particulier niet en kan ze meestal niet invullen. Een formulier dat één vaste set velden aan beide presenteert, verzamelt ofwel onzin van particulieren of blokkeert bedrijven.
Wat zijn de vier takken die elk factuurformulier zou moeten doorlopen?
Elk zakelijk factuurformulier heeft minstens vier wezenlijk verschillende paden, en de meeste defecten zitten op de grenzen ertussen.
| Tak | Wat verandert | Wat gewoonlijk breekt |
|---|---|---|
| Bedrijf met een btw-nummer | De identificatievelden zijn verplicht en gevalideerd | Grensoverschrijdende formaatcontroles wijzen een legitiem nummer af |
| Bedrijf zonder btw-nummer | Het veld moet werkelijk optioneel zijn | Een verplicht-veld-attribuut maakt indienen onmogelijk |
| Grensoverschrijdend | De fiscale behandeling en identificatieregels volgen het land van de koper | Binnenlandse aannames worden toegepast op een buitenlands adres |
| Particuliere koper | De bedrijfsvelden zouden volledig moeten verdwijnen | Half verplichte velden blijven staan en blokkeren het afronden |
Test elke tak twee keer: één keer met geldige invoer en één keer met invoer die op precies één manier opzettelijk fout is. De tweede ronde is waar foutafhandeling wordt beproefd, en foutafhandeling op factuurformulieren is waar klanten opgeven.
Een praktisch minimum is acht gevallen — vier takken, elk in een geldige en een ongeldige vorm — plus de paren aan weerszijden van elke grens: tijdens het formulier wisselen van particulier naar bedrijf, het land wijzigen nadat identificaties zijn ingevoerd, en terugkeren naar een opgeslagen concept. Deze overgangsgevallen vangen de toestand die afzonderlijke gevallen nooit raken.
Waarom gedraagt hetzelfde veld zich in verschillende landen anders?
Omdat de eis voortkomt uit nationale belasting- en facturatieregels, en die regels verschillen in welke velden een factuur moet dragen en wat elk veld moet bevatten.
Sommige rechtsgebieden verwachten de fiscale identificatie van de koper op een zakelijke factuur; andere vereisen die niet in dezelfde omstandigheden. Sommige eisen een registratienummer, sommige een belastingnummer, en sommige beide. Het verplichte karakter van een veld kan ook afhangen van de aard van de levering in plaats van alleen van de koper, wat betekent dat een formulier dat de eisen van één land hardcodeert, tegelijk te streng in het buitenland en te laks thuis zal zijn.
De technische reactie is de regels niet te coderen maar op land te routeren. Bepaal eerst het land en het type van de koper, leid dan af welke velden verplicht, optioneel of verborgen moeten zijn. Houd die afleiding op één plek, want landspecifieke voorwaarden door een template strooien levert precies de drift op die een formulier op twee schermen die zouden moeten overeenkomen anders laat werken.
Wat gaat er mis buiten het formulier?
Een verrassend deel van de factuurdefecten raakt helemaal geen validatie. Ze zitten in wat er gebeurt nadat het formulier is ingediend.
Factuurnummering is het klassieke voorbeeld. Het nummer moet uniek zijn, en het moet stabiel zijn. Als het op het moment van indienen wordt gegenereerd uit een teller die wordt gelezen en dan geschreven, kunnen twee gelijktijdige inzendingen hetzelfde nummer opleveren, en het duplicaat wordt weken later door een administratieteam ontdekt. Als het opnieuw wordt gegenereerd wanneer een document wordt herdrukt, heb je nu twee nummers voor één transactie.
Herhalingspogingen zijn het tweede klassieke geval. Een klant dient in, het verzoek loopt af, de klant dient opnieuw in, en er bestaan twee facturen voor één bestelling. De oplossing is idempotentie: één inzending moet één sleutel dragen, en een tweede inzending met dezelfde sleutel moet het eerste resultaat teruggeven in plaats van een tweede factuur te maken. Dit goed testen betekent doelbewust dezelfde inzending twee keer sturen en controleren dat het aantal facturen één is.
Het derde is de plaats van fouten. Een validatiefout op een lang factuurformulier moet zeggen welk veld fout is en waarom, en mag niet wissen wat de klant al heeft getypt. Test met een formulier dat tot het laatste veld is ingevuld en met één fout die vroeg is geplant, en bevestig dan dat de foutmelding naar de juiste invoer wijst en er niets verloren gaat.
Voor ontwikkelaars: de gevallenmatrix en de fixtures
Bouw de matrix als gegevens in plaats van als een berg handgeschreven tests, zodat het toevoegen van een land of een tak een rij is in plaats van een herschrijving. Elke rij moet het type koper, het land, welke identificatievelden zijn ingevuld, de verwachte vereiste per veld en de verwachte uitkomst dragen. Laat dan één testlichaam de matrix doorlopen, wat de asserties consistent houdt over de takken heen.
Gebruik testrecords die onmiskenbaar synthetisch zijn. Een facturatietest die een plausibel ogende echte bedrijfsnaam gebruikt, nodigt verwarring uit op het moment dat een screenshot in een ticket wordt geplakt, en het gebruik van de identificaties van een echt bedrijf in een testomgeving is een werkelijk juridisch risico, niet slechts slordig. Gegenereerde entiteiten uit de generator voor bedrijfsgegevens dragen neutrale, overduidelijk verzonnen namen en identificaties die tot niets leiden, precies wat een facturatiefixture nodig heeft.
Scheid de verantwoordelijkheden ook in de fixtures. Eén record voor een binnenlands bedrijf met een btw-nummer, één voor een buitenlands bedrijf zonder, één voor een eenmanszaak, één voor een particulier: vier records dekken de assen van de matrix, en ze kunnen in elk formulier van het product worden hergebruikt. Houd ze in versiebeheer met een notitie die stelt dat ze verzonnen zijn, dat er geen echt bedrijf wordt beschreven, en dat ze niet mogen worden gebruikt om rekeningen te openen of echte documenten uit te geven.
Nog twee gewoonten verkorten de feedbacklus. Valideer in de volgorde waarin de klant het formulier invult in plaats van in de volgorde waarin de velden toevallig zijn gedeclareerd, zodat de eerste fout die de gebruiker tegenkomt de eerste is die hij kan oplossen. En log een correlatiesleutel voor elke inzendingspoging — dezelfde die voor idempotentie wordt gebruikt — zodat een rapport over dubbele facturen kan worden herleid tot het paar verzoeken dat ze veroorzaakte.
Velden die afzonderlijk zijn getest, falen nog steeds in combinatie, en daarom eindigen de bespreking van btw-nummerformaten en die van validatie van fiscale identificatienummers beide op dezelfde plek: controleer de vorm lokaal, bevestig de registratie officieel, en laat het eerste nooit voor het tweede doorgaan.
Volgende stappen
Neem je factuurscherm en schrijf de vier takken op een vel papier, loop ze dan elk door met een synthetisch bedrijfsrecord en noteer elk veld dat je blokkeert. De takken die niet met gegenereerde gegevens kunnen worden afgerond, zijn degene die je echte zakelijke klanten ook niet kunnen afronden. Wanneer de matrix werkt, breid die dan uit met een grensoverschrijdend geval met een land waarvan je het formaat nooit hebt gezien en controleer dat het formulier om de juiste dingen vraagt in plaats van de bekende.