Know whether the factory received the right revision.

Sending a configured order or BOM to another system is not complete when the request leaves the browser. The factory needs to know whether the receiving application accepted the intended revision, created the right record and acknowledged it in a way that can be reconciled later. A timeout is especially important: the sender may not know whether the receiver completed the action before the connection failed.

Configurix creates custom software and connected workflows for manufacturers. An integration workstream should specify identifiers, mappings, acknowledgements, retries and exception ownership. This article focuses on reliable transfer of a released material requirement or configured order, rather than on a generic promise to connect every ERP.

Define the business action before the API call

“Send the BOM” can mean creating an item structure, attaching a document, creating an order-specific material list or releasing a production order. Those actions have different consequences. Name the intended record and the event that authorises its creation.

The interface may be an API, a controlled file import or another supported mechanism. Agree the behaviour using the actual system documentation and access available to the project. A vendor's logo on a page does not establish support for a particular transaction.

Give the transfer a stable identity

Use a transfer identifier that represents one intended business action. Keep it linked to the source revision and a fingerprint or other comparison record for the payload. A retry of the same action should retain that identity. A changed order revision should be recognised as a different business event, with rules for how it relates to the earlier one.

A proposed reference might combine the source order, revision and destination action. The exact format is less important than uniqueness, scope and lifecycle. Decide how long the receiver remembers a completed action and how the sender reconciles an older transfer after that period.

If the receiver supports an idempotency mechanism, document its precise guarantees. Stripe's API documentation gives a concrete example of a service that recognises repeated requests under an idempotency key. That is an example of the pattern, not evidence that an ERP implements the same behaviour. Stripe: idempotent requests.

Understand the timeout problem

Suppose the receiving system creates an order, but its acknowledgement does not reach the sender. A blind retry could create a duplicate if the interface has no duplicate protection. Reporting “failed” may also be misleading because the business action succeeded remotely.

Use a state such as “awaiting confirmation” when the result is genuinely unknown. The recovery process should check the destination using the agreed transfer or source reference before deciding whether to resend. If the destination cannot be queried or deduplicate requests, include that limitation in the process design.

Open full-size image (new tab)

The person responsible for the exception needs enough context to investigate: source revision, action, transfer identity, last attempt and destination response. Keep credentials and unnecessary customer details out of operational error messages.

Validate fields before and after sending

Validate required fields, allowed units, component mappings and revision references before transfer. A material named differently in two systems needs an explicit mapping, not a guessed string match. Decide how unknown and discontinued references are handled.

Then validate the acknowledgement. A successful transport response may mean only that a request was received or queued. It may not mean the downstream order is released for production. Preserve the destination record identifier and the business status returned by the receiving process.

For a file import, define the file identity, checksum or comparison method, naming convention and acceptance report. A file appearing in a folder is not an acceptance acknowledgement. The receiving team must be able to identify which rows were accepted, rejected or left pending.

Handle partial success without hiding it

An interface may accept the order header but reject a material line. Decide whether the action is atomic, whether partial records are allowed and how the sender learns about them. Do not report the whole transfer as complete because one stage succeeded.

If a correction is needed, define whether it updates the existing destination record or submits a new revision. Repeatedly creating new records to work around an error can leave the factory with duplicates and conflicting versions. Keep the corrective action associated with the original transfer.

A cancellation also needs its own business rules. An order already in production may not be cancellable through the same endpoint used for an unstarted order. The software should reflect the receiving system's status and route the decision to the appropriate owner.

Test recovery as part of acceptance

Use a test environment or controlled acceptance setup for transfer tests. Include an ordinary order, an unknown component, a unit mismatch, a repeated submission, a timeout and a corrected revision. Record the expected source and destination records before the test.

The duplicate test should confirm that one intended business action creates only the agreed result. The timeout test should verify the reconciliation path, not merely show an error banner. The changed-payload test should establish that a previous transfer identity cannot silently refer to different data.

Also test authentication failure and access scope. Use credentials appropriate to the required action and keep them on the trusted server side. Agree credential ownership, rotation and incident handling with the teams responsible for the connected systems.

Is retrying a failed request always safe?

No. Safety depends on the operation, the receiving system's guarantees and whether the earlier result is known. Reconcile uncertain outcomes before repeating an action that could create or release another record.

Does a 200 response mean production can start?

Only if the documented business contract gives it that meaning. Many interfaces acknowledge receipt before completing processing. Display the actual agreed business state.

Can we begin with a file export?

Yes. A controlled file workflow can be a practical first scope when its identity, validation and acceptance process are clear. The factory still needs a way to prevent duplicate imports and reconcile rejected rows.

Review product configurator integrations with Configurix and bring the receiving system's transaction specification. Connect that discussion to custom factory software so the interface supports a clearly defined business action.