ERP and the distribution execution layer: dividing responsibility

In detail

Problems start when both systems claim ownership of the same fact. A customer, price, stock balance or document status is then edited in more than one place, and integration becomes a continuous reconciliation exercise.

A resilient architecture assigns ownership by data type. ERP may own item master data, financial accounting and final documents; the execution layer may own visit plans, verified outlet activity, orders, field evidence and operational exceptions.

Data exchange should follow business events: what changed, who needs it and how the receiving system confirms acceptance. An integration error needs an observable review queue and an owner rather than disappearing inside a technical log.

How it is applied

• List the shared entities and assign one system of record to each of them.
• Define the business events that trigger an exchange and the minimum message payload.
• Map external and internal identifiers without manual matching in each transaction.
• Add idempotency, controlled retries and an observable error log.
• Test the end-to-end path from a master-data change to an accepted business document.

Practical checklist

• Every shared entity has one named data owner.
• Exchange direction and frequency follow an explicit business need.
• A repeated message does not create a duplicate transaction.
• The team can see an error, its business impact and the person accountable for resolution.

Scope and limits

An integration architecture does not imply a ready-made connector for every ERP. Objects, exchange direction, frequency, security and responsibilities are agreed for each implementation.

Where this lives in the platform

• For IT directors
• Integrations with Existing ERP and External Systems
• Green Line Trading: product traceability, customer master data and delivery control