Assign one authority to each important data field
As in a CRM and ecommerce integration plan, document direction at field level. Product copy may belong to the store, stock to the ERP and sales conversations to the CRM. Calling every connection bidirectional does not resolve conflicting edits to the same field.
For example, a promotional price entered in the store might disappear after the next ERP update. That could be an implementation defect or an undefined ownership rule. Distinguish source price, selling price and promotion logic. Check whether an update causes the other system to emit the same change back again.
The handover should identify the object, field, direction, update condition and owner. Review the decisions when a source system changes. Describing the ERP as the master system is not sufficient detail to explain how every field should behave.
Field matrix
Name the authority for stock, prices, descriptions, customer identity and order state. State why other systems need a copy.
Conflict decision
If both systems change a value, specify which approved rule resolves it. Silent overwriting is not a business decision.
Loop evidence
Demonstrate that an update does not repeatedly generate itself across the connection. Retain the originating transaction relationship.
Prove product and customer matches with representative records
The product data checklist distinguishes SKUs, barcodes and variant identities. Where an ERP supports several selling units, state which one the store record represents. Spaces or leading zeros in identifiers can affect matching and should not disappear during normalisation without a decision.
An illustrative wholesaler sells boxes containing several components. Two boxes ordered online must not become two individual pieces in the ERP. Verify unit conversion, pack quantity and the unit to which the price belongs with operations. Equal product counts cannot prove that relationship.
Do not merge customers automatically only because names look similar or a phone number matches. Guest purchases, company accounts and alternate delivery addresses are separate cases. Agree identity keys and review behaviour, using suitable synthetic or masked records where personal information is unnecessary for testing.
Product mapping
Keep examples connecting the source code, target identity, unit and variant. Unknown references need an explicit failure rather than a guessed substitute.
Customer mapping
Separate new, known and ambiguous identities. Records that cannot be matched safely should enter an owned review process.
FROM READING TO A NEXT STEP
Review the failure path as well as the successful order
Share source systems, inventory authority and a representative order flow. We can define integration acceptance and operating support as concrete deliverables.
Distinguish physical stock from available-to-sell quantity
Store operations management should establish the business owner of inventory decisions. Physical quantity, reserved quantity and sellable availability can differ. The approved calculation must follow the actual warehouse and trading process rather than a universal formula copied from another business.
With several warehouses or channels, document which location supplies each selling surface. Choose update frequency against sales velocity and connection capacity. Instead of relying on a real-time label, measure the interval between the source change and the storefront result with representative records.
In an illustrative case, the same product sells through the website and a marketplace close together. Check where reservation occurs and how insufficient inventory is resolved. Separately define whether a return request affects sellable stock before a physical inspection has taken place. That decision belongs to the approved operating process.
Map order states, cancellations and reverse flows
Backend integration development needs compatible meanings across the two order lifecycles. Payment received, ERP accepted, ready for dispatch and delivered are different states. Identify the evidence supporting the status shown to the shopper and the actions it permits.
A partial shipment should not mark every line as fulfilled. A return request, financial refund and physical stock receipt are also different operations. Finance and warehouse owners approve their respective completion conditions. One generic returned status can conceal several unfinished responsibilities.
An order may enter preparation while a cancellation travels to the ERP. That situation can need an exception task rather than an automatic reversal. Keep an approved state map describing permitted transitions and changes that require an authorised person’s decision.
Acceptance record
Relate the source order to the ERP order identity. Check a transport response separately from acceptance of the business record.
Reverse flow
Test financial, dispatch and inventory effects of cancellations and returns independently. One generic status is not sufficient proof.
Exception decision
Route changes to processed orders to the appropriate owner. Preserve the actual transaction history rather than forcing a misleading earlier state.
Test repeat delivery, delayed responses and outages
DevOps and operating setup should make failures visible and recovery controlled. Duplicate events, slow destination responses and transactions completed without a received response are different conditions. Check whether any of them creates an additional order.
A stable source transaction identity and destination relationship can support repeat-safe processing, but the method must be verified with the actual API. Not every failure is suitable for an automatic retry. Repeatedly sending an invalid product reference requires a data correction, not more attempts.
The exception queue needs transaction type, an understandable cause, last attempt and an accountable team. Avoid retaining unnecessary personal information or secrets in logs. Restrict recovery actions to authorised users. Acceptance should establish that someone knows the resolution path, not merely that an alert was emitted.
Release with reconciliation and an operating handover
The CI/CD and operating process should make the deployed connector version and changes traceable. Decide which checks repeat when a field or provider version changes. Assign ownership for credential rotation, access removal and communication during an outage.
Regular reconciliation examines whether source and target completed the same business work. Compare orders, relevant totals and states over an appropriate period. Differences should produce understandable records for review rather than blindly rewriting every value. A mass correction that violates business rules creates another incident.
The initial release can cover a small representative flow. Deliver field mappings, the state vocabulary, selected success and failure evidence, reconciliation methods and operating owners. Those records make a discussion with Prix Studio more precise by separating connection delivery from continued support.
Reconciliation owner
State who reviews differences and when. Each investigated discrepancy should have a correction decision and closure evidence.
Operating guide
Provide short tasks for outages, access changes and safe repeat processing. Have the support owner rehearse a realistic exception.
Get the checklist and discuss your scope
Your email and phone are used for this request. This does not subscribe you to a newsletter.
BEFORE YOU DECIDE
Frequently asked questions
Should integration always be bidirectional?
No. Define direction for each object and field. Independent edits to the same value can create conflicts or loops; bidirectional behaviour needs a demonstrated requirement and an approved resolution rule.
Must stock always update in real time?
Consider sales velocity, reservation behaviour and API capacity. Define and measure acceptable delay. A real-time label alone does not demonstrate operational quality or prevent overselling.
What should happen when the same order arrives twice?
The target should recognise the existing transaction rather than create another independent order. Verify the identity and repeat-handling rule with the actual API instead of relying solely on a connector promise.
Should stock increase as soon as a return is requested?
Follow the approved warehouse process. Request, physical receipt, financial refund and suitability for resale may be separate events. The checklist checks that technical behaviour matches that decision.
Is an error queue sufficient?
It needs understandable causes, owners and safe resolution actions. Reconciliation should also detect transactions missing without a visible queued error. Alert counts alone do not establish resolution.
What belongs in the integration handover?
Field and state mappings, identity relationships, selected success and failure tests, duplicate-processing evidence, reconciliation methods and an operating guide. One successful order cannot accept the entire scope.
LET’S DEFINE THE SCOPE
Review the failure path as well as the successful order
Share source systems, inventory authority and a representative order flow. We can define integration acceptance and operating support as concrete deliverables.
Discuss integration acceptance