Use these data-model references to describe the records your connection needs. They are planning examples; connector availability and supported operations must be established before implementation.
Download the mapping worksheet · CSV, no email required
Record matching
Contacts / Contacts (res.partner)
Compare whether Microsoft Dynamics 365 Contacts and Odoo Contacts (res.partner) describe the same contact in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- Microsoft Dynamics 365
- Object support to establish
- Odoo
- Object support to establish
- Record identity
- Use a stable person/contact ID and an explicit cross-system lookup. Email can change and can be shared, so treat it as a matching clue rather than a universal key.
- Field ownership
- Keep consent and communication preferences under an agreed authority; a general contact update must not silently resubscribe someone.
Fields to include
- Source person ID
- Display name
- Email address
- Organization reference
- Consent state
- Record dependencies
- Resolve the organization relationship and any owner or consent references required by the destination.
- Validation
- Test an email change, two records sharing an email, and a person associated with multiple organizations.
- Recovery
- Hold ambiguous matches for review and reconcile the person ID before retrying; preserve the consent decision already recorded by its owner.
References: Microsoft Dynamics 365: Contacts documentation
Record matching
Quotes, Orders & Invoices / Invoices (account.move)
Compare whether Microsoft Dynamics 365 Quotes, Orders & Invoices and Odoo Invoices (account.move) describe the same customer invoice in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- Microsoft Dynamics 365
- Object support to establish
- Odoo
- Object support to establish
- Record identity
- Retain the invoice ID, issuer/legal entity, and original order reference; invoice numbers alone may overlap.
- Field ownership
- The financial system owns posting and accounting treatment. A posted invoice may need a credit or adjustment process instead of an overwrite.
Fields to include
- Source invoice ID
- Customer or supplier reference
- Line totals
- Currency
- Posting/payment status
- Record dependencies
- Resolve the customer or supplier, account codes, tax, currency, and accounting period before posting.
- Validation
- Test a posted invoice, a partial payment, tax rounding, and a closed accounting period. Compare financial totals within the same entity and currency.
- Recovery
- Determine whether a transaction posted before retrying. Follow the approved adjustment process for posted records.
References: Microsoft Dynamics 365: Quotes, Orders & Invoices documentation
Business process
Opportunities / Sales Orders (sale.order)
Approved sales handoff: Microsoft Dynamics 365 Opportunities provides context for Odoo Sales Orders (sale.order). These are related records, not equivalent entities.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- Microsoft Dynamics 365
- Object support to establish
- Odoo
- Object support to establish
- Record identity
- Link the originating deal ID to a newly assigned order ID; do not reuse the deal ID as an order number.
- Field ownership
- Define the approval event and the customer/product data required to create an order. A sales stage alone must not authorize every order.
Fields to include
- Source record reference
- Destination record reference
- Approved handoff state
- Duplicate-detection key
- Record dependencies
- Map the customer and sales pipeline before the opportunity; map stage values deliberately.
- Validation
- Repeat the approved handoff and verify that it locates the existing order; test a reopened deal without silently cancelling fulfillment.
- Recovery
- Suspend downstream creation for a rejected deal and review whether an order already exists before retrying.
References: Microsoft Dynamics 365: Opportunities documentation
Business process
Quotes, Orders & Invoices / Sales Orders (sale.order)
Order-to-invoice handoff: Odoo Sales Orders (sale.order) provides context for Microsoft Dynamics 365 Quotes, Orders & Invoices. These are related records, not equivalent entities.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- Microsoft Dynamics 365
- Object support to establish
- Odoo
- Object support to establish
- Record identity
- Link order and line IDs to invoice and line IDs; allow partial invoicing and multiple invoices per order.
- Field ownership
- Finance owns invoice posting; the order system supplies the approved commercial context.
Fields to include
- Source record reference
- Destination record reference
- Approved handoff state
- Duplicate-detection key
- Record dependencies
- Create or locate the customer and products first; resolve taxes, currency, and fulfillment references.
- Validation
- Test a partially invoiced order, tax rounding, and a repeated handoff without generating another invoice.
- Recovery
- Check for an existing destination order before retrying a timed-out create; reconcile line IDs to avoid duplicate fulfillment.
References: Microsoft Dynamics 365: Quotes, Orders & Invoices documentation
Record matching
Products / Products (product.template / product.product)
Compare whether Microsoft Dynamics 365 Products and Odoo Products (product.template / product.product) describe the same product or catalog item in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- Microsoft Dynamics 365
- Object support to establish
- Odoo
- Object support to establish
- Record identity
- Distinguish the product ID, variant ID, SKU, and price-list entry; they are not interchangeable keys.
- Field ownership
- Assign ownership for catalog content, price, and stock separately.
Fields to include
- Source product ID
- SKU or variant reference
- Description
- Unit of measure
- Price-list reference
- Record dependencies
- Resolve units, variants, categories, and applicable price lists before order lines.
- Validation
- Test two variants of one product, a changed SKU, and a price that applies to only one market or currency.
- Recovery
- Repair the variant or price-list reference before retrying affected order lines; preserve existing transaction prices.
References: Microsoft Dynamics 365: Products documentation