{"id":114,"date":"2026-09-23T09:00:00","date_gmt":"2026-09-23T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=114"},"modified":"2026-09-23T09:00:00","modified_gmt":"2026-09-23T07:00:00","slug":"afas-succes-vervolgsysteem-mislukt","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/afas-succeeded-the-downstream-system-failed-what-now\/","title":{"rendered":"AFAS succeeded, the downstream system failed: what now?"},"content":{"rendered":"

If AFAS succeeds but a downstream system fails, preserve the successful part and recover only the failed dependency. Do not rerun the whole order chain. A partial result is not an unclear failure: it is a known state in which the financial order exists while, for example, the parcel or route still needs attention.<\/p>\n

A chain has several established facts<\/h2>\n

Processing an online store order rarely consists of one API call. First the source order is validated, then a debtor record or sales order may be created in AFAS, and only afterwards a parcel in Sendcloud or a stop in route planning. Each step has its own external identity, response and repeatability. One red indicator for the entire chain hides which facts have already been established.<\/p>\n

Model provider steps separately and record their dependencies. A logistics step may only begin once AFAS has accepted the order, for example. If logistics then fails, the AFAS step remains complete. The main action receives \u201ccompleted with warning\u201d or \u201cattention needed\u201d, not the misleading status \u201cnothing happened\u201d. This makes Connect<\/a> more than a forwarding service: it retains the state of the process.<\/p>\n

Use a partial-results matrix<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
AFAS<\/th>\nLogistics<\/th>\nMeaning<\/th>\nSafe action<\/th>\n<\/tr>\n<\/thead>\n
Not started<\/td>\nNot started<\/td>\nValidation or a filter stopped the order<\/td>\nCorrect the source or confirm the exclusion<\/td>\n<\/tr>\n
Succeeded<\/td>\nNot started<\/td>\nA dependency or configuration is blocking progress<\/td>\nInvestigate logistics readiness only<\/td>\n<\/tr>\n
Succeeded<\/td>\nFailed<\/td>\nThe financial identity exists<\/td>\nRecover and rerun the failed substep<\/td>\n<\/tr>\n
Uncertain<\/td>\nNot started<\/td>\nThe outcome of the external write is unknown<\/td>\nFirst verify receipt in AFAS<\/td>\n<\/tr>\n
Succeeded<\/td>\nSucceeded<\/td>\nChain complete<\/td>\nRetain the audit trail<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The matrix prevents operations from using \u201cretry\u201d as a universal button. Give the button a precise meaning: rerun only this provider step, recalculate dependencies and skip side effects that already have a receipt.<\/p>\n

Fictional example: an ERP order without a parcel<\/h2>\n

Fictional example: order 39014 from camping online store Buitenstroom is correctly created as a sales order in AFAS. The subsequent Sendcloud step fails because the configured sender account is temporarily unavailable. Desk shows the AFAS substep in green with its external order identity, and the parcel step in red with the specific error.<\/p>\n

An administrator restores the Sendcloud account and selects \u201crerun\u201d for the parcel step only. The dependency check confirms that AFAS is still complete. One parcel is created; the AFAS sales order is not submitted again. The final check then recalculates the main status. This fictional scenario shows how a chain remains recoverable without a technical incident creating a duplicate financial order.<\/p>\n

Acceptance criteria for recoverable chains<\/h2>\n