Migrate from Deacom ERP to Odoo ERP

Deacom dmprod with pr_id as integer primary key maps to Odoo product.template as the master record, with product.product variants generated for any size/color/flavor dimension definitions present in Deacom. We export all item records including UOM definitions, catch-weight settings, and facility restrictions in a single pass. Odoo's product type (stockable, consumable, service) maps from Deacom item type flags. Product code from Deacom becomes the default_code field; Deacom's facility restriction flags require Odoo warehouse rules configuration post-import.

Deacom BOMs stored per Item per Revision with active/default/lab-only/regulatory-only flags map to Odoo mrp.bom with the bom_line records for each component. We export BOMs sorted by revision date to preserve formulation state, flag any Item with multiple active revisions for customer decision on consolidation versus full history preservation. Lab-only and regulatory-only BOMs require custom boolean fields on mrp.bom in Odoo since this distinction is not native. The Odoo BOM type (normal or kit) maps from Deacom BOM structure type.

Deacom dmcust with cu_id primary key maps to Odoo res.partner with customer_rank set to distinguish from vendor records. Customer hierarchies, credit terms, and customer-part associations (dmcust cross-links) map to res.partner fields and ir.model.relation constraints in Odoo. Customer-specific pricing sheets stored in Deacom require Odoo price list configuration per partner or partner category post-import.

Deacom vendor master records using consistent dm-type naming map to Odoo res.partner with vendor_rank set. We export vendor purchasing lead times, preferred UOMs, and vendor-specific part cross-references. Odoo vendor lead times map to seller_delay on product.supplierinfo records linked to the vendor partner. EDI trading partner setups from Deacom map to Odoo EDI configuration records where applicable.

Deacom production orders as dt-type transaction records referencing Item pr_id and BOM revision map to Odoo mrp.production. We export job costing, routing steps, and labor tracking entries with Work Order (mrp.workorder) records created per routing step. Open production orders require handling for in-process status; Odoo Manufacturing requires explicit state transitions (draft → confirmed → in_production → done) that must match the Deacom order status at migration time. Closed production orders migrate as done-state records for historical traceability.

QC tests set up per Item/Revision in Deacom with threshold values, test types, and pass/fail criteria map to Odoo quality.alerts and quality.checks. The test schema varies by facility, so we map each facility's QC configuration independently. Deacom's dmd3 pick-list UDF options for test types require the UDF remapping table to recreate as Odoo quality.point with test_type as a selection field. Odoo requires the Quality app to be installed; if absent, we flag this as a separate module activation step.

Deacom lot numbers and shelf-life dates at the inventory transaction level map to Odoo stock.production.lot linked to stock.quant for on-hand quantities. Parent-child lot relationships for co-manufactured or bulk-split scenarios map to Odoo lot genealogy via stock.move.line records. Serial number traceability maps similarly to stock.production.lot with unique serial number constraints. Odoo's lots require explicit linking to product_id and company_id; we resolve these references at migration time from the parent Item records.

All Deacom inventory movements — receipts, issues, adjustments, and transfers — live in dt-type tables linked to Items and lots, sequenced in timestamp order. These map to Odoo stock.move records with source/destination location references resolved from Odoo's warehouse location hierarchy. We exclude any records that reference lots not yet migrated. Deacom's multi-facility model maps to Odoo multi-warehouse with stock.location hierarchy (Internal Locations per facility).

Deacom real-time GL postings with drill-down to dt transaction level map to Odoo account.move records. We export account codes, journal line items, and source document references (AR/AP/inventory). Custom financial statements per company structure in Deacom require Odoo chart of accounts design and financial reporting configuration post-import. Multi-currency GL entries require exchange rate mapping at the account.move line level using Odoo's foreign currency fields.

Accounts payable and receivable from Deacom integrate directly with the GL. We export open invoices, payment applications, credit memos, and aging details as account.move records with move_type of entry for vendor bills (in_invoice) and customer invoices (out_invoice). Multi-currency AR requires exchange rate records mapped from Deacom's currency tables. Payment terms from Deacom's customer credit terms map to Odoo account.payment.term records.

Deacom user-defined fields in dmd3 reference pick-list options via d3_c2guid links to dxcaption2's system-generated uniqueidentifier. These _guid values are non-transferable — importing them into Odoo creates orphaned references with no validation error. We export the human-readable labels alongside the guids, create a remapping table, and apply Odoo selection field options with sequential integer values or ir.model.fields with selection_ids for dynamic picklists. The customer reviews the remapped pick-list options before import to confirm business-appropriate labeling.

Deacom's iOS and Android mobile apps for sales and warehouse use cached local data that is not persisted to exportable database tables independently. Mobile-specific notes, offline entries, and mobile-only GPS data cannot be migrated. We flag this gap in the data inventory and recommend that sales and warehouse teams document any records created on mobile devices during the migration window for manual entry post-go-live.