Als AFAS slaagt maar een vervolgsysteem faalt, moet je het geslaagde deel bewaren en alleen de mislukte afhankelijkheid herstellen. Draai de hele orderketen niet opnieuw. Een deelresultaat is geen onduidelijke mislukking: het is een bekende toestand waarin de financiële order bestaat, terwijl bijvoorbeeld het pakket of de route nog aandacht vraagt.
Een keten heeft meerdere waarheden
De verwerking van een webshoporder is zelden één API-aanroep. Eerst wordt de bronorder gevalideerd, daarna kan een debiteur of verkooporder in AFAS ontstaan en pas vervolgens een pakket bij Sendcloud of een stop in routeplanning. Iedere stap heeft een eigen externe identiteit, antwoord en herhaalbaarheid. Eén rood eindlampje voor de hele keten verbergt welke waarheid al is ontstaan.
Modelleer daarom providerstappen afzonderlijk en leg hun afhankelijkheden vast. Een logistieke stap mag bijvoorbeeld pas beginnen nadat AFAS de order heeft geaccepteerd. Faalt logistiek daarna, dan blijft de AFAS-stap voltooid. De hoofdactie krijgt “voltooid met waarschuwing” of “aandacht nodig”, niet de misleidende status “niets gebeurd”. Dit maakt Connect tot meer dan een doorgeefluik: het bewaart de toestand van het proces.
Gebruik een deelresultatenmatrix
| AFAS | Logistiek | Betekenis | Veilige actie |
|---|---|---|---|
| Niet gestart | Niet gestart | Validatie of filter hield de order tegen | Bron corrigeren of uitsluiting bevestigen |
| Geslaagd | Niet gestart | Afhankelijkheid of configuratie blokkeert | Alleen logistieke gereedheid onderzoeken |
| Geslaagd | Mislukt | Financiële identiteit bestaat | Mislukte deelstap herstellen en opnieuw uitvoeren |
| Onzeker | Niet gestart | Externe schrijfuitkomst onbekend | Eerst ontvangst bij AFAS verifiëren |
| Geslaagd | Geslaagd | Keten afgerond | Auditspoor bewaren |
De matrix voorkomt dat operations “opnieuw proberen” als universele knop gebruikt. Geef de knop een precieze betekenis: voer alleen deze providerstap opnieuw uit, herbereken afhankelijkheden en sla neveneffecten over die al een ontvangstbewijs hebben.
Fictief voorbeeld: ERP-order zonder pakket
Fictief voorbeeld: order 39014 van kampeerwebshop Buitenstroom wordt correct als verkooporder in AFAS aangemaakt. De vervolgstap naar Sendcloud faalt omdat het ingestelde afzenderaccount tijdelijk niet beschikbaar is. Desk toont de AFAS-deelstap als groen, met de externe orderidentiteit, en de pakketstap als rood met de concrete fout.
Een beheerder herstelt het Sendcloud-account en kiest “opnieuw uitvoeren” op alleen de pakketstap. De afhankelijkheidscontrole bevestigt dat AFAS nog steeds voltooid is. Er wordt één pakket gemaakt; de AFAS-verkooporder wordt niet opnieuw aangeboden. Daarna berekent de eindcontrole de hoofdstatus opnieuw. Dit fictieve scenario laat zien hoe een keten herstelbaar blijft zonder dat een technisch incident een dubbele financiële order creëert.
Acceptatiecriteria voor herstelbare ketens
- Iedere externe schrijfhandeling heeft een eigen status, pogingnummer en externe identiteit.
- Een vervolgstap noemt zichtbaar van welke geslaagde stap zij afhankelijk is.
- Een fout in een kindstap verandert een geslaagde ouder niet terug naar mislukt.
- Opnieuw uitvoeren controleert eerst bestaande ontvangst en actuele configuratie.
- De eindstatus onderscheidt volledig succes, waarschuwing en handmatige aandacht.
- Een medewerker ziet wat de klant al mag verwachten en wat nog ontbreekt.
In Desk hoort die laatste uitleg naast de order te staan, zodat klantenservice niet uit drie leveranciersportalen hoeft af te leiden wat er is gebeurd. Voor de bredere architectuur helpt het artikel over betrouwbare webshop-ERP-integraties om eigenaar en herstelpad per stap vast te leggen.
Maak ook de klantbelofte afhankelijk van het juiste deelresultaat. “Je bestelling is verwerkt” kan financieel waar zijn terwijl nog geen pakket bestaat; “je bestelling is verzonden” is dan onjuist. Definieer per extern bewijs welke interne en klantgerichte status mag veranderen. Laat bijvoorbeeld een AFAS-acceptatie alleen de administratieve verwerking bevestigen en wacht voor tracking op een echte pakketidentiteit. Controleer bij herstel of eerdere notificaties al zijn verstuurd, zodat opnieuw uitvoeren niet dezelfde e-mail of webhook naar een klantkanaal stuurt. Neem in een incidentrapport zowel de oorspronkelijke fout als de herstelactie op: welke deelstap faalde, wie veranderde de configuratie, welk bestaand bewijs werd hergebruikt en welke vervolgmelding is bewust niet herhaald. Daarmee wordt gedeeltelijk succes een beheersbare bedrijfsstatus in plaats van een technische voetnoot.
Geef iedere keten tenslotte een eigenaar voor het grijze gebied. Techniek kan de stappen tonen, maar operations beslist bijvoorbeeld of een order zonder pakket vandaag nog handmatig moet worden verzonden. Leg die beslissing bij de order vast, zodat de volgende dienst niet opnieuw begint.
Wil je een kwetsbare orderketen opdelen in aantoonbare, herstelbare stappen? Bespreek jouw providerflow met Yindle.