What the integration must move
Start with the buyer journey. A shopper finds a product, sees a price and availability, places an order, then expects a meaningful status. Write down the systems involved at each step: ERP, commerce backend, storefront, warehouse, payment provider and CRM. Do not assume that one connector covers every direction.
Separate catalog publication from order processing. A delayed product description may be tolerable; a stale price or a missing order may not be. Agree on an acceptable delay for each data type and on the person who investigates a mismatch.
Assign a source of truth
For every field, choose one system that can change it. Other systems receive a copy or send a proposed change. For example, ERP may own warehouse quantities while the commerce backend owns the customer basket. If both can overwrite the same price, the last update wins unpredictably unless you define a rule.
Write a field and event contract
A short field dictionary prevents two teams from using the same word for different values. This sample is a starting point; replace it with your systems, identifiers and acceptance rules.
| Data | Example direction | Acceptance check |
|---|---|---|
| Product ID and variant ID | ERP → storefront | Keep stable identifiers; confirm how deleted or merged items are handled. |
| Price and currency | ERP → storefront | Map price types and customer groups; compare displayed and checkout prices. |
| Stock by warehouse | ERP → storefront | Define the quantity buyers can order and the maximum acceptable data age. |
| Order and line IDs | Storefront → ERP | Retry the same order without creating a second ERP order. |
| Order and fulfilment status | ERP → storefront | Map allowed transitions; keep a record of rejected or unknown statuses. |
Add the exchange format, field type, required values, update trigger and version to the actual contract. Preserve the source event ID so a retry can be recognized. If customer-specific prices or hidden items exist, check authorization before showing them in search or product results.
Test failures and recovery
A successful first sync proves little about daily operation. Test a temporary ERP outage, a timeout after the ERP has accepted an order, a repeated event, an older stock update arriving after a newer one, an invalid product field and a deleted item. Record the expected result and how the team will see and repair each failure.
- Retry recoverable failures without duplicating orders.
- Quarantine invalid data so it does not silently overwrite good data.
- Alert on growing queues and on updates older than the agreed limit.
- Compare source and destination totals for orders, products and stock.
- Keep a manual reconciliation path for exceptions that need a decision.
Retries reduce the effect of an outage; reconciliation tells you whether the systems eventually agree. Both need an owner and a documented procedure.
Launch and reconciliation checklist
- Take a baseline export of products, prices, stock and open orders.
- Run the integration on a representative data copy and compare counts.
- Place test orders with normal, unavailable and customer-specific items.
- Change price and stock in the owner system; measure when the store reflects them.
- Simulate an API failure and verify alert, retry and reconciliation.
- Enable one flow or audience first; keep a documented return path.
- Review exceptions daily until the agreed launch criteria hold.
Avoid declaring success from a green deployment alone. Sign off on data correctness, order processing and recovery separately. Keep sample IDs and timestamps so another person can reproduce the checks.
A live project and the next step
Our Ur-Met project combines a large industrial catalog with 1C and CRM integrations on Frontbox. Its published case illustrates the storefront and business-system context; the field contract and failure checks for your project still depend on your own ERP configuration and operating rules.
If you are planning an exchange, start with the systems, directions, catalog size and the hardest five order or stock cases. Our integration service scopes the schema and implementation. If your existing store already handles the exchange, keep that path and test it before replacing anything.