Maak iedere automatische financiële boeking controleerbaar door de verzendintentie vóór de API-opdracht vast te leggen. Noteer welke brontransactie, boekingssnapshot en deterministische AFAS-referentie worden aangeboden. Daarmee kan administratie na een crash aantonen wat bedoeld was, wat mogelijk is ontvangen en waarom een herstelstap wel of niet opnieuw heeft geschreven.
Een logregel ná succes is te laat
Veel koppelingen bewaren pas een extern nummer wanneer de provider succesvol antwoordt. Precies tussen verzenden en dat antwoord zit echter het gevaarlijkste venster. Valt het proces daar weg, dan is lokaal geen voltooiing bekend terwijl AFAS de boeking mogelijk al heeft gemaakt. Een latere operator ziet alleen “mislukt” en kan onterecht opnieuw sturen.
Een uitvoeringsregister begint daarom vóór de externe schrijfhandeling. Het bevat een eigen poging-ID, werkruimte, transactie-identiteit, doeltype, vaste externe referentie en een onveranderlijke zakelijke snapshot. Gevoelige data blijft beperkt tot wat voor identificatie en controle nodig is. De toestand gaat daarna naar bevestigd, afgewezen of onzeker, met het antwoord of verificatiebewijs erbij.
Minimaal uitvoeringsregister
| Veld | Functie | Controle |
|---|---|---|
| Brontransactie-ID | Terug naar PayPal/Mollie of andere bron | Uniek binnen account en werkruimte |
| Boekingssnapshot | Bewijst aangeboden inhoud | Onveranderlijk, geminimaliseerd |
| AFAS-referentie | Gerichte ontvangstcontrole | Deterministisch en collisionvrij |
| Pogingstatus | Gestart, bevestigd, afgewezen of onzeker | Geldige statusovergangen |
| Extern bewijs | Bevestigt doelrecord | Identiteit én kernvelden vergelijken |
| Actor of proces | Herkomst van uitvoering | Automatisch, medewerker of herstelactie |
Het register in Connect vervangt geen boekhouding. Het maakt de technische overdracht naar een door administratie goedgekeurde AFAS-inrichting aantoonbaar.
Fictief voorbeeld: herstart tijdens maandafsluiting
Fictief voorbeeld: webshop Klei & Koper verwerkt transactie KK-P-1904. De integratie bewaart de boekingssnapshot en referentie vóór verzending. Het proces wordt herstart voordat het AFAS-antwoord lokaal is opgeslagen. In het uitvoeringsregister staat één gestarte, onzekere poging; in de gewone ordertijdlijn is nog geen bevestigd resultaat.
Een herstelproces zoekt gericht naar de vaste referentie en vindt een AFAS-record met dezelfde gecontroleerde regels. Het bewaart dat bewijs en sluit de bestaande poging als bevestigd. Administratie ziet bij de maandcontrole één brontransactie, één intentie en één doelrecord. Als de inhoud niet overeenkwam, zou het register een conflict tonen en niet het gevonden record als succes claimen. Dit fictieve voorbeeld maakt duidelijk dat auditdata een herstelmechanisme is, geen decoratieve logging.
Controle voor de financiële eigenaar
- Kan iedere brontransactie naar precies één actuele boekingsintentie worden gevolgd?
- Is zichtbaar of een nieuwe poging een retry, correctie of afzonderlijk record is?
- Kan een operator geen tweede opdracht starten zolang ontvangst onzeker is?
- Wordt bewijs uit AFAS met snapshotinhoud vergeleken en niet alleen op referentie gevonden?
- Zijn onbekende transactietypen apart in plaats van onder een standaardrekening verwerkt?
- Kan een handmatige beslissing met reden en bevoegdheid worden teruggevonden?
In Desk kan de order een begrijpelijke status tonen, terwijl financieel beheer het uitvoeringsbewijs beoordeelt. Meer over de technische orderroute staat bij WooCommerce en AFAS koppelen. Laat boekingsschema’s en wettelijke vereisten altijd afzonderlijk door deskundigen vaststellen.
Voer een volledigheidscontrole uit die niet alleen bevestigde boekingen telt. Neem ook gestarte, onzekere, afgewezen en handmatig gesloten pogingen mee. Een rapport dat alleen successen toont kan precies de transacties verbergen waarvoor geen antwoord kwam. Vergelijk per brontransactie het aantal actieve intenties en sta hoogstens één uitvoerbare intentie tegelijk toe. Een correctie moet naar de oorspronkelijke identiteit verwijzen, maar als nieuw, expliciet type herkenbaar blijven; verander een oude snapshot niet achteraf om het totaal te laten kloppen.
Test het register met een herstart op ieder overgangsmoment: vóór verzenden, direct na verzenden, na providerantwoord en tijdens het opslaan van bewijs. Controleer dat dezelfde herstelbeslissing na twee herstarts nog steeds ontstaat. Geef financiële beheerders een export met identiteiten en statussen, niet met ruwe secrets of volledige klantpayloads. Spreek een bewaartermijn af die onderzoek mogelijk maakt zonder alle brondata onbeperkt te bewaren. Wanneer iemand een poging handmatig afsluit, moet reden en gekozen externe bewijs verplicht zijn. Zo blijft de keten ook onder tijdsdruk verklaarbaar.
Koppel een correctie altijd aan de oorspronkelijke intentie, maar laat haar als apart besluit bestaan. Achteraf een oud bedrag aanpassen vernietigt het bewijs van wat werkelijk is verzonden.
Wil je financiële integratiestappen aantoonbaar maken vóórdat er iets wordt verzonden? Ontwerp het uitvoeringsregister met Yindle.