Analyze with AI
Get AI-powered insights from this Mad Devs article:
A B2B wholesaler's storefront shows ten boxes for $960, while its ERP determines current contract prices and available stock. Before connecting checkout, the team must establish whether its existing integration can preserve the buyer's agreed terms through ERP acceptance, including when a response disappears.
This illustrative example follows one order from displayed quote to confirmed reservation. Its quantities, prices, connector capabilities, and outcome are hypothetical. The evaluation starts with the existing connector and identifies the behavior that requires an extension.
For synchronization fundamentals, see Data Synchronization Best Practices.
Use this guide to define requirements for your first B2B ecommerce ERP integration flow, compare implementation options against that order, and agree on launch checks. The resulting contract gives ecommerce, ERP, and integration teams a shared basis for accepting the work.
Key takeaways
- Customer-specific pricing must match the authorized buying company, SKU, currency, and selling unit. Verify the conversion used by both systems.
- Portal receipt and ERP acceptance need separate confirmation rules. Display availability according to its meaning; reservation requires an explicit decision.
- Acceptance tests must cover changed commercial terms, lost responses, and recovery after a restart, alongside the successful order.
- Order requirements determine the work: configure a supported connector first, extend a specific gap, and justify custom integration through behavior the available solution cannot cover.
Define the first B2B order flow
Assign ownership by business decision
Name the system and team authorized to decide account eligibility, contract prices, selling units, available-to-sell inventory, and order acceptance. A real project may assign these decisions to an ERP, an OMS, or another system. The commercetools ERP and OMS integration guides, checked November 13, 2026, separate master-data ownership from order-lifecycle responsibilities within that platform.
This system integration connects storefront requests with those decisions. Record who can change each rule and resolve a disagreement between systems.
For Leeuwerik, iO linked negotiated ERP prices to online customer accounts through customized shared catalogues. This illustrates why account-to-price mapping belongs in the integration requirements.
Agree what the buyer can rely on
A displayed quantity describes availability at a point in time. A reservation allocates stock under the inventory owner's rules. Define when price and quantity are checked again, and what the buyer sees if either changes.
Keep the first flow bounded by these assumptions:
- Account A is an active company authorized to buy.
- The order contains one SKU from one warehouse, in USD.
- The store sells boxes; ERP stock is measured in individual pieces, with 12 pieces per box.
- The ERP sets prices and performs final validation and reservation when accepting the order.
- The buyer must confirm changed prices or quantities before submission.
- Backorders are prohibited. Taxes, shipping, and payments are excluded; amounts represent the merchandise subtotal.
The commercetools OMS guide, checked November 13, 2026, also distinguishes inventory ownership from commerce-side inventory behavior. Confirm the chosen system's reservation rules before promising stock to buyers.
Turn pricing and stock rules into an order contract
Map the account, SKU, and selling unit
Resolve the signed-in user's permitted ERP account on the server. Check membership and purchasing permission through company-level authorization before retrieving prices or accepting an order. Treat account identifiers submitted by the browser as inputs requiring validation.
The price request needs Account A, the mapped SKU, USD, and the applicable unit. Maintain an explicit mapping between the storefront's box and the ERP's each unit, represented here as EA. Validate the pack size and reject quantities that cannot form complete boxes under this flow's rules.
Carry the warehouse identifier through the availability check. A stock figure from another location cannot establish how many boxes this warehouse can supply. Test the mapping with a known account price and pack size before evaluating the connector's order submission.
Revalidate the quote before submission
Refresh price and available-to-sell quantity before asking the buyer to submit. Elogic's DMI project description documents checkout validation of current pricing and stock. That supports the mechanism; the following values belong entirely to our illustrative order.
| Parameter | Initial quote | Quote after ERP validation |
|---|---|---|
| Boxes | 10 | 9 |
| Pieces per box | 12 | 12 |
| Total pieces | 120 | 108 |
| Price per piece | $8.00 | $8.50 |
| Merchandise subtotal | $960.00 | $918.00 |
The ERP now reports $8.50 per piece and 108 available pieces. The buyer agrees to nine boxes: 10 × 12 × $8 = $960 initially; 9 × 12 × $8.50 = $918 after confirmation. The lower subtotal reflects the smaller quantity; it is not an integration savings claim.
Present both changed terms together. Require confirmation of the revised quantity and unit price, and invalidate the earlier quote for submission. If the buyer declines, leave the request unsent. If validation is unavailable, hold submission and explain that current terms require confirmation.
This pre-submission check captures a snapshot. Stock can change before the ERP processes the order. Final ERP acceptance must validate the agreed conditions and reserve the quantity together under the example's rules. A further price or availability change returns the order for renewed buyer agreement. The adapter must preserve the approved terms and request renewed agreement when those terms change.
Record the agreed order intent
An order intent is the saved set of agreed terms for one operation. For this flow, record Account A, the SKU and warehouse, nine boxes / 108 EA, USD, $8.50 per EA, merchandise subtotal $918, the agreed quote version, and external reference B2B-1042.
Save the buyer's confirmation against that version. Retries preserve the operation's identity and approved payload. Define an explicit revision rule: changed terms create a new quote version requiring fresh agreement, while a pending submission remains locked until its outcome is established. Retain the previous version for comparison so an operator can identify exactly which terms reached the ERP. If a sent version is rejected, a revised submission receives a new operation reference; the old operation remains closed. Apply this rule consistently to prevent revised terms from being mistaken for a retry.
Choose configuration, extension, or a custom integration
Test the existing connector against the same order
Start with the selected solution's settings and documented capabilities. Ask its provider to demonstrate Account A's pricing, box-to-EA conversion, quote revalidation, ERP acceptance, and recovery after a lost response. Record which requirements configuration covers and the evidence for each answer.
The commercetools ERP guide, checked November 13, 2026, considers existing Connectors alongside middleware and runtime choices. Use that distinction when evaluating your own stack: a connector can run within middleware and call APIs. Development scope and execution environment are separate decisions.
Build only the uncovered behavior
Compare B2B ecommerce ERP integration solutions against the same mandatory outcomes:
| Path | When it fits | Team responsibilities |
|---|---|---|
| Configuration | Settings cover every mandatory requirement | Mapping, acceptance testing, and operations |
| Extension | Core flows work; a supported extension covers a specific gap | A defined adapter or rule, testing, and maintenance of the change |
| Custom integration | No suitable supported solution covers mandatory requirements | Contracts, flow implementation, operation state, and operations |
API access enables communication. The implementation still needs agreed field meanings, authorization, validation, failure handling, and operational ownership. Ask who maintains each extension when the connector or ERP interface changes.
For this hypothetical setup, the base connector already transfers catalog data, contract prices, and availability. Order submission requires a separate adapter with persistent operation status and recovery. The ERP interface guarantees uniqueness of the external reference for one operation and supports finding a created order by that reference. One adapter sends orders; there is no independent parallel sender.
These are assumptions of the example, with no attribution to a named product. They justify a bounded order adapter while retaining the base connector. In a real evaluation, obtain the receiving interface's documented guarantees and test them before approving that scope. If a connector setting already provides the required behavior, keep it in configuration.
Handle a timeout after the ERP receives the order
Separate receipt from ERP acceptance
The portal saves the agreed B2B-1042 intent. Its adapter submits the order, and the ERP accepts it and reserves 108 pieces. The response is lost before the adapter records confirmation. At this point, the portal can confirm receipt of the buyer's request while showing processing in progress.
Microsoft's asynchronous request-reply guidance, checked November 13, 2026, separates receipt for processing from completion and describes a way to retrieve progress. Apply that distinction to the buyer-facing state even when your interface uses different transport details.
Set the portal status to accepted only after matching the ERP ID, Account A, line contents, merchandise subtotal, and reservation result with the approved intent. If these fields disagree, keep processing unresolved and raise an exception. These status names illustrate business states. Accepted means ERP acceptance under the agreed rules; shipment occurs later. A timeout alone establishes neither rejection nor acceptance.
Recover using a durable reference
Before sending, the adapter stores B2B-1042, its approved version, and operation state in persistent storage. After the timeout, it searches the ERP using that reference. In this example, the ERP returns the previously created order. Reconciliation restores the original ERP ID without creating another order.
AWS's guidance on safe retries, checked November 13, 2026, explains how caller-provided request identifiers express intent and support duplicate handling. For an actual ERP, verify the identifier's uniqueness scope, repeat-request behavior, treatment of changed payloads, and retention period for the recorded result. Persisting a reference locally provides correlation; safe repetition also depends on the receiving system's contract.
An empty lookup result can reflect delayed processing or delayed search visibility. It is insufficient evidence for another create request. Continue checking within the documented processing window; if the outcome stays unknown and safe-repeat guarantees are absent, assign the operation to an owner for reconciliation.
Hold subsequent order changes until the previous operation's outcome is established. Preserve the reference, intent, and recovery state across adapter restarts, and record each lookup result. Recovery should let the responsible operator establish what happened before deciding the next action.
Prove the first flow is ready to launch
Verify business outcomes under failure
Run acceptance against the same approved order and its failure conditions. Capture ERP records and reservation evidence alongside portal states. Give each failed check an owner and a repeatable recovery action.
| Check | Pass criterion |
|---|---|
| Account, price, and units | One account; 9 boxes = 108 EA; $8.50/EA; merchandise subtotal $918 |
| Another company's access | Server rejects access to another company's prices and orders |
| Price or quantity changes | Buyer confirms revised terms; otherwise submission pauses |
| Response lost after ERP write | Original ERP ID recovered; no duplicate order |
| Retry and adapter restart | Correlation survives; repeated side effects prevented within the verified contract |
| Error or stalled processing | Operation has an owner, a visible cause, and a recovery action |
Use contract testing at the API boundary to verify message compatibility: required fields, types, and responses. An integration scenario must verify commercial values, persistence, reservation, and final state across the connected systems. Interface compatibility alone cannot establish that business result.
Inject the lost response after the ERP write succeeds so the test actually exercises an unknown outcome. Restart the adapter during recovery and inspect the ERP record count afterward. Keep the order reference in the evidence so the team can trace each observed state to the same operation.
Close the example with a bounded release decision
The illustrative reconciliation finds one ERP order referenced as B2B-1042 for Account A. It confirms 108 accepted pieces, merchandise subtotal $918, and the reservation. The portal then updates its status after comparing the recovered record with the approved intent. This is the scenario's specified outcome; no real connector or ERP product test is being reported.
The hypothetical team retains the base connector for catalog, prices, and availability, adds the bounded order-submission adapter, and authorizes launch after the acceptance matrix passes. The commercetools OMS guide, checked November 13, 2026, provides platform-specific guidance on order correlation, reconciliation, and operational checks.
Assign continuing responsibility explicitly:
- Ecommerce team: buyer interface and request receipt.
- ERP team: commercial rules and reservation.
- Integration owner: adapter behavior and reconciliation.
- Operations: exception investigation and recovery execution.
Monitor the age of unprocessed requests and the count of unmatched orders. Agree on escalation thresholds from project requirements, including how long a buyer may wait for a confirmed outcome. Record who receives an alert and which recovery action they can safely perform.
Conclusion
Choose one B2B order flow and write down its commercial rules, data owners, acceptance conditions, and launch checks. Make the expected buyer experience explicit whenever terms change or processing remains unresolved. Use that document to evaluate a connector with your own account, units, and order conditions.
Require evidence for every mandatory outcome before agreeing on development scope. Where configuration meets the requirement, record the setting and its acceptance result. Where a gap remains, define the smallest supported change and who will maintain it. Keep the agreed checks with the integration so future changes can be evaluated against the same business commitments.
B2B commerce & system integration Keep B2B prices, stock, and orders aligned Mad Devs can help map your account pricing, inventory, and order workflows, then build the APIs and adapters your commerce platform needs. We can define validation and recovery rules, test the integration against agreed business scenarios, and document how your team will operate it after launch. Explore integration services |
Latest articles here
