PLM integration

Odoo and Siemens Teamcenter Integration

Teamcenter holds the engineering truth. Odoo holds the operational truth. The integration between them decides how fast an engineering change becomes a purchase order.

Written by the Kalk Solutions Odoo team · Last reviewed 30 August 2026

Quick answer

Yes. Siemens Teamcenter exposes service interfaces and structured export mechanisms, and Odoo exposes its External API, so item revisions, released BOMs and engineering change notices can be pushed into Odoo products and bills of materials. There is no official Siemens-supplied or Odoo-supplied connector between the two, so this is a middleware project sized around how heavily your Teamcenter instance has been customised.

Native connector?: No official connector from either vendor. Middleware is the normal approach.
What moves: Item revisions, released BOMs, ECNs, and drawing references into Odoo.
Main variable: How customised your Teamcenter data model already is.

Can Odoo integrate with Teamcenter?

Yes. The integration pattern is well understood: PLM publishes a release event, middleware normalises and maps it, Odoo receives products and bills of materials through its External API, and operational status flows back so engineering can see commercial reality.

What varies enormously is your Teamcenter configuration. Item types, revision rules, BOM view types and release statuses are frequently customised for a specific OEM programme, and that customisation is what the mapping layer has to absorb.

The business case is usually cycle time. Where engineering changes are re-keyed by hand into purchasing and inventory, each change costs days and introduces errors that surface later as wrong parts on a shop floor. Automating the release-to-procurement path is the return.

We have written up a real Teamcenter to Odoo engagement for a precision engineering manufacturer, including what the middleware actually did day to day.

How the integration can work

01
Agree the release gate
Only released revisions cross. Work in progress stays in Teamcenter. Without this rule, purchasing chases parts that engineering has not approved.
02
Map the item model
Teamcenter item revisions map to Odoo product variants or products with a revision field. This decision shapes every downstream report.
03
Normalise the BOM
Engineering BOMs and manufacturing BOMs are not the same structure. Phantom levels, reference designators and make-versus-buy flags need explicit rules.
04
Handle the ECN
An engineering change is not just a new BOM. It carries an effectivity date, obsolete stock, open purchase orders and in-flight work orders that all need a decision.
05
Return the operational signal
Purchase order raised, material received, work order closed. Feeding this back gives engineering visibility into the commercial consequence of a change.

Need an Odoo integration partner?

Kalk is an Odoo partner working only with manufacturers. Tell us what you run.

Discuss your integration with Kalk

What data may be synchronised

Scope is a decision, not a default. Everything below is possible; almost no project should do all of it in phase one.

Data	Direction	Notes
Item revisions	Teamcenter to Odoo	Released revisions only, with the revision identifier preserved.
Released BOMs	Teamcenter to Odoo	Requires an explicit EBOM to MBOM transformation rule.
Engineering change notices	Teamcenter to Odoo	Effectivity date drives which open orders are affected.
Drawing and document references	Teamcenter to Odoo	Usually a link or controlled attachment, not a file copy.
Material and part attributes	Teamcenter to Odoo	Feeds procurement categories and inspection requirements.
Procurement and stock status	Odoo to Teamcenter	Optional return path. Valuable for change-impact assessment.

One-way or two-way?

One-way

Engineering releases, operations consumes. Clean and defensible
No risk of ERP data overwriting a controlled engineering record
Simpler audit position under AS9100 or IATF regimes
Faster to deliver and validate change by change

Two-way

Gives engineering visibility of stock, open POs and change cost
Return path should be read-only status, never edits to controlled data
Adds a second mapping surface and a second failure mode
Only justified when change-impact analysis is a real bottleneck

Our view: Push engineering data one way into Odoo. If a return path is needed, keep it to non-controlled operational status. Never let the ERP write back into a controlled engineering record.

Architecture and data flow

The shape is consistent across every serious integration: a source of truth, a layer that maps and protects, and a target that consumes.

Source

Teamcenter (PLM)

Item revisions
Released EBOM
ECN and effectivity
Drawings and documents

Between

Middleware

EBOM to MBOM rules
Revision mapping
Queue, retry, audit log
Effectivity handling

Target

Odoo

Products and variants
Manufacturing BOMs
Purchase orders
Work orders and stock

Kalk reference architecture for an Odoo and Teamcenter integration.

Key implementation considerations

Teamcenter version and customisation

Scope is driven by how far your data model has diverged from a standard deployment. This has to be surveyed before any estimate is credible.

EBOM to MBOM rules

The transformation from an engineering structure to a manufacturable structure is a business decision, not a technical one. Get it agreed by engineering and production together.

Effectivity and obsolete stock

Every change needs a rule for existing inventory, open purchase orders and released work orders. Automate the flag, keep the decision human.

Traceability and audit

In regulated supply chains, the integration log is part of your evidence. Every synchronised change should be reconstructable.

Idempotency

The same ECN may be published twice. The bridge must recognise it and do nothing the second time.

Limitations and things to verify

No official connector from Siemens or Odoo. Any product claiming one should be verified against both vendors' documentation and support policies.
Odoo's product and BOM model is simpler than Teamcenter's. Some engineering structure will be flattened, and the rules for flattening must be explicit and agreed.
Heavily customised Teamcenter deployments can change scope substantially. Survey before estimating.
Odoo major-version upgrades affect API surface and the mapping layer. Budget for regression testing at each upgrade.

Who this is suitable for

A good fit

Precision engineering and machining suppliers to automotive Tier 1 programmes
Aerospace component manufacturers under AS9100 with frequent engineering changes
Medical device subcontract manufacturers with controlled document requirements
Any manufacturer where PLM is mandated by the OEM and operations still run on spreadsheets

Probably not worth it

Manufacturers with a handful of stable BOMs and rare engineering changes. The manual path is cheaper.
Businesses that have not yet stabilised their Odoo manufacturing configuration. Integrate second, not first.

Primary sources

Vendor capabilities change by version and licence. Verify against current documentation before making a commercial decision.

Frequently asked

Odoo and Teamcenter: common questions

Can Teamcenter integrate with Odoo?

Yes. Teamcenter service interfaces or structured exports feed a middleware layer that writes products and bills of materials into Odoo through its External API. Neither vendor ships an official connector, so the integration is purpose-built.

Does the same approach work for Windchill or 3DEXPERIENCE?

The pattern is the same: PLM holds design truth, Odoo holds operational truth, middleware synchronises releases. The specific interfaces and the effort differ by platform and by how each deployment has been configured.

What actually changes day to day after the integration?

A released BOM revision in the PLM system appears in Odoo without re-keying, procurement can act on the current specification, and obsolete stock against a superseded revision can be flagged rather than discovered later.

Should engineering data ever be edited in Odoo?

No. Controlled engineering data should be edited only in the PLM system. Odoo consumes releases. Any return path should carry operational status only.