Migrate from De Facto ERP to Odoo ERP

De Facto Customer records map directly to Odoo res.partner with partner_type=contact or company. We extract customer name, addresses, phone, email, payment terms, and account balance via TSQL. De Facto's custom field extensions on the customer record (often used for industry-specific attributes) require field-by-field mapping to Odoo res.partner custom fields or to dedicated Odoo configuration tables. Parent-company hierarchies map to res.partner's child contact structure.

De Facto Vendor master records map to Odoo res.partner with partner_type=supplier. Currency assignments and tax identification numbers migrate as-is. Multi-country supplier details from De Facto's supply chain module map to Odoo's fiscal country mapping on the partner record. Vendor bank details migrate to res.partner.bank for SEPA and international payment processing.

De Facto stock items map to Odoo product.product with product_type=product or service. Each item's unit of measure, barcode, weight, volume, and route assignments (buy, manufacture, make-to-order) migrate via TSQL extraction. De Facto item cost layers (standard, average, FIFO) map to Odoo's product costing method fields. Where De Facto uses item-level landed cost components (freight, insurance, duty), we map these into Odoo's landed cost mechanism on the product form and apply them during stock valuation.

De Facto BOMs (bill of materials) with component lines, quantities, and operations map to Odoo mrp.bom. Multi-level BOM nesting is preserved as Odoo BOM lines referencing sub-assembly product.cycle_time and workcenter assignments map to mrp.workcenter. De Facto's warranty stock management for importers maps to Odoo product tracebility settings on the finished goods.

De Facto's landed cost tracking for importers (freight, insurance, duty, tax per imported shipment) requires explicit mapping to Odoo's stock.landed.cost model. Each landed cost line type from De Facto maps to an Odoo landed cost type (supplier, customs, transportation, other). We preserve the per-shipment allocation logic by creating Odoo landed cost records linked to the relevant stock moves and then triggering Odoo's landed cost valuation layer to update product costs post-import.

De Facto open invoices, credit notes, and outstanding balances migrate to Odoo account.move records with move_type=out_invoice (AR) or in_invoice (AP). Payment status, due dates, and residual amounts are preserved in Odoo's payment_state and amount_residual fields. We validate that Odoo's account.payment term lines match De Facto's payment terms before migration to avoid reconciliation gaps. Locked and reconciled items are migrated as reconciled with a journal entry date matching the original.

De Facto's chart of accounts generated via TSQL scripts (CSV or XML output) maps directly to Odoo account.account with code, name, account_type, and reconcile flags preserved. De Facto multi-country account structures (common for importers using the landed cost module) map to Odoo's account group hierarchy for consolidated reporting. De Facto tax code assignments map to Odoo account.tax records with the correct tax_scope and country.

De Facto purchase orders, sales orders, and warehouse movements exported via TSQL map to Odoo purchase.order, sale.order, and stock.move respectively. Large transaction volumes require chunked extraction; we chunk TSQL output into 10,000-row batches and load sequentially via Odoo's XML-RPC or csv import framework with batch-level row counts reconciled. Transaction dates and warehouse assignments are preserved for inventory valuation continuity.

De Facto fixed asset registers (acquisition cost, depreciation schedule, asset location, category) map to Odoo account.asset and account.asset.profile. Depreciation board entries migrate as Odoo depreciation lines with posted journal entries. De Facto's landed cost tracking overlap with fixed assets (where imported equipment carries duty and freight into asset cost) is resolved by mapping those landed cost lines to Odoo's capitalisation journal entries on the asset.

De Facto user records and role assignments map to Odoo res.users and res.groups. De Facto's custom permission sets (often bespoke to each company's EDP configuration) cannot map 1:1 to Odoo's access rights framework; we extract all users with their role memberships during discovery and create a written permission mapping table for the customer's Odoo admin to configure post-migration. Inactive De Facto users migrate as inactive Odoo users for audit continuity.

De Facto documents stored by default and linked to data records via OCR/barcode processing migrate as ir.attachment records in Odoo linked via res_model and res_id to the corresponding parent record (res.partner, product.product, stock.move, account.move). Document-to-record linkages from De Facto export cleanly if the linkage is stored as a foreign key in the document table; linkages maintained only in OCR metadata do not migrate and are flagged in the scoping report.

De Facto custom fields and user-defined TSQL-generated output formats require field-by-field enumeration during discovery. We extract the complete custom field list from De Facto's metadata tables via TSQL, then pre-create Odoo custom fields (ir.model.field with custom=True) before master data import. Custom field types (string, integer, decimal, date, lookup, multi-select) are mapped to the equivalent Odoo field type. Any De Facto custom entities without an Odoo standard model become Odoo ir.model and ir.model.field definitions in a dedicated custom module.