A reliable WooCommerce–AFAS integration starts with one simple agreement: exactly one system is authoritative for each piece of data. A data-ownership matrix makes that agreement visible. For each object, it records where it originates, where it may be changed and which systems only receive a copy.
Without that matrix, a quiet conflict can easily develop between systems. A customer changes an address in the online store, an employee updates it in AFAS and the next synchronisation restores one of the two versions. Everything appears technically active, but nobody knows which value is correct.
What is data ownership?
The owner of a piece of data is the system that maintains its authoritative version. That does not have to be the system where a user first enters it. A delivery address may be entered in WooCommerce, validated and then sent to AFAS as part of the order. The order address remains a snapshot, while the general customer address may be managed elsewhere.
Distinguish between concepts that look similar:
- customer profile: the customer’s current general details;
- debtor account: the accounting relationship, including terms;
- order address: the address that applied to one order;
- delivery stop: the operational destination for planning;
- billing address: the legal or financial snapshot.
If the integration treats all these addresses as one field, keeping corrections and history reliable becomes very difficult.
Build the matrix for each business object
For each relevant object, include at least these columns: business meaning, owner, entry point, permitted changes, recipients, unique key, synchronisation timing and recovery procedure. Start with objects that directly affect delivery or money.
| Object | Possible owner | Key agreement |
|---|---|---|
| Online order | WooCommerce at purchase | AFAS receives a recognisable administrative representation |
| Debtor account | AFAS | Match a new online customer against existing accounts first |
| Product identity | AFAS, PIM or the agreed catalogue | Map the SKU and AFAS code unambiguously |
| Stock | AFAS or the fulfilment system | Define sellable stock and the relevant warehouses |
| Payment | Payment provider for the transaction outcome | Accounting receives a checked transaction record |
| Delivery status | Carrier or route platform | Translate technical statuses into meaning for the customer |
These are possible choices, not a mandatory model. The essential point is that the organisation makes them explicit. Also record who owns the agreement internally. Otherwise, a technical team becomes responsible for a business decision that was never made.
Avoid symmetrical synchronisation
“Everything both ways” sounds flexible but creates more conflict rules than value. Choose a clear direction for each purpose. Stock might flow from AFAS to WooCommerce, for example. A new order flows from WooCommerce to AFAS. Order status may then flow back, but it is a different piece of data with a different owner.
Data that genuinely may be edited in several systems needs a conflict strategy. Options include timestamps, field-level ownership or an explicit review task. A simple rule such as “the latest change wins” is dangerous when system clocks, delayed messages or bulk corrections are involved.
Keep identity separate from visible labels
Use stable keys to identify objects. A product name, shipping method or customer name can change and is therefore unsuitable as a technical identity. An SKU can be useful if the organisation guarantees that it stays unique and stable; otherwise, additional mapping is needed.
The same applies to shipping methods. Match on an exact method code, rather than the translated text a customer sees at checkout. Otherwise, a small wording change could unintentionally cause a collection order to be treated as a delivery order.
Test the matrix against exceptions
A matrix is only useful if it also resolves difficult situations. Walk through at least these scenarios:
- An existing customer orders with a new delivery address.
- An unknown customer closely resembles an existing AFAS account.
- An SKU is missing or refers to several products.
- Stock changes while a customer is checking out.
- An order is changed after it has already been sent to AFAS.
- A system accepts a change, but the confirmation does not return.
For every situation, it must be clear which system decides, which information is retained and who handles an exception. This also establishes the requirements for monitoring and an administration interface.
In reliably integrating an online store and ERP we explore this process-based approach further. The specific WooCommerce–AFAS flow is described on connecting WooCommerce and AFAS. Yindle Connect provides the manageable layer between the systems involved.
Three governance questions technology cannot decide
Who may correct a piece of data?
Appoint a process owner alongside the system owner. An integration can enforce AFAS as the authoritative source for credit terms, but does not decide which employee may change a term. For each critical field, record who may correct it, where that happens and how recipients receive the change.
How long must history remain available?
For a current stock value, the latest confirmed level usually matters; for an order address, you need to be able to demonstrate what applied at purchase. Decide for each object whether you need only the current state, a change history or a complete snapshot. This prevents both insufficient evidence and unnecessary copies of personal data.
What happens during a temporary source failure?
Define whether a destination may keep showing the last known value, must block the function or should create a manual task. Some delay is often acceptable for product copy; the same choice may be irresponsible for stock, payment or a delivery promise. Add these tolerances as a column in the matrix.
Maintain the matrix as product documentation
Review the agreements whenever a warehouse, sales channel, payment process or customer type is added. For each relevant change, check whether identity, direction and retention policy remain correct. An outdated matrix is more dangerous than no matrix, because developers and users trust that the documented authority still applies.
From a matrix to workable agreements
Have e-commerce, accounting, logistics and customer service approve the matrix. Each considers a different consequence of the same data. Then translate the final decisions into mappings, validations, permissions, event filters and recovery steps. Keep the matrix as part of the functional documentation and update it when the process changes.
Want to remove ownership conflicts from an existing integration? Arrange a short process review with Yindle. We first make the data flows and exceptions visible, then determine which automation fits.