Product configurator ERP integration
Connect the accepted configuration—not another copy of it.
Configurix can connect governed product choices, interactive 3D, scoped pricing, quotes and customer approval to an ERP order or operational handoff. A reliable integration defines who owns every field, what triggers delivery, how revisions map and how both systems recover when reality rejects the request.
One transaction
Configuration to acknowledged order
Configured project
CFG-2048 · revision 7
Accepted quote
Q-1842 · EUR 18,460
ERP command
Idempotency · CFG-2048-R7
ERP acknowledgement
SO-78114 · accepted
Success is not “the API responded.” Success is an accepted ERP record that reconciles to the exact product, price, quote and customer revision.
Integration definition
ERP integration is a business-state contract, not a data pipe.
A product configurator and ERP solve different parts of the journey. The configurator guides a customer, dealer or salesperson through permitted choices and commercial actions. ERP manages authoritative orders and core operational processes. Integration makes the accepted transition explicit while keeping product, customer, price and fulfillment responsibilities with named systems.
ERP to configurator
- Customer and account identities
- Sellable products and lifecycle status
- Price lists, costs or commercial references
- Currency, tax, payment and delivery context
- Inventory, availability or lead-time indicators
- Order, production, shipment and invoice status
Configurator to ERP
- Configuration ID and accepted revision
- Product, option and characteristic identities
- Dimensions, quantities and derived values
- Commercial lines, services and approvals
- Customer, site and delivery context
- Quote, document and customer-acceptance references
Reconciliation loop
- ERP order or configured-item identifier
- Accepted, rejected or review-required status
- Field-level validation errors
- Price or availability changes
- Safe retry and duplicate protection
- Change, cancellation and fulfillment status
Interactive ERP architecture planner
Define the transaction before selecting the connector.
Select the closest operating model. The result identifies the contracts to specify and test; the actual endpoints and supported capabilities depend on the ERP environment and signed Configurix scope.
System-of-record matrix
One business meaning. Named system authority.
| System | Typical authority | Boundary to resolve |
|---|---|---|
| PIM | Names, classifications, technical and marketing attributes, media references and market content | Do not assume PIM represents executable configuration or order rules. |
| PLM or engineering | Released engineering structures, effectivity, drawings, specifications and technical change | Define which released data becomes sales configuration knowledge. |
| Configurix | Guided choices, accepted rule state, interactive 3D, scoped price, quote and project revision | Name every price, BOM and order behavior included in the working scope. |
| CRM | Account relationship, contact, opportunity, activity, owner and sales stage | Use shared identifiers rather than duplicating the authoritative customer history. |
| ERP | Sales orders, materials, inventory, procurement, finance, fulfillment and authoritative operational status | Specify whether ERP also owns product, price, BOM or configured-item creation. |
| MES or operations | Work execution, production status, quality, installation or field delivery | Receive only the released information required for the accepted operational step. |
Configured-order contract
Carry the accepted product state into ERP.
The handoff must remain meaningful without the original browser session. Stable identities, versions, validity and delivery controls let the ERP validate the same customer and commercial state that Configurix presented.
CorrelationConfiguration, quote, opportunity, cart, payment and ERP request identifiers
RevisionCatalogue, rule, configuration, price, document and schema versions
Account contextCustomer, sold-to, ship-to, bill-to, dealer, market, currency and tax context
Product stateFamily, model, characteristics, option IDs, dimensions, quantities and derived values
ValidityComplete, valid, review-required, approved and order-permitted states with reason codes
Commercial statePrice list, lines, discounts, services, tax, totals, approvals and validity timestamp
Operational mappingERP materials, configured item, components, BOM, routing or service identifiers
Customer evidenceAccepted quote, specification, images, terms, signature or checkout references
Delivery controlDestination, idempotency key, attempt, acknowledgement, error and safe-retry state
Change controlPrevious revision, changed fields, downstream impact, reapproval and supersession
Integration patterns
Use the pattern that matches the decision.
Synchronous request
Use when: Price, validation or order response is required before the user can continue.
Strength: Immediate result and clear customer feedback.
Control: ERP latency or downtime can block the journey; timeouts and fallback must be designed.
Asynchronous command
Use when: An accepted project submits an order request and receives the ERP result later.
Strength: The customer workflow can acknowledge receipt without waiting for every ERP action.
Control: Requires durable status, idempotency, retry, reconciliation and user-visible pending states.
Event or webhook
Use when: Order, product, price or fulfillment changes should notify another system.
Strength: Reduces polling and supports loosely coupled process updates.
Control: Delivery order, duplicates, authentication, replay and failed subscribers need control.
Scheduled synchronization
Use when: Products, accounts, price lists or status can move on an accepted interval.
Strength: Useful for larger reference sets and systems without event support.
Control: Users need freshness timestamps and rules for changes between synchronization runs.
Managed file exchange
Use when: The ERP accepts CSV, XML, JSON, EDI or another governed file contract.
Strength: Practical when no suitable API exists and the batch process is operationally accepted.
Control: Schema drift, partial failures, duplicates, transport security and acknowledgements remain essential.
Hybrid architecture
Use when: Different data and decisions have different urgency, volume and system capability.
Strength: Uses the appropriate pattern for reference sync, live decisions, commands and status.
Control: Requires an explicit authority and sequencing map so several paths do not create conflicting truth.
Reliability controls
Design for duplicates, stale data and rejection.
Stable identifiers
Map immutable product, option, component, account and project identities—not display labels.
Schema versioning
Version request and response contracts and define compatible change, deprecation and migration behavior.
Idempotent commands
A repeated accepted-order request must not create another order or configured item.
Explicit acknowledgement
Record what the ERP accepted, rejected or changed and the authoritative destination identity.
Field-level errors
Return actionable reasons for unknown material, invalid account, stale price, missing field or blocked state.
Safe retry
Classify transient and permanent errors, preserve attempt history and avoid uncontrolled automatic loops.
Reconciliation
Compare expected and actual records by correlation ID, revision, totals, line count and state.
Observability
Log latency, volume, status, retries, dead letters and mismatches without exposing sensitive data.
Historical integrity
Do not let current catalogue or price data silently rewrite an earlier accepted configuration.
Operational ownership
Name who responds when the configurator, integration layer or ERP rejects or delays a transaction.
Implementation blueprint
From representative order to accepted integration.
Define the business transition
Choose the exact endpoint: reference lookup, qualified opportunity, approved quote, sales order, configured item, BOM review or operational work package.
Select one representative product
Include dimensions, options, services, account context, a boundary condition and a known ERP rejection.
Assign field and state authority
Map product, rules, price, customer, tax, order, inventory, BOM, routing, documents and status to responsible systems.
Design the canonical contract
Use stable identities, explicit units, versions, classification, price status and customer evidence independent of one screen layout.
Choose integration patterns
Match synchronous, asynchronous, event, synchronization or file patterns to urgency and system capability.
Implement security and controls
Scope service identity, network path, secrets, authorization, validation, rate limits, audit and data minimization.
Prove normal and failure paths
Test accepted, duplicate, stale, invalid, unavailable, timeout, partial and changed-after-acceptance cases.
Release with reconciliation
Observe real transactions, compare source and destination, assign incidents and version the integration as product knowledge changes.
Security boundary
Protect the command that creates operational truth.
ERP integrations handle customer, commercial and operational data and may create financially or physically consequential records. Security belongs in the service architecture and acceptance plan, not only the login screen.
Service identity
Use a dedicated non-human identity with the minimum permitted operations and environments.
Server-side authorization
Keep ERP credentials, privileged pricing and order commands outside public browser code.
Transport protection
Use accepted encrypted transport, endpoint validation and controlled network exposure.
Secret lifecycle
Store, rotate, revoke and audit credentials without embedding them in repositories or customer payloads.
Input validation
Validate schema, type, length, enum, unit, identity and business state before calling the ERP.
Object access
Verify the acting user or account may read or change the referenced project and commercial context.
Data minimization
Send only the customer, product and operational fields required for the defined business transition.
Audit and retention
Record decisions and delivery evidence while limiting sensitive content and enforcing accepted retention.
Working acceptance matrix
Twelve tests before the integration can create real orders.
The configurator and ERP use agreed stable product, option, component, account and unit identities for the representative product.
A known valid configuration creates or updates the intended ERP record with the accepted field values and no manual re-entry.
A known invalid or obsolete product, option or account is rejected with a useful reason and does not create a partial order.
Normal, boundary, account, currency, service, discount, tax and rounding price fixtures reconcile with the named authority.
The 3D state, specification, price, quote and ERP payload reference the same configuration and document revision.
A repeat of the same order command returns or reconciles to the existing ERP result instead of creating a duplicate.
A timeout or temporary ERP failure preserves the customer project and can retry safely without losing acceptance evidence.
A permanent rejection assigns an owner, displays an actionable status and retains request, response and correlation evidence.
A product or price update between configuration and order triggers the accepted refresh, warning, reprice or reapproval path.
A change after ERP acceptance creates the required new revision and follows the defined update, cancellation or replacement process.
The destination acknowledgement, ERP identifier and authoritative order status are visible and reconcilable from the source project.
Logs, exports and support views protect customer, commercial and credential data according to the agreed access and retention policy.
Failure patterns
What “ERP integrated” can hide.
The integration is described by a logo
An ERP name does not define product, price, order, BOM, status, revision or failure behavior.
Every system becomes a source of truth
The same product, price or customer field can change in several places without authority or reconciliation.
Translated labels become keys
A renamed option or localized description breaks mappings because visible text replaces stable identity.
Quote acceptance creates an incomplete order
Required account, tax, delivery, component or approval fields are discovered only after handoff.
Retries create duplicates
A timeout makes the source repeat a successful request because no idempotency or acknowledgement exists.
ERP downtime freezes product exploration
A synchronous dependency blocks the whole customer experience even when only order creation needs ERP.
Current data rewrites history
A new price list, product revision or component substitution silently changes an accepted configuration.
Success means HTTP 200
The transport responded, but the expected order, lines, totals and state were never reconciled in the ERP.
Primary technical references
Use documented contracts—not connector assumptions.
SAP · ERP integration for SAP CPQ Quote
Primary integration guidance for synchronizing products, prices and customers and continuing quote data into ERP.
Open primary sourceSAP · CPQ configuration and quote-to-order setup
Primary documentation covering product replication, pricing-condition mapping and sales-quote-to-order configuration.
Open primary sourceOracle · Product data synchronization
Primary guidance for synchronizing PIM, sales products, parts and BOM data with Oracle CPQ.
Open primary sourceOracle · Configurator application integration
Primary documentation for starting configuration sessions from external applications with structured initialization context.
Open primary sourceOpenAPI Specification
Primary standard for describing HTTP API operations, schemas, authentication and responses.
Open primary sourceJSON Schema Specification
Primary standard for defining and validating structured integration payloads.
Open primary sourceERP integration FAQ
Detailed answers for product, sales, IT and operations teams.
Bring one accepted quote and one ERP order example
Map the exact configured-order contract.
We can identify system authority, price and order triggers, required fields, configured product mappings, security controls, failure paths and working acceptance tests.