License Requirement: ATR CustomTools Professional + Odoo ERP Integration (V2) module

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.

TIP: The recommended starting point is the tutorial video below. Use this page as a high-level whitepaper and technical reference.

Video: Tutorial: Integrate SOLIDWORKS (and/or PDM) with Odoo ERP

Table of Contents

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.

Demo Integration Auto-configures a demo environment so you can try the integration with your existing Odoo instance.
Low-code Configuration Adaptable to both standard and highly customized Odoo environments without custom development.
Multiple Export Profiles Define different profiles for different use cases (manufacturing BOM, spare parts, sales BOM, etc.).
Company & Language Context Supports Odoo company selection and language selection for translatable fields.
Default Values Specify default field values when source data is missing or empty.
Script Extensions Extend and tailor behavior with debuggable scripts for advanced customization.
Authentication & Connectivity

Secure connectivity to Odoo with several authentication options.

Authentication Support Supports Odoo login, API keys and external OAuth2 providers (configured in Odoo).
Search Groups Use Odoo-powered searches to link existing Products/Variants to design components or weldment profiles.
Lookup Lists Populate SOLIDWORKS custom properties from Odoo-sourced lookup lists.
Product & BOM Data Management

Create and maintain Products, Variants and BOMs in Odoo directly from your CAD structures.

Advanced Product Export Export full design structures as Products and BOMs or update existing items.
BOM Comparison Compare Odoo BOMs with the current export and highlight differences with color coding.
Product Linking Search and link existing Products/Variants to designs or BOMs instead of always creating new items.
Design Grouping Group multiple designs as the same Product/Variant based on chosen Custom Property values.
Engineering BOM Translation Translate engineering BOMs into ERP-ready BOMs with grouping and rules (Exclude, Dissolve, Promote).
Multi-configuration Support Export multiple root configurations in a single operation.
Virtual Items Add non-modeled items (e.g. consumables) into BOM structures.
Batch Import Import Odoo field values back into SOLIDWORKS models in bulk.
Mapping & Data Rules

Control how data flows between SOLIDWORKS and Odoo on a field-by-field level.

Flexible Property Mapping Map SOLIDWORKS custom properties to Odoo fields (Char, Text, HTML, Selection, Float, Integer, Boolean, Many2One, Many2Many, One2Many).
Data Master Control Define which system is the master per field (SOLIDWORKS or Odoo) during synchronization.
File Conversion & Publishing

Publish neutral formats and previews to Odoo with automated file conversion.

Preview Support Export component previews for Products/Variants.
Upload Neutral Formats Convert and upload drawings/components as PDF, DXF, STEP and other supported formats.
Conversion Control Auto-detect required conversions or force specific formats when needed.
Full SOLIDWORKS PDM Support

Use the integration seamlessly in SOLIDWORKS PDM vault workflows.

PDM Task Support Trigger exports manually or automatically from PDM workflow transitions.
TIP: For a quick functional test, start with a demo export profile against a non-production Odoo database.

Performance

TIP: Values provided are for reference. Overall performance is always a sum of multiple factors.

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

  • Read CAD structure & properties (fully resolved): 15sec
  • Format the BOM (database intensive): 1min 45sec
  • Communicate with Odoo: 15sec
  • Fill Export View: 30sec
Export to Odoo Total: 7min 30sec

  • 2 688 new Products with previews (+ 2688 Variants)
  • 128 new BOMs
Export re-opened
(all Products and BOMs exists in Odoo)
Total: 3min 0sec

  • Read CAD structure & properties (fully resolved): 15sec
  • Format the BOM (database intensive): 1min 45sec
  • Communicate with Odoo: 30sec
  • Fill Export View: 30sec

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.


Since the current Odoo ERP Integration (V2) uses the JSON-RPC API, ATR CustomTools 2026 SP0 (and older) will not support Odoo ERP version 20.

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.

NOTE: All integration traffic is performed through Odoo's supported external API. Direct database access is not required.
  • 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 from res.company.
  • lang – resolved from res.lang to support translations.

By default, all queries exclude archived records. Customizations and future features can override this behavior when needed.

TIP: Odoo ERP Integration (V2) batches API calls whenever possible to reduce round trips and improve overall performance.

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.template was found:
  • Try to match product.product using 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.bom records.
  • Primary match is on product_tmpl_id against the template’s id.
  • If variant-specific BOMs are enabled, product_id must 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’s id).
  • 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.attachment based on res_model and res_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.template is created using Export mapping.
  • Fields are populated from the Export view according to mapping rules.
  • Odoo is expected to automatically create one product.product variant.
  • The variant is obtained via product_variant_ids using search_read immediately after template creation.
NOTE: In ATR CustomTools , Export Items cannot have a variant without a template, nor a template without a variant. Future versions may loosen this requirement.
  • Create a new mrp.bom for the product template (and variant when applicable).
  • Set product_tmpl_id and optionally product_id for 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.

TIP: For large assemblies, consider using separate export profiles (e.g. by product family or project) to keep individual export operations manageable and easier to review.
  • 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.
NOTE: Odoo ERP Integration (V2) favors consistency and data integrity. When in doubt, it prefers explicit user review (for example via ghost items) rather than silently discarding mismatches.