Migrate from Encompass Production Cloud to Odoo ERP

Encompass Production Cloud Batch records (batch_id, batch_number, production_date, status, quantity_produced, quantity_unit, linked BOM, production_schedule) map to Odoo mrp.production. We resolve the mrp_bom_id by matching the Encompass BOM identifier to Odoo's mrp.bom records pre-loaded during the BOM migration phase. Production order state (draft/production/done/cancel) maps to Odoo's state field using the Encompass batch_status enum. Batch Backtrace genealogy is preserved as Odoo stock.move.line traceability records with lot_link references to the finished-goods lot.

Encompass BOMs (bom_id, recipe_name, version, ingredient lines with quantity, unit_of_measure, cost_allocation, step_sequence) map to Odoo mrp.bom as the recipe header and mrp.bom.line records as ingredient rows. BOM versioning requires a customer decision during scoping: we extract all active and historical BOM versions and present them for selection (active-only vs. all versions for audit traceability). Each selected BOM version is inserted as a separate mrp.bom with the Encompass version field stored in Odoo's active boolean or a custom revision_date field. Ingredient cost_allocation from Encompass maps to Odoo's product_qty and unit_cost where product_id cost is set via Odoo's standard cost on the product form.

Encompass Production Schedules (planned_quantity, start_date, end_date, assigned_workstation, assigned_staff, resource_type) map partially to Odoo mrp.workorder and mrp.workcenter. Odoo's workorder model supports workcenter assignment, planned/actual start and end times, and duration tracking. The mapping is partial because Encompass scheduling granularity and resource-linkage modelling may differ from Odoo's default workorder structure; we flag gaps during data audit and present configuration options to the customer (Odoo Workcenter groups, workorder dependencies via mrp.routing.workcenter). Resource capacity modelling is scoped as a configuration task rather than a direct data migration.

Encompass Inventory Lot records (lot_number, product_id, quantity_on_hand, location_id, cost_per_unit, TTB_attributes, received_date, expiration_date) map to Odoo stock.lot (lot_number, product_id, product_qty from linked stock.quant) and stock.quant (lot_id, product_id, location_id, quantity, inventory_date, value). Lot genealogy chains from Encompass Batch Backtrace migrate to Odoo stock.move.line traceability links. TTB-relevant attributes (TTB status, compliance batch notes) migrate to Odoo's lot.name or a custom stock.lot field depending on whether the customer licenses the Odoo Quality module. We validate that ingredient lots and finished-goods lots form closed backtrace circles before confirming completeness.

Encompass Production Variance records (batch_id, planned_material_cost, actual_material_cost, planned_labour_minutes, actual_labour_minutes, yield_variance, cost_variance) map to Odoo workorder cost-tracking fields and a custom mrp.workorder variance record if the customer requires full variance history. Odoo's standard MRP does not have a native variance object, so we either store variance deltas as Odoo stock.move.line value differences or in a custom mrp.variance model depending on reporting needs agreed during scoping. Variance records keyed to batch_id are resolved after the batch-to-mrp.production mapping is confirmed.

Encompass QC records (batch_id, checkpoint_name, result_status, inspector_id, corrective_action, timestamp) map to Odoo quality.check when the customer licenses the Odoo Quality module. QC checkpoint types map to quality.point records pre-created in Odoo. Pass/fail result_status maps to quality.check status (pass/fail). Corrective_action text migrates to quality.check note. QC schema variation across Encompass tiers and add-on configurations is flagged during data audit; we assess field coverage and present quality module configuration options before migration.

Encompass Sales Order records (order_number, customer_id, order_date, line_items with product_id/qty/price, fulfilment_status, shipping_date) map to Odoo sale.order and sale.order.line. Customer_id resolves to Odoo res.partner via name/email matching. Partial fulfilment status (partially_shipped, pending) requires careful state mapping: Odoo's sale.order state (draft/sent/sale_done/cancel) must align with Encompass fulfilment status so that partially-fulfilled orders land in the correct Odoo state. Product_id resolves to Odoo product.product; pricing migrates as order-level UnitPrice.

Encompass Purchase Order records (po_number, vendor_id, order_date, line_items, expected_delivery, received_qty, po_status) map to Odoo purchase.order and purchase.order.line. Vendor_id resolves to Odoo res.partner (supplier type). Open POs migrate with their current line-item received quantities; closed POs migrate as PO history. Any PO-to-receiving linkage (partial receipts against open POs) requires mapping Encompass receiving records to Odoo stock.picking incoming moves with po_id resolved at migration time.

Encompass Finance Chart of Accounts (account_number, account_name, account_type, cost_centre, segment_structure) maps to Odoo account.account records. Account type (asset, liability, equity, revenue, expense) maps to Odoo's accountType field. COGS, labour, overhead, and revenue recognition accounts are identified during mapping and must be confirmed against Odoo's default chart of accounts structure. We require a customer-reviewed account mapping spreadsheet because company-specific account numbering and segment structures vary; mismatched account IDs break cost-of-goods postings after migration.

Open payables and receivables from Encompass (vendor_id, customer_id, invoice_number, amount_due, due_date, payment_terms, invoice_status) map to Odoo account.move records of type out_invoice (AR) or in_invoice (AP). Customer/vendor IDs reconcile against res.partner records migrated from Encompass Purchase Orders and Sales Orders. Due_date and payment_terms map to Odoo's invoice_date and invoice_payment_term_id. Open invoice amounts must match after partner and account reconciliation; we flag any unreconciled open balance for customer review before final import.

Encompass Production User accounts (user_id, display_name, email, role_name, module_permissions, floor_staff_flag) map to Odoo res.users. Role schemas differ between Encompass tiers, so we extract user assignments and map them to Odoo's access groups (stock.group_stock_user, mrp.group_mrp_user, quality.group_quality_user, account.group_account_invoice). Users with a floor_staff_flag that may have been entered under a shared account are flagged for attribution review before migration because shared-account entries may lack individual owner attribution.

Closed GL entries, COGS postings, and inventory adjustment transactions are migrated as Odoo account.move records of type entry (manual journal entries). Migration scope for historical transactions is negotiated with the customer during scoping because historical transaction volume, account reconciliation completeness, and audit requirements vary by producer. Encompass does not publish a bulk-export endpoint for GL history, so transaction extraction relies on in-app report output that must be assessed for completeness during discovery before this object enters migration scope.