ERP and the distribution execution layer: dividing responsibility

For IT, sales and operations leaders, the key question is where a particular value can be changed and who owns the outcome. If a price, customer or order status is corrected independently in two systems, the team gets conflicting versions of the same process. Clear responsibility establishes which data to trust and where corrections belong, while retaining the required functions of both ERP and the execution layer.

Assign ownership to a fact or field. In an agreed design, for example, Smartup holds the visit record and original order request, while ERP holds the linked document and its accounting status. An ERP response does not transfer ownership of the whole visit. Agree a separate action and result confirmation for changing or cancelling an accepted order. Cancelling a request does not automatically reverse a completed shipment: define how linked documents are handled. A late acceptance response must not reactivate a cancelled order.

Agree the data scope and acceptable delay for each flow. A product name does not replace a shared ID; a price needs a currency, unit, validity period and version. Inactive records, late updates and partial batch acceptance need explicit rules. A record missing from an incomplete export does not establish that it was deleted or cancelled. Agree an explicit status-change signal and a way to reconcile the complete dataset; the last exchange time alone does not show which records were applied.

Sent, received and applied are distinct states. A receipt acknowledgement does not establish that ERP has registered an order, reserved stock or posted a document. A lost response leaves the outcome unknown. Provide a way to check the result by the original identifier; retry only under an agreed protocol that prevents duplicates. Changed content must not be presented as the original attempt under the same key.

A temporary network failure and a business-rule rejection need different responses. Retrying cannot fix an unknown product, a wrong unit or disallowed order terms. The investigation queue should identify the affected operation, reason and owner. After correction, verify the outcome in both systems, including partially processed records; removing an error from a log does not prove that the process is complete.

Before launch, separate the initial data load from ongoing changes. Define the initial dataset, a checkpoint and how changes made during the load will be captured. In the pilot, verify that the handover neither loses new records nor overwrites them with an older export. Bring an anonymised order example with its change or cancellation, system versions and process owners to the discussion. The outcome should be an agreed exchange map with acceptance criteria. An API alone does not establish readiness for the customer configuration.