Bills of materials and batch records

Agree the movement contract before sending production data.

Choose the actual source event that should create a consumption movement. An ingredient reservation, an issue to production and a confirmed physical addition are different events. Agree the destination movement meaning and the source review state required for transmission. If the ERP expects material, plant, storage location and lot identifiers, resolve those mappings explicitly rather than relying on display names.

Define quantities and units at the boundary. If the source records 2.40 kg and the receiving movement is expressed in grams, the agreed quantity is 2,400 g. Preserve the original source quantity and the conversion applied. Check whether the destination expects a positive consumption quantity with a movement type or a signed quantity; do not infer that convention from a field called 'amount'.

Retain the intended transaction through an uncertain delivery.

Create the outbound transaction from the source event and record its immutable identity before the first send. Retain each attempt separately with its time, response classification and relevant evidence. A second attempt is not a second physical consumption event. The batch quantity must continue to reflect the actual execution even when the integration is unavailable.

Confirm whether the ERP supports an idempotency key, an external document reference, a searchable transaction identifier or another supported reconciliation route. Specify what that mechanism guarantees and how long its identity is retained. Sending the same key only prevents duplication if the destination actually honours that contract; a local 'sent' flag cannot guarantee exactly-once processing across two systems.

For the timeout in the example, inspect the destination outcome before authorising a new movement. Match M-88421 using the agreed identity and verify material, location, lot, quantity and unit. If the destination exposes no safe lookup or retry contract, route the uncertain case to the responsible owner. Preserve the unresolved state rather than turning absence of a response into a definite rejection.

Treat a corrected consumption as new controlled work.

Suppose the accepted source quantity later changes from 2.40 kg to 2.10 kg after a documented correction. Do not silently alter the payload recorded for the already posted TX-610-007. Retain the original event and transaction, the correction reason, and the authorised destination adjustment. The receiving ERP may require a reversal and replacement or a separate adjustment; use its supported accounting and inventory workflow.

The reconciliation must explain both systems' final state from their event histories. A net total that happens to agree is insufficient if one destination movement belongs to the wrong lot or location. Group the review by transaction identity and material context, then calculate the net quantities from the matched movements and authorised corrections.

Define what counts as a matching destination movement.

For TX-610-007, capture a reconciliation record containing the source event identity, intended destination operation, external reference, material, lot, plant/location, quantity, unit and any applicable posting date. Compare the supported destination lookup with that entire contract. A movement for 2.40 kg of the same material is a candidate; it is not necessarily this movement when two additions legitimately have equal quantities.

Classify the lookup explicitly. One matching destination identity with matching required fields resolves the delivery. A record with the expected reference but 2.10 kg instead of 2.40 kg is a conflict for the transaction owner. Multiple candidate matches require investigation. No visible match remains uncertain if the query is delayed or incomplete; retry is appropriate only under the operation’s supported recovery rules and the evidence available.

Retain the lookup time and the actual matched destination document with the outbound attempt. If a later source correction changes the accepted consumption, begin the separately authorized correction process against that document. Updating a local payload or clearing its sent flag cannot change the physical event or reverse an already posted movement.

Configure the exchange history and recovery review in Seal.

Use Templates for source events, transactions and recovery assessments, linked through Reference fields. Store quantities as Number fields with explicit units, destination identifiers as defined mapping fields, and send/acknowledgement timing as Time & date values. Attach relevant source exports, responses and reconciliation reports as Files. Keep credentials and unrelated personal data out of record evidence.

The connection itself requires a configured Script or supported integration route with the appropriate access. Agree where retries run, which owner sees rejected or unknown outcomes, and how the receiver's response is recorded. A scheduled retry process must be configured; the presence of an unresolved record does not automatically create one. Use the platform documentation and the selected ERP's current interface documentation when implementing the actual code.

Use Seal review requirements and Checks for the controlled decisions you need—for example, requiring destination evidence and a rationale before publishing a recovery assessment. These publication checks do not prove that a remote movement has occurred. Test the interface in an authorised non-production environment, including a response lost after destination commit, before relying on it for routine inventory exchange.

Source consumption event

Represents the manufacturing fact. Its identity remains stable across every delivery attempt.

Source event — Text

USE-610-007; identify the actual event, not only the batch.

Batch, step and container — References

B-610, step 7 and C-610-04, with the material-lot relationship.

Quantity and unit — Number / Select

2.40 and kg, retaining the defined quantity being transferred.

Execution and review basis — References

The source records establishing which consumption event is permitted to be sent.

Outbound transaction and attempts

Separates the one intended movement from its network delivery history.

Transaction identity — Text

TX-610-007; reuse the intended transaction identity during a supported retry.

Source event — Reference

USE-610-007, allowing the batch reviewer to find the integration history.

Destination mapping — Text / References

ERP material, plant or site, storage location, lot and the configured movement meaning.

Payload revision and evidence — Text / Reference to File

Retain the exact agreed payload or a safely redacted representation for review.

Attempt identity and timing — Text / Time & date

ATT-610-01 and any later attempts, each with its actual send and response history.

Exchange state — Select

For example: prepared, sent, acknowledged, rejected or outcome unknown; define these states in the connection.

Destination acknowledgement and reconciliation

Records what the ERP confirms, including any mismatch requiring resolution.

ERP movement identity — Text

M-88421, from the destination's supported response or reconciliation evidence.

Acknowledged transaction — Reference / Text

The verified relationship to TX-610-007, not a match based only on quantity.

Posted quantity and unit — Number / Select

The destination quantity and its unit, compared with the intended transaction.

Reconciliation result — Select / Text

Matched, rejected, mismatched or unresolved, with the reason and source evidence.

Recovery owner and actions — User / References

The responsible integration or inventory owner and any authorised correction work.

Destination commits before the response is lost

Input: Send TX-610-007 for 2.40 kg, let the test ERP create M-88421, then simulate loss of the response.

Expected: The sender records an unknown outcome. Recovery locates and verifies M-88421 using the agreed identity. The reconciled destination contains one intended consumption, with both the original attempt and recovery evidence retained.

Quantity is numerically equal but the unit is wrong

Input: Return destination evidence showing 2.40 g for an intended 2.40 kg transaction.

Expected: Reconciliation reports a quantity/unit mismatch. It does not mark the exchange matched because the numeric values are equal.

The same batch contains two legitimate additions

Input: Create separate source events for two additions from the same lot in B-610, each consuming 2.40 kg.

Expected: Each event retains its own intended transaction. Duplicate prevention does not collapse legitimate movements merely because batch, material and quantity match.