Migrate from Decision Builder to Odoo ERP

Decision Builder Customer records map to Odoo res.partner records with partner_type = 'contact'. We preserve customer name, email, phone, address, pricing tiers, and account hierarchies. If Decision Builder stores parent-child customer relationships, we create the commercial partner linkage in Odoo by setting commercial_partner_id. Customer-specific tax IDs migrate to res.partner's vat field. Active versus inactive status flags migrate as active = True/False in Odoo.

Decision Builder Companies where customers are individuals map to res.partner records with partner_type = 'company' in Odoo. The company name becomes the partner display name, and the individual customer records become child contacts under that company partner via child_ids. This supports Odoo's commercial entity model where invoices and contracts attach to the company partner while individual contacts remain linked.

Decision Builder Vendor records map to Odoo res.partner with supplier_rank set to 1 or higher. Payment terms, tax IDs, bank details, and address information require field-level mapping because naming conventions differ. We validate vendor names against Odoo's supplier creation form and flag any vendor with a duplicate partner name for the customer admin to resolve before import.

Decision Builder Item records encompass inventory products, services, and non-inventory items. We map item types to Odoo's product.product variants under a product.template. The item type (stockable, consumable, service) determines Odoo's type field. Pricing migrates to product.template's list_price and standard_price. If Decision Builder stores cost accounting methods, we align them with Odoo's costing methods (standard, average, FIFO).

Decision Builder Items with multi-level BOM structures require special handling. We extract the BOM as a tree, mapping each component item to a product.product reference and each sub-assembly to a nested mrp.bom. We resolve the product.product IDs in Odoo before creating any BOM record so that component lookups are satisfied. Single-level BOMs migrate directly; multi-level BOMs are sequenced so parent BOMs are created after child BOMs.

Open invoices, credit memos, and payment records export from Decision Builder cleanly and map to Odoo account.move records with move_type = 'out_invoice', 'in_invoice', 'out_refund', or 'in_refund' depending on direction and type. We preserve document numbers as name, invoice dates as invoice_date, due dates as invoice_date_due, and aging amounts as amount_total and amount_residual. Post-import reconciliation in Odoo closes the loop on open items.

Invoice history, payment records, and adjustment logs migrate with full audit trails to Odoo account.move records with move_type = 'entry'. Journal entries require mapping to the destination Chart of Accounts, which may use different account numbering schemes. We create a pre-migration account mapping session to align source account codes to Odoo account.account codes before any journal entry data moves. Each line's account_id, debit, and credit fields map from the Decision Builder transaction detail.

Decision Builder's account structure including segment definitions, account types, and rollup hierarchies requires pre-migration mapping to Odoo's account.account. We use Odoo's standard chart of accounts template as a baseline, then add, modify, or merge accounts based on the Decision Builder chart. Segment definitions (if structured as account codes with delimiters) map to Odoo's account.code field with the full hierarchy preserved. We configure account_type (receivable, payable, liquidity, etc.) per Odoo's taxonomy.

Flat Decision Builder Data Structures with no interdependent relationships migrate by mapping their fields to custom fields on the relevant Odoo res.partner, product.product, or account.move. We create the custom field schema in Odoo via Settings > Technical > Custom Fields before data import, then import the Data Structure rows as records in the corresponding model with the custom fields populated.

Decision Builder Data Structures with complex relationships must be exported at the Project level via .dec.obj rather than individually. We convert the .dec.obj to an intermediate format, validate field integrity, and resolve any lookup references to other Data Structures before loading into Odoo. If the destination is a custom Odoo module, we pre-create the model schema with all fields and relationships before data import. Complex structures with cross-references require sequenced import where referenced records exist first.

Decision Builder Projects bundle related Data Structures, workflows, and configurations. We split Projects into Odoo project.project records (the project container) and project.task records (the work breakdown). Task dependencies, assignees, and dates migrate to project.task with the correct parent_id hierarchy for nested sub-tasks. Project-level configurations that do not map to Odoo standard fields are documented as configuration items for manual setup.

Attached documents and files migrate as ir.attachment records linked to their parent record (res.partner, product.product, account.move, project.task, etc.) via res_model and res_id. We verify file integrity after transfer using checksums. Any documents that reference objects not included in the migration scope are flagged separately so the customer admin can assess whether they should be migrated manually or excluded.