Pilot WMS–ERP receipt integration with a reconciliation report

The warehouse records 98 cartons against an expected 100. Ninety-four are accepted and four are held. The ERP receives “quantity 98” and marks all 98 available. The interface has transferred a number correctly while losing the decision that made four cartons unavailable.

A first receipt integration should prove one well-defined handoff between the warehouse process and the ERP. Agree the receipt scope, quantity/status meaning, correction authority and destination acknowledgement before expanding to other inventory events.

Choose one business event and one destination effect

Decide what triggers the message: physical arrival, completed receiving, acceptance, or another supported milestone. These events are not interchangeable. Choose the one that the business and installed systems can represent consistently.

Microsoft's external-ERP warehouse guidance describes receipt processing and reconciliation across the boundary. Its warning about overlapping inventory updates is relevant when selecting which feed may change the destination quantity. Microsoft Dynamics 365 — Integrating warehouse management with an external ERP.

The pilot requires a WMS receipt source, ERP sandbox or controlled test destination, item/owner/unit mappings, status rules, source and destination identifiers, a review queue and a batch reconciliation report. Receiving, inventory control, finance and integration support should each approve their part of the contract.

Define the example quantities without double counting

In this illustrative receipt, the inbound expectation is 100 cartons. The warehouse physically receives 98: 94 accepted and four held under an authorised process.

Accepted plus held equals arrived: 94 + 4 = 98. Expected minus arrived equals two not received. Do not add 98 and 94 as separate receipts.

For this example, the agreed ERP model records 98 in custody and only 94 eligible for the defined use. Another installation may represent the held quantity through a different supported process. If the destination cannot preserve the required restriction, stop and redesign the handoff rather than map the hold to available stock.

A later release of the four held cartons changes their state; it is not another four-carton physical arrival.

Write a compact interface agreement

The message needs source receipt and event identity, client/owner, site, order/ASN relationship, item, original unit, approved conversion, quantities/statuses, event time, version and correction reference where applicable.

Define whether the destination action creates a new receipt, updates an approved record or posts a supported state change. State which source is authoritative for each field. Avoid a generic endpoint that overwrites whatever inventory values it receives.

Use a versioned example record and expected destination state that receiving and finance can both explain.

For the illustrative receipt above, define a small business record before choosing a transport format:

These names are a design example, not an ERP API schema. The same E72-1 retransmitted with unchanged content must resolve to the existing receipt outcome. Different quantity content under that identity is a conflict requiring the defined correction mechanism.

After authorised release of the four held cartons, the example state changes from custody 98 / eligible 94 / held 4 to custody 98 / eligible 98 / held 0. A linked release event has zero physical-receipt increment, +4 eligible and −4 held. It must not make custody 102.

Build the failure set before enabling writes

Test a normal receipt, the partial/held example, a duplicated event, wrong unit mapping, absent owner mapping, a timeout and a correction after acceptance. Include an attempted cancellation after downstream work has used the stock.

Independently label the expected records and quantities. A pilot that passes only the clean receipt demonstrates connectivity, not business correctness.

Add a two-line receipt where the ERP accepts one line and rejects the other for an unmapped item. Require line-level outcomes and control totals; a document-level “failed” flag is too coarse for safe recovery. The accepted line remains accounted for while the rejected line follows the supported repair process. Test simultaneous duplicate submissions as well as sequential retries.

Keep acknowledgement and reconciliation separate

An acknowledgement should identify the destination transaction and its meaningful result. It does not remove the need to compare quantities, dimensions and statuses.

For each batch, show every source receipt, destination reference, accepted/rejected/uncertain interface outcome and unresolved reason. Reconcile control totals within a compatible unit and owner/site scope. Do not add cartons from unrelated items where pack meanings differ and call the sum an inventory balance.

After a timeout, use the stable reference to inspect destination state. If its outcome cannot be established, keep the message uncertain and assign support. Generating a new identity to bypass a duplicate check defeats the protection.

Restrict the interface to its approved scope

Use credentials and permissions limited to the required records and actions. A source receipt identifier should not permit access to another client's inventory. OWASP calls for object-level authorisation on identified records and actions. OWASP — Broken Object Level Authorization. Test that boundary with controlled client identities.

Log enough to diagnose the handoff while avoiding unnecessary personal information or secrets. The evidence and queue should be available to the roles responsible for correcting the problem.

Accept and recover the pilot deliberately

Proposed gates include no duplicate destination effect in retry tests, correct preservation of held quantities, visible rejection of unsupported mappings and a fully explained batch reconciliation. Measure time to acknowledgement, unresolved age and manual intervention against the existing process.

The stop procedure suspends new destination writes while preserving source events. Inventory and finance owners review already-processed transactions before any correction or replay. Resume from a reconciled population: unchanged retries retain their identities, while corrected content uses the supported versioned correction path. A mapping repair must not replay an already accepted receipt as a new arrival.

Prove the meaning of one receipt

The pilot is successful when the ERP receives the business meaning of the warehouse event, including its unresolved conditions, and both sides can prove what happened. That is the right foundation for adding dispatch, adjustment and other inventory handoffs.

Next actions

1. Choose the receipt milestone, client/site and exact destination effect.
2. Approve the ownership, unit and status mapping with operations and finance.
3. Label the normal, partial, held, duplicate and correction tests.
4. Run the sandbox handoff and reconcile every source and destination record.
5. Demonstrate stop/recovery before authorising a limited live scope.

For receipt-pilot scoping, identify the WMS, ERP, receipt milestone and the quantity or status meaning lost at the boundary.