Migrate from Datacor ERP to Odoo ERP

Datacor Items carry formula data, multi-level BOM versions, unit-of-measure conversions, shelf-life metadata, and CAS number fields that require decomposition before Odoo import. We extract Items with all associated BOM levels and split them into Odoo Product Templates (the sellable item) with optionally generated Variants (for size, color, or packaging variants). Datacor's formula versions map to Odoo MRP BOM versions via the mrp.bom.line and mrp.bom resource model. Shelf-life and lot expiration metadata maps to lots_stock_move fields in the Inventory app. Tier and edition constraints: Odoo Enterprise BOM versioning requires the Manufacturing or PLM app; Community uses a single BOM version unless custom module installed.

Datacor's nested BOMs (formulations with co-products, by-products, and multi-level sub-assemblies) map to Odoo's MRP BOM structure where each level becomes a separate mrp.bom record with type=normal or type=phantom. We decompose Datacor's BOM levels into a flat BOM hierarchy, preserving the quantity-per-parent ratio and operation sequences (work centers and cycle times) as mrp.workcenter resources. Co-products and by-products from Datacor map to By-Product lines in the Odoo BOM. Formula version control maps to Odoo's active/draft BOM versioning pattern.

Datacor's cradle-to-grave lot tracking is a core strength of the platform. We preserve full lot genealogy including parent lots, co-products, by-products, and downstream consumption records. Each Datacor lot becomes an Odoo stock.production.lot record with name, product_id, create_date, and lifespan_date preserved. Lot genealogy links migrate as mrp_production records linked via the lot number so that the customer's quality team can trace downstream consumption in Odoo's Manufacturing and Inventory apps. Note: Odoo's base Inventory app supports lot traceability; full genealogy traversal across multi-level production orders requires the Manufacturing app configured with tracked BOMs.

Datacor Customer records include customer-specific pricing tiers, credit limits, discount schedules, and multi-address shipping configurations. We map these to Odoo res.partner records with customer=True and attach pricing tiers as Odoo price lists (product.pricelist with item rules scoped per partner or partner category). Multi-address configurations migrate as separate res.partner contact records linked to the parent customer record. Credit limits and discount schedules migrate as custom fields on the partner or as entries in the Odoo Account module's payment terms table.

Datacor Vendors carry CUPS (Complex Unit Price Schedules), rebate logic, multi-source purchasing flags, and lead-time data. We map vendors to Odoo res.partner records with supplier=True and preserve CUPS as product.supplierinfo records linked to the vendor's partner record, with min_qty, price, and currency mapped per line. Multi-source purchasing flags and rebate schedules migrate as custom fields or notes on the supplierinfo or as a vendor-specific price list rule. Datacor's vendor quality ratings migrate as custom fields on the supplier partner record.

Datacor Sales Order headers and lines carry customer-product pricing, freight terms, shipping method logic tied to the truck routing module, and order-status flags. We map open sales orders to Odoo sale.order and sale.order.line records. Lines are resolved to Odoo product variants (via the Product Template mapping). Customer-specific pricing is resolved from the price list attached to the customer partner record. Partially-shipped orders are held open or closed manually post-migration depending on whether the remaining lines can be repriced in Odoo. Freight terms and shipping method logic is preserved as order notes or custom fields pending Odoo delivery configuration.

Datacor Purchase Orders with line items and delivery schedules map to Odoo purchase.order and purchase.order.line records. We flag partially-received POs (those with receipt quantities less than ordered quantities) and hold them open or close them manually post-migration depending on whether the remaining receipt lines can be processed in Odoo against the vendor's supplierinfo pricing. Datacor's multi-source purchasing flags (preferred vendor vs. alternate vendor) are preserved as vendor rank or sequence values in Odoo's product.supplierinfo.

Datacor batch production orders include formula versions, scheduled start and end times, consumption records, and yield data. We extract completed and closed production orders as historical mrp_production records with mrp_workorder records for each operation. In-process batches with partial consumption or incomplete yields are flagged during pre-migration discovery — these cannot be safely migrated without creating orphaned lot records. We advise completing or formally closing open production orders before migration day. The formula version reference maps to the mrp_bom resource ID resolved at migration time.

QC inspection records in Datacor link to lots and items with disposition decisions and certificate-of-analysis data. We extract the inspection history, disposition (release, reject, quarantine), and CoA records and map them to Odoo Quality module quality.alert records (for issues) or quality.check records (for inspection points). Disposition decisions and test results migrate as text fields or custom fields on the alert/check record. Note: Odoo's base Quality app requires Enterprise; Community users need a third-party QC module or custom field configuration for lot-level inspection tracking.

Datacor's GL structure with accounts, departments, cost centers, and journal entry history migrates directly to Odoo account.account and account.move records. We map the account code hierarchy, account type (asset, liability, equity, revenue, expense), and opening balances. Journal entries with posting dates and amounts preserve the original date and period. Cost centers and departments from Datacor map to Odoo's analytic account structure (account.analytic.account) if the Analytic Accounting app is installed. This is a high-risk mapping: Odoo will not auto-fill computed fields like balance during raw import; we run ORM recompute after schema load to populate computed amounts.

Open AR and AP invoices from Datacor migrate as Odoo account.move records of type out_invoice and in_invoice respectively, with payment terms, discount schedules, and outstanding credit amounts preserved. We flag records with outstanding credits or payment holds as exceptions in a reconciliation queue. Partial payments already processed in Datacor migrate as fully paid invoices with payment matching records (account.payment) linked via the reconcile field. Line items on AP/AR records are resolved to Odoo product variants and account codes mapped via the GL account mapping.

Datacor's equipment records with maintenance schedules, work orders, and asset specifications split across Odoo's maintenance.equipment (preventive maintenance schedules and work orders) and account.asset (financial asset depreciation tracking) models depending on whether the customer's use case is operational maintenance or financial asset accounting. Work order histories and repair records from Datacor migrate as maintenance request records on the equipment. Odoo requires the Maintenance app for equipment scheduling and the Asset app for depreciation tracking; both are Odoo Enterprise apps.