ATR CustomTools - Odoo ERP Integration
Odoo ERP Integration (V2)
Odoo ERP Integration (V2) connects your SOLIDWORKS designs directly to Odoo, turning engineering data into ERP-ready products, variants and bills of materials (BOMs). It automates product creation and updates, BOM maintenance and document publishing – while keeping you in control of what is synchronized and when.
Video: Tutorial: Integrate SOLIDWORKS (and/or PDM) with Odoo ERP
Table of Contents
- Key Capabilities
- Performance
- Architecture & Communication
- Odoo Data Model Used by the Integration
- Export Workflow
- Execution Model and Performance
Key Capabilities
The table below summarizes the main functional areas of Odoo ERP Integration (V2) .
| Setup & Configuration |
Tools that simplify onboarding, configuration and administration of the integration.
|
|||||||||||||||||
| Authentication & Connectivity |
Secure connectivity to Odoo with several authentication options.
|
|||||||||||||||||
| Product & BOM Data Management |
Create and maintain Products, Variants and BOMs in Odoo directly from your CAD structures.
|
|||||||||||||||||
| Mapping & Data Rules |
Control how data flows between SOLIDWORKS and Odoo on a field-by-field level.
|
|||||||||||||||||
| File Conversion & Publishing |
Publish neutral formats and previews to Odoo with automated file conversion.
|
|||||||||||||||||
| Full SOLIDWORKS PDM Support |
Use the integration seamlessly in SOLIDWORKS PDM vault workflows.
|
|||||||||||||||||
Performance
The 5000+ Component Test-Assembly
| Files | 2 688 |
| Components | 5 247 |
| Unique Assemblies | 128 |
| Unique Parts | 2 560 |
| State | Fully Resolved |
Export Performance with Test-Assembly
Using the Demo Integration configuration of ATR CustomTools 2026 SP0 , under SOLIDWORKS 2026 SP0.
| Export Opened (No Products or BOMs exist in Odoo) |
Total: 2min 45sec
|
| Export to Odoo |
Total: 7min 30sec
|
| Export re-opened (all Products and BOMs exists in Odoo) |
Total: 3min 0sec
|
Architecture & Communication
Odoo ERP Integration (V2) communicates with Odoo using the external JSON-RPC API.
- API: Odoo External API via JSON-RPC.
- Services:
- common – authentication and version checks.
- object – data operations via
execute_kw.
Odoo ERP has deprecated the JSON-RPC External API since version 19 (released in fall 2025). It's also scheduled for removal in version 20, that we could expect to be released in fall 2026.
We are working on reimplementing the API layer of Odoo ERP Integration (V2) , and we aim to introduce it to ATR CustomTools 2026 SP1 . Our preliminary study indicates, we should be able to do a fully backwards compatible upgrade without any compromises in e.g. performance.
- Standard Odoo user login.
- API keys (recommended, must be used together with MFA in Odoo).
- External OAuth2 providers configured in Odoo (per-user API keys still required).
Authentication is handled via common.authenticate, and Odoo version is confirmed using
common.version to ensure compatibility.
All data operations use the execute_kw method of the object service. Each Odoo
object is expected to have a unique integer id, and many objects also provide a
display_name for user-friendly identification.
Common methods used:
fields_get– metadata and field definitions.search_read– combined search and read for efficient queries.create– create new objects.write– update existing objects.unlink– remove objects when allowed by configuration.
Context handling:
company_id– resolved fromres.company.lang– resolved fromres.langto support translations.
By default, all queries exclude archived records. Customizations and future features can override this behavior when needed.
Odoo Data Model Used by the Integration
Odoo ERP Integration (V2) focuses on a core set of Odoo models. The table below summarizes how they are used.
| Entity | Description | Key Relations |
|---|---|---|
| res.company | Defines the active company context. | Used in context.company_id for all object queries. |
| res.lang | Defines the active UI and data translation language. | Used in context.lang for translatable fields. |
| product.template | Master product record with generic product information. | Has one or many product.product variants. |
| product.product | Specific product variant. | Linked to product.template via product_variant_ids. |
| mrp.bom | Bill of materials for manufacturing a product. |
References product.template and optionally product.product for
variant-specific BOMs.
|
| mrp.bom.line | Individual line in a BOM with component and quantity. | Linked to mrp.bom and to a component product.product. |
| ir.attachment | Binary file storage (drawings, documents, previews). | Linked to products or BOMs via res_model and res_id. |
Planned future integrations:
-
ir.model.data – robust mapping of selectable values by immutable
external_id. - mrp.eco – support for engineering change order (ECO) processes.
- product.attribute, product.attribute.value – richer support for variant creation workflows.
Export Workflow
The integration starts from the SOLIDWORKS model structure (engineering BOM). Using ATR CustomTools Export settings and BOM rules, this structure is translated into Export Items that represent the future Odoo products and BOM lines.
- Represent each CAD component or virtual (non-modeled) item.
- Can have child Export Items, forming a tree structure.
- Multiple CAD components may map to the same Export Item; consistency checks help avoid conflicts.
- Export Items can appear multiple times in the view; changes to one instance affect all.
Before creating new records, Odoo ERP Integration (V2) attempts to match existing products and variants in Odoo.
- Configured Export Fields (e.g.
default_code) act as identifiers. - Multiple fields can be used as identifiers for more robust matching.
- Due to batching, the first identifier is used in the API query; additional identifiers are applied by filtering the result set locally.
- The search must resolve to exactly one template or none.
Odoo always maintains at least one variant per product. BOMs reference variants
(mrp.bom.product_id), not templates, so both levels must be considered.
- Variants are obtained via
product.template.product_variant_ids. - When variants are enabled, additional identifier fields can be used to pick the correct variant.
- The integration expects to resolve exactly one variant, regardless of whether variants are visible in Odoo UI.
- Future versions may suggest creating a new variant when no match is found.
Mixed setups with single-variant and multi-variant products can be tricky. If the template cannot be matched, the integration can fall back to matching directly on variants.
- If no
product.templatewas found:
- Try to match
product.productusing the configured identifiers. - Use the same batching and filtering principles as template matching.
- If found, derive the related template via
product_tmpl_id.
-
For each matched product template, the integration searches corresponding
mrp.bomrecords. - Primary match is on
product_tmpl_idagainst the template’sid. -
If variant-specific BOMs are enabled,
product_idmust also match the chosen product variant. - Optional filtering by identifiers (e.g. BOM Reference names like Manufacturing BOM, Spare parts, etc.).
- Each export profile is expected to resolve exactly one BOM, but different profiles may target different BOMs.
- BOM lines are queried by
bom_id(the BOM’sid). - Lines are matched to child Export Items via:
product_id= child’s product variant.product_tmpl_id= child’s product template.
BOM lines that do not match the current Export structure can be:
- Ignored,
- Shown as “ghost items” in the Export view for user review, or
- Removed automatically, depending on configuration.
Ghost items are displayed in the Export view using product and BOM line mappings, including
mrp.bom.line.product_qty for the quantity.
The integration can link and update documents and previews stored in Odoo as attachments.
-
Attachments are queried from
ir.attachmentbased onres_modelandres_id.
Attachment targets:
- Product templates (
product.template). - Product variants (
product.product). - BOMs (
mrp.bom).
Data used:
- Filename (
name). - MIME type (
mimetype). - Binary data (
datas).
Depending on settings, existing attachments with the same filename can be updated in place, or new attachments can be created even when filenames are duplicated.
When an Export Item cannot be matched to existing objects, the integration creates the required products, variants and BOMs.
- A new
product.templateis created using Export mapping. - Fields are populated from the Export view according to mapping rules.
- Odoo is expected to automatically create one
product.productvariant. -
The variant is obtained via
product_variant_idsusingsearch_readimmediately after template creation.
- Create a new
mrp.bomfor the product template (and variant when applicable). -
Set
product_tmpl_idand optionallyproduct_idfor variant-specific BOMs. - Populate other mapped fields from the Export view.
- For each child Export Item, create a corresponding
mrp.bom.line:
bom_id= parent BOM.product_id= child’s product variant.- Other fields, including
product_qty, follow the Export mapping.
Once all items (products, variants, BOMs and BOM lines) are matched or created, the integration updates Odoo objects based on the Export field values.
Only fields where SOLIDWORKS is defined as the data master are written back to Odoo. Fields mastered by Odoo are instead read and populated into the Export view or the CAD model, as configured.
If an Export field is configured to be imported into CAD, the integration ensures file access so that the updated values are available for SOLIDWORKS.
Execution Model and Performance
Updates are executed in a dependency-aware order: referenced objects (such as products) are created or updated before dependent objects (such as BOMs and attachments). The integration may issue several batched calls per table to handle complex exports.
Create and delete operations can usually be batched efficiently. Updates (write) are more limited by the Odoo API: batching is only supported when the same values are written to multiple records at once.
- All operations can be extended or overridden with centrally deployed customizations.
- The integration is designed for large datasets and high-volume exports.
- Comprehensive logging is available for troubleshooting and auditing API traffic.