Voorbereidend testplan voor een boekhoud-API

Een 201 Created van een boekhoud-API vertelt je vrijwel niets. Het bevestigt alleen dat de server heeft geantwoord. Het bevestigt niet dat er precies één factuur bestaat, dat debet gelijk is aan credit, dat het documentnummer eenmalig is toegewezen of dat een nieuwe poging na een verbroken verbinding niet stiekem een tweede exemplaar boekt. De meeste dubbele boekingen in productie ontstaan door exact die kloof: een mutatie die op de server is doorgevoerd terwijl de client achterbleef met een onbekende afloop en in stilte een nieuwe poging deed met een verse sleutel.

Dit plan is bedoeld voor teams die een boekhoud-API evalueren voordat ze deze koppelen aan de echte administratie. De focus ligt op faalgedrag, niet op de gelukkige paden (happy paths). Hieronder staat per onderdeel vermeld wat je moet testen, welke asserties je moet doen en wat geldt als een geslaagde test. De implementatiecontext in dit document is Nordlet, wiens API gebruikmaakt van scoped bearer keys, decimaal-stringbedragen, idempotentiesleutels en ondertekende webhooks. Raadpleeg voor de exacte syntaxis van de endpoints en responsecontracten de pagina's API conventions en Getting started in plaats van af te gaan op aannames.

Wat "slagen" daadwerkelijk betekent

Een test bewijst pas dat een boekhoudkoppeling veilig is wanneer deze de semantiek verifieert en niet enkel de statuscodes. Voor elk scenario moet de testsuite bevestigen dat:

• Bedrijfsmatig neveneffect: er exact één klant, factuur, journaalpost, nummertoewijzing of betalingsovergang bestaat.
• Boekhoudkundige integriteit: debet gelijk is aan credit en decimale precisie behouden blijft na serialisatie.
• Herhalingsgedrag: een herhaalde poging het oorspronkelijke resultaat retourneert in plaats van een nieuw record.
• Duurzaamheid: auditrecords en webhook-events bestaan zodra de operatie is doorgevoerd.
• Falen zonder neveneffecten: geweigerde verzoeken verbruiken geen documentnummers en schrijven geen gedeeltelijke grootboekregels weg.
• Herstel: een tijdelijke fout opnieuw kan worden geprobeerd zonder duplicatie of permanent verlies.

De API-richtlijnen van Google trekken hier een duidelijke grens: alleen operaties waarvan de herhaalde uitvoering dezelfde eindstaat oplevert, zijn veilig om opnieuw te proberen. Een API moet aangeven welke operaties idempotent zijn in plaats van elke fout blind opnieuw te proberen.

Stel een geïsoleerde, observeerbare omgeving in

Gebruik een sandboxbedrijf en geen producteadministratie. Een Nordlet-sandboxbedrijf gebruikt dezelfde modules en API-functionaliteit als een echt bedrijf en is gemarkeerd als testdata, waardoor het veilig is voor grootschalige duplicatie- en faaltests. Deze markering kan na aanmaak niet meer worden gewijzigd, zodat echte administraties later niet per ongeluk als testdata kunnen worden geclassificeerd. Houd er rekening mee dat het gebruik van de sandbox net zo wordt gemeten en gefactureerd als het gebruik in een echt bedrijf, dus stem je volumetests af op de prijsstelling die voor jou geldt.

Bereid het volgende voor voordat je tests schrijft:

• Een toegewijd sandboxbedrijf met isSandbox: true.
• Een testsleutel voor de API die uitsluitend is beperkt tot de te testen modules.
• Een webhook-endpoint of lokale tunnel die de ruwe request body intact laat.
• Vooraf ingevoerde klanten, leveranciers en een bekend rekeningschema.
• Ten minste twee boekhoudperiodes: één open en één vergrendeld.
• Een testklok of datumfixture als de implementatie daarin voorziet.
• Een lokale opslag die elke poging tot een verzoek, idempotentiesleutel, response-hash, webhooklevering en afstemmingsresultaat vastlegt.

Voer geen duplicatietests uit op gedeelde staging-data. Een achtergebleven klant of factuur van een eerdere runs maakt latere asserties dubbelzinnig.

Elke fixture voor mutaties moet het volgende vastleggen: de methode, het endpoint, de volledige body, de idempotentiesleutel, de scope van de sleutel, een correlatie-ID van de client, start- en eindstempels, de responsestatus, headers, body, request-ID en de vraag of de verbinding werd verbroken voordat de respons arriveerde. Gebruik vaste decimale strings zoals "75.0000" voor geldbedragen. Nordlet vertegenwoordigt monetaire waarden als decimale strings met maximaal vier decimalen, en de voorbeeldfactuur hanteert diezelfde notatie.

De andere helft van de voorbereiding is het injecteren van fouten. Je testsysteem moet in staat zijn om een respons te vertragen, een tcp-verbinding te verbreken nadat de server het verzoek heeft ontvangen, synthetische 429/500/502/503/504-responses te retourneren, een niet-2xx status terug te geven vanaf de webhook-ontvanger, dezelfde webhook tweemaal af te leveren, events in de verkeerde volgorde aan te bieden, één byte van een webhook-body te corrumperen, de payload van een idempotentiesleutel te wijzigen terwijl de sleutel gelijk blijft, twee identieke verzoeken tegelijkertijd uit te voeren en een periode te vergrendelen tussen de voorbereiding en de boeking in. Deze scenario's zijn meer waard dan honderd voorbeelden van succesvolle scenario's.

Vergrendel het contract voordat je herhalingslogica schrijft

Genereer of haal het OpenAPI-schema op en vergelijk dit met je client. Nordlet publiceert zijn OpenAPI-specificatie in de API-referentie en genereert zijn getypeerde SDK's vanuit diezelfde specificatie, waardoor tests op basis van het schema betrouwbaarder zijn dan handmatige gissingen.

Verifieer verplichte velden en typen, decimale stringvelden, datum- en tijdnotaties, toegestane acties en scopes, de structuur van de foutmelding (error envelope), schemas van webhook-events, welke mutaties een idempotentiesleutel accepteren en welke responsevelden het aangemaakte object identificeren.

Geslaagd als: De client ongeldige payloads lokaal afwijst wanneer het schema dat toestaat. De responses van de server overeenkomen met het gedocumenteerde schema. Ongeldige decimalen, onjuiste datums en ontbrekende verplichte velden gestructureerde validatiefouten opleveren. Er geen nieuwe poging wordt ondernomen bij een deterministische validatiefout.

Te onderscheppen fout: Een client parset "121.0000" naar een binary float en serialiseert later een net afwijkend bedrag. Gehele getallen slagen wel; btw-regels en fractionele aantallen falen. Test geldwaarden als strings van begin tot eind.

Autorisatie en tenant-isolatie

Gebruik afzonderlijke sleutels voor lezen en schrijven. Test vervolgens de volledige matrix: ontbrekende sleutel, ongeldige sleutel, geldige sleutel met onvoldoende modulescope, geldige sleutel met de juiste scope, een sleutel die toebehoort aan een ander bedrijf, en een poging om een object van een ander bedrijf te lezen.

Asserties:

• Ontbrekende of ongeldige inloggegevens retourneren 401.
• Een geldige sleutel zonder de vereiste rechten retourneert 403.
• Er wordt geen boekhoudkundig neveneffect gecreëerd bij beide typen fouten.
• Een succesvol verzoek kan de gegevens van een ander bedrijf niet lezen of muteren.
• Beveiligingsfouten worden nooit automatisch opnieuw geprobeerd.

Geslaagd als: Je zowel de correctheid van de autorisatie als de tenant-isolatie kunt bewijzen met leesacties na de test, en niet alleen op basis van statuscodes.

Bewijs één schone transactie

Voer een kleine, deterministische stroom uit: maak een testklant aan (of zoek er een), maak een factuur aan met decimale stringbedragen, stel deze vast, lees de factuur en het boekhoudkundige effect daarvan uit, lees het auditrecord en ontvang de webhook. Het Getting Started-voorbeeld van Nordlet toont dat bij het vaststellen van een factuur een sluitend nummer wordt toegekend, wordt gecontroleerd of de periode open is en een sluitende journaalpost wordt geboekt binnen dezelfde transactie.

Verifieer dat de factuur de verwachte status bereikt, het documentnummer precies eenmalig wordt toegewezen, debet gelijk is aan credit, btw- en regeltotalen overeenkomen met de verwachte afronding (half-up), het auditrecord de uitvoerende actor en wijziging vernoemt, de webhook uiteindelijk wordt afgeleverd en de API-respons en een volgende leesactie het eens zijn over de factuur-ID en de status.

Een belangrijk onderscheid om vast te houden: de aankomst van een webhook is geen bewijs dat de mutatie is doorgevoerd. De API-respons plus een herhaalde leesactie vormen je primaire transactie-asserties. De webhook bewijst dat de keten op de hoogte is gebracht en wordt apart getest.

Idempotentie: zelfde sleutel, zelfde body

Genereer één sleutel per logische bedrijfsoperatie, niet één sleutel per netwerkpoging. Verstuur de mutatie met sleutel K en body B, sla de aangemaakte ID op en verstuur exact hetzelfde verzoek nogmaals.

Verifieer dat de tweede respons dezelfde operatie vertegenwoordigt, de object-ID identiek is en er sprake is van één bedrijfsobject, één boeking, één documentnummer en één financieel effect. De herhaalde respons moet de gedocumenteerde herhalingsheader bevatten (x-idempotent-replay: true in het geval van Nordlet) en de audit trail mag geen tweede mutatie tonen.

Twee opslagregels bepalen wat je herhalingslus (retry loop) kan verwachten, dus test deze direct: een opgeslagen 4xx-respons wordt herhaald zoals elke andere respons, terwijl een 5xx-respons helemaal niet wordt opgeslagen, zodat een nieuwe poging na een serverfout de operatie opnieuw uitvoert in plaats van te herhalen. Sleutels verlopen ook (bij Nordlet na 24 uur), wat begrenst hoe lang een herhaling mogelijk is.

De documentatie van Nordlet belooft dat het toevoegen van een Idempotency-Key-header voorkomt dat een herhaald verzoek een duplicaat aanmaakt, en de API-conventies definiëren de exacte herhalingsheader en de vereiste van een byte-voor-byte identieke respons. Dit principe komt overeen met het gepubliceerd model van Stripe: een sleutel identificeert de logische operatie, herhalingen retourneren het opgeslagen resultaat, en een hergebruikte sleutel met andere parameters wordt geweigerd in plaats van stilletjes aangepast.

Geslaagd als: Er exact één financiële statusovergang bestaat, ongeacht hoe vaak de client hetzelfde verzoek verstuurt binnen het herhalingsvenster.

Idempotentie: zelfde sleutel, gewijzigde body

Verstuur het oorspronkelijke verzoek met sleutel K en body B1, en stuur vervolgens een tweede verzoek met sleutel K en body B2 waarbij ten minste één bedrag, klant, datum of regel verschilt.

Verwacht resultaat: het verzoek wordt geweigerd met de gedocumenteerde foutmelding voor hergebruik van de sleutel (Nordlet retourneert 422 idempotency_key_reuse), het oorspronkelijke record blijft onaangeroerd, er verschijnt geen tweede record, nummer of auditmutatie, en de client "lost dit niet op" door een nieuwe sleutel te genereren. Het stilletjes accepteren van B2 zou herhalingssleutels onveilig maken.

Gelijktijdige dubbele verzoeken

Vuur twee identieke verzoeken met dezelfde sleutel op exact hetzelfde moment af. Afhankelijk van het gedocumenteerde gedrag wordt de ene operatie uitgevoerd terwijl de andere een conflict ontvangt vanwege een lopend proces (Nordlet retourneert 409 idempotency_in_progress), of observeren beide uiteindelijk hetzelfde resultaat.

Verifieer dat beide aanroepen geen onafhankelijke financiële effecten kunnen creëren, dat er maximaal één documentnummer wordt toegewezen, dat een tijdelijk conflict opnieuw wordt geprobeerd met dezelfde sleutel in plaats van een nieuwe, dat de uiteindelijke resource compleet en leesbaar is en dat het idempotentierecord niet permanent vast blijft te zitten.

Faalmodus: Een library voor herhalingspogingen die per poging een verse UUID aanmaakt, verandert één logische operatie in meerdere onafhankelijke schrijfhandelingen en tenietdoet daarmee de idempotentie volledig.

De onbekende afloop na een verbroken verbinding

Dit is de allerbelangrijkste simulatie voor productie. Verstuur een mutatie met sleutel K, laat de server deze doorvoeren, verbreek de verbinding voordat de respons arriveert, markeer de afloop als onbekend, probeer het opnieuw met dezelfde sleutel K en stem af door de resource en auditgegevens uit te lezen.

Verifieer dat de herhaalde poging de oorspronkelijke of gedocumenteerde herhalingsrespons retourneert, er exact één financieel neveneffect bestaat, de client de operatie pas als voltooid markeert na een succesvolle herhaling of afstemmende leesactie, en er geen nieuwe sleutel wordt gegenereerd. Een timeout betekent niet dat er "niets is gebeurd". Stripe omschrijft idempotentie precies als bescherming tegen verbindingsfouten waarbij de server een mutatie mogelijk al heeft verwerkt voordat de client de respons kon ontvangen.

Een conservatief beleid voor herhalingspogingen

Beslissingen over het al dan niet opnieuw proberen hangen af van zowel de fout als de vraag of de operatie idempotent is, en niet uitsluitend van de HTTP-methode.

Meestal opnieuw te proberen, zelfde sleutel behouden: verbindingsreset of timeout na een idempotente mutatie, 408, 429 na het respecteren van retry-after, en 502/503/504. Een gedocumenteerde idempotentierepons die aangeeft dat een proces bezig is, kan na een korte pauze opnieuw worden geprobeerd.

Niet opnieuw te proberen zonder afstemming: 400/422 validatiefouten, 401/403 auth-fouten, 404 voor een ontbrekende resource, 409-bedrijfsconflicten die geen verband houden met een lopende sleutel, een gewijzigde payload op een bestaande sleutel en een afwijzing vanwege een vergrendelde periode.

Verifieer een begrensd exponentieel uitstelgedrag (exponential backoff) met jitter, expliciete maximumaantaal pogingen en verstreken tijd, het respecteren van retry-after voor rate limits, het behouden van dezelfde sleutel bij herhalingen van één operatie, een nieuwe sleutel voor elke nieuwe operatie, en logboeken die de oorspronkelijke poging scheiden van herhalingen.

Test rate-limiting afzonderlijk. Overschrijd de gedocumenteerde grens (Nordlet staat standaard 300 verzoeken per minuut toe per API-sleutel, en sommige niet-geauthenticeerde endpoints hanteren lagere eigen limieten per adres) en bevestig dat de server een rate-limit-respons retourneert, de client retry-after interpreteert als een pauze in plaats van een fout, deze pauzeert in plaats van te blijven hameren, en een nieuwe poging voor een afgeknotte mutatie de oorspronkelijke sleutel hergebruikt. De x-ratelimit-*-headers rapporteren het resterende budget, wat een mooi uitgangspunt vormt voor een voorafgaande assertie. Houd rate-limit-tests uit de buurt van financiële asserties, tenzij je fixture een afgeknotte poging kan onderscheiden van een doorgevoerde poging.

Verificatie van webhook-handtekeningen

Bouw een ontvanger die de ruwe bytes intact laat. Vang voor elk event het volgende op: leg de ruwe body vast, lees de x-nordlet-signature-header, bereken de verwachte HMAC-SHA256 met het abonnementsgeheim, vergelijk dit via een constante-tijd-functie (constant-time function), parse JSON pas na verificatie, leg de levering vast en retourneer snel een 2xx na duurzame acceptatie. Nordlet ondertekent een HMAC over de ruwe body, verstuurt deze als sha256=<hex> en probeert leveringen opnieuw met exponentiële backoff. De webhook-richtlijnen van Stripe benadrukken het verifiëren van de ongewijzigde ruwe body met een vergelijking in constante tijd.

Voer negatieve tests uit: correcte body en geheim, correcte body met verkeerd geheim, een wijziging van één byte in de body, opnieuw geserialiseerde JSON met aangepaste witruimte, een ontbrekende header, een misvormde handtekening, een herhaalde oude levering als het schema een tijdstempel bevat, en een geldige handtekening die wordt afgeleverd bij het verkeerde abonnement.

Geslaagd als: Alleen de correcte ruwe body en het juiste geheim worden geaccepteerd. Ongeldige handtekeningen krijgen een niet-2xx status. Ongeldige payloads komen nooit in de boekhoudwachtrij terecht. Geheimhoudingen blijven buiten de reguliere logboeken. De handler bevestigt pas nadat het event duurzaam is opgeslagen.

Dubbele en onordelijke webhooks

De betrouwbaarheid van de levering is een ander vraagstuk dan API-idempotentie, en ook de ontvanger moet idempotent zijn. Lever hetzelfde event tweemaal af, lever een sale_invoice.paid-event af vóór een sale_invoice.issued-event, retourneer een 500 na opslag maar vóór de respons, en herhaal een event dat de consument al heeft verwerkt.

Verifieer dat dubbele leveringen geen dubbele betalingen, statuswijzigingen of journaalhandelingen veroorzaken, dat de deduplicatiesleutel de leverings- of event-ID van de provider gebruikt wanneer die aanwezig is (of een gedocumenteerde samengestelde sleutel, nooit een willekeurige tijdstempel), dat events in de verkeerde volgorde nooit nieuwere statussen overschrijven met oudere, dat de consument de huidige status uit de API kan ophalen wanneer de volgorde niet toereikend is, en dat mislukte pogingen van de consument via een wachtrij of dead-letter-route lopen. Stripe waarschuwt expliciet dat de leveringsvolgorde niet gegarandeerd is en raadt aan om verwerkte event-ID's op te slaan.

Houd het endpoint licht: valideer de vorm, verifieer de handtekening, sla op of zet in de wachtrij, bevestig ontvangst en retourneer 2xx. Afstemming en notificaties horen thuis in asynchrone verwerking. Test dit door het neerwaartse werk langer te laten duren dan de levertijd; een correcte ontvanger bevestigt nog steeds na duurzame plaatsing in de wachtrij.

Open en vergrendelde boekhoudperiodes

Nordlet handhaaft periodevergrendelingen op het moment van boeken over handmatige journaalposten, documentstromen en imports heen, dus test deze controle op meerdere plekken. Maak vergelijkbare documenten aan met een datum in een open periode, in een vergrendelde periode, op de grens vlak voor de vergrendeling, op de eerste dag van de volgende open periode en met een geldige documentdatum maar een ongeldige boekingsdatum als de API beide van elkaar scheidt.

Verifieer voor het geval van de vergrendelde periode dat het verzoek wordt geweigerd met de gedocumenteerde foutmelding voor de periodevergrendeling (een 409 conflict bij Nordlet), en dat er geen journaalregels worden weggeschreven, geen documentnummer wordt verbruikt, het document niet overgaat naar de status 'geboekt' en er geen succesvolle webhook wordt verzonden. De variant in de open periode zou met dezelfde financiële waarden moeten slagen.

Racetest. Start een boeking in een open periode, vergrendel de periode halverwege het verzoek en bevestig dat de transactie de vergrendeling niet kan omzeilen. De cruciale slaagvoorwaarde: een doorgevoerde boeking belandt nooit in een periode die al was vergrendeld voordat de transactie werd voltooid.

Auditeerbaarheid en afstemming

Bevestig voor elke succesvolle mutatie dat het bedrijfsobject bestaat, de boekhoudkundige boeking bestaat waarbij debet gelijk is aan credit, het auditrecord bestaat, het webhook-event bestaat of kan worden opgehaald, en dat je operatierecord verwijst naar de object-ID van de provider waarbij herhalingen naar dezelfde logische operatie verwijzen.

Bevestig voor elke geweigerde mutatie dat er geen gedeeltelijk document bestaat, er geen nummer is verbruikt tenzij het contract reservering toestaat, er geen grootboekregel bestaat, er geen succesvolle webhook is en de fout een request-ID bevat voor diagnose. De conventies van Nordlet beschrijven de auditeerbaarheid van mutaties en gebalanceerde boekingen als platformgaranties, waarbij de balans wordt afgedwongen door een uitgestelde databasetrigger op het moment van doorvoeren in plaats van alleen door applicatielode. Zet die garanties om in afstemmingsqueries na de test in plaats van blind te varen op de HTTP-respons.

Kern van de testmatrix

Onderdeel	Testactie	Verwachte assertie	Geslaagd als
Autorisatie	Geen sleutel, ongeldige sleutel, onvoldoende scope	Gestructureerde 401/403; geen neveneffect	Alle geweigerde pogingen creëren geen boekhoudrecord
Schema en geld	Ongeldige decimaal, datum, verplicht veld	Veldspecifieke validatiefout	Geen herhaling of gedeeltelijke schrijfhandeling
Normale boeking	Maak en stel een factuur vast in een open periode	Één document, één sluitend journaal, één auditrecord	Status uitgelezen via API en grootboek komen overeen
Herhaling zelfde sleutel	Herhaal identieke mutatie, zelfde sleutel en body	Oorspronkelijk resultaat herhaald; geen duplicaat	Object-ID, nummer, journaaleffect en audit blijven uniek
Gewijzigde body, zelfde sleutel	Hergebruik sleutel met ander bedrag	Gedocumenteerde weigering wegens hergebruik	Oorspronkelijk record ongewijzigd; niets nieuws geschreven
Verbroken verbinding	Doorvoeren, verbreken, herhalen met zelfde sleutel	Herhaald resultaat	Exact één financieel neveneffect
Vergrendelde periode	Boek een document met datum in vergrendelde periode	Weigering wegens periodevergrendeling	Geen journaal, geen nummer, geen succesvolle webhook
Webhook-handtekening	Verkeerd geheim, gewijzigde body	Niet-2xx van ontvanger	Alleen correcte ruwe body en geheim geaccepteerd

Wat ik als eerste zou doen

Als de tijd krap is, voer de tests dan uit in de volgorde die de duurste bugs het snelst opspoort. Begin met de herhalingspoging na een verbroken verbinding, omdat dat enkelvoudige scenario de meeste echte duplicaten veroorzaakt. Daarna het paar van idempotentie met dezelfde sleutel en een gewijzigde body. Vervolgens vergrendelde periodes, aangezien een boeking in een afgesloten maand een auditing-probleem is dat pas laat aan het licht komt. Handtekeningverificatie en webhooks in de verkeerde volgorde volgen daarna, en de volledige schema- en autorisatiematrix kan continu in CI draaien zodra de client stabiel is.

Al het andere in dit plan ondersteunt die vijf punten. Zorg dat deze groen zijn in een sandboxbedrijf, waarbij leesacties voor afstemming de neveneffecten bevestigen, en je weet zeker dat de integratie veilig is voordat deze ook maar één echte administratie aanraakt. Je kunt binnen enkele minuten een sandboxbedrijf en een scoped testsleutel aanmaken via Get started en controleren welke modules je nodig hebt via de lijst met functies.

FAQ

Is een 2xx-respons voldoende om te bevestigen dat een boekhoudkundige schrijfhandeling is geslaagd?

Nee. Een statuscode bevestigt alleen dat de server heeft geantwoord, niet dat er exact één document, één nummertoewijzing en één sluitende journaalpost bestaan. Elke mutatietest moet op de respons volgen met een uitleesactie van het object, het boekhoudkundige effect en het auditrecord. Het gevaarlijke geval is de omgekeerde richting: een operatie die is doorgevoerd terwijl de client de respons helemaal nooit heeft ontvangen.

Moet ik een nieuwe idempotentiesleutel genereren wanneer een verzoek in een timeout loopt?

Nee, en dit is de fout die de meeste duplicaten in productie veroorzaakt. De sleutel identificeert de logische bedrijfsoperatie, niet de netwerkpoging. Probeer dezelfde sleutel opnieuw en stem daarna af door de resource te lezen. Een herhalingslibrary die per poging een verse UUID aanmaakt, verandert één bedoelde factuur in meerdere onafhankelijke schrijfhandelingen.

Wat gebeurt er als ik een idempotentiesleutel hergebruik met een andere payload?

Een correcte API wijst dit af in plaats van de nieuwe body stilletjes toe te passen. Nordlet retourneert 422 idempotency_key_reuse en laat het oorspronkelijke record ongemoeid. Je client moet dit behandelen als een programmeerfout die moet worden opgelost, en niet als een situatie die je omzeilt door een nieuwe sleutel te genereren.

Zijn webhooks een vervanging voor het uitlezen van het aangemaakte object?

Nee. Webhooklevering bewijst dat de keten op de hoogte is gebracht, niet dat de transactie is doorgevoerd zoals je verwacht, en de leveringsvolgorde is niet gegarandeerd. Verifieer de handtekening over de ruwe body, dedupliceer op basis van de leverings- of event-ID en haal de huidige status op uit de API wanneer de eventvolgorde alleen niet voldoende is om te bepalen wat er is gewijzigd.

Hoe test ik het boeken in een vergrendelde boekhoudperiode?

Maak vergelijkbare documenten aan in een open periode en in een vergrendelde periode, en verifieer dat het vergrendelde geval wordt geweigerd zonder journaalregels, zonder verbruikt documentnummer, zonder statusovergang en zonder succesvolle webhook. Voer daarna de racetest uit: start een boeking in een open periode en vergrendel de periode halverwege het verzoek. Een doorgevoerde boeking mag nooit belanden in een periode die al was vergrendeld voordat de transactie werd voltooid.

Kan ik grootschalige duplicatietests uitvoeren in een sandboxbedrijf?

Ja. Een sandboxbedrijf gedraagt zich als een echt bedrijf, is gemarkeerd als testdata en wordt direct verwijderd in plaats van na de bewaartermijn, dus het is de juiste plek voor destructieve tests en duplicatietests. Het gebruik van de sandbox wordt nog steeds gemeten en gefactureerd als echt gebruik, dus plan het volume in plaats van oneindig door te loopen.