Migrate from Odoo Enterprise to Epicor Prophet 21

Odoo's res.partner stores both individuals and organizations in a single table with the company_type field distinguishing them. We split during migration: partners with company_type=company become Epicor Company records; company_type=person become Epicor Person records. The original Odoo partner ID is preserved in a custom Epicor field ext_odoo_partner_id__c for cross-reference. Address data (street, city, state, country, zip) migrates to Company addresses or Person addresses depending on entity type. Bank account records migrate to Epicor Payment Methods linked to the appropriate Company.

Individual partners (company_type=person) who serve as sales contacts, purchasing contacts, or customer service contacts migrate to Epicor Contact records linked to the parent Company. We preserve the partner's email, phone, and role/type tags from Odoo category_ids as Epicor ContactType assignments. Odoo's customer_rank and supplier_rank flags map to Epicor Territory assignments for sales routing.

Odoo product.template defines the base product with name, default_code, type (product/service/consumable), and list_price. We migrate each product.template to an Epicor Part record, using product.template.default_code as Part.PartNum and product.template.name as Part.PartDescription. The product type maps to Part.TypeCode (M=manufactured, K=kit, S=sales stock, P=service). Product categories from Odoo migrate to Epicor Product Groups.

Odoo product variants (product.product) inherit from a product.template but carry variant-specific attributes like size, color, or material grade. We migrate each variant to an Epicor Part as a separate Part record with a variant code in PartAlt to track the parent template relationship. The variant attribute values map to Part Selling UOM or PartRestrict per the customer's configuration choice. For manufacturers who use Odoo's product variants for Bill of Materials ingredient sourcing, this splitting is critical for Epicor's PartRev BOM chain.

Odoo Bill of Materials (mrp.bom) with mrp.bom.line components map to Epicor PartRev (BOM revision) and PartOpr (operations/routings) records. Odoo's bom_line.product_id maps to Epicor PartOpr.MaterialPartNum; Odoo's product_qty maps to PartOpr.QtyPer; Odoo operation.workcenter_id maps to Epicor PartOpr.WorkcenterID. Odoo's workcenter resources and cycle times become PartOpr.EstLaborHours and PartOpr.EstRunHours. Multi-level BoMs require recursive PartRev resolution where child BoMs are created as separate PartRev records linked by PartRev.ParentPart.

Odoo stock.quant (on-hand inventory by warehouse and location) maps to Epicor PartBin records keyed by Part, Site, Warehouse, Bin, and Lot/Serial number. Odoo's lot_id and lot_number map to PartBin.LotNum; Odoo's serial_number_id maps to PartBin.SerialNumber. We preserve the on-hand quantity, reserved quantity, and inventory value (at standard cost or FIFO cost from Odoo). Quant snapshots are migrated as opening balances; the Epicor inventory cycle count process reconciles physical counts post-go-live.

Odoo sale.order maps to Epicor OrderHed with order lines (sale.order.line) as OrderDtl. Odoo customer (res.partner) resolves to the Epicor Company and Contact via the partner split. Odoo's order state (draft, sent, sale, done, cancel) maps to Epicor OrderHed.OrderStatus. The Odoo warehouse picking policy (pick and ship from specific warehouse) maps to OrderDtl.WarehouseCode and OrderDtl.ShipRegion. Discount percentages and payment terms from Odoo migrate to OrderDtl.DiscountPercent and OrderHed.TermsCode respectively.

Odoo purchase.order maps to Epicor POHeader with purchase order lines as PODetail. Odoo's supplier partner resolves to Epicor's Vendor record (Company with vendor classification). Odoo's picking_in_policy and invoicing_control map to PODetail.ReceiptType and PODetail.LineTaxes respectively. Odoo's stock.picking (receipts) linked to purchase orders map to Epicor Receipt records against the corresponding PO.

Odoo posted invoices (account.move with move_type=out_invoice or in_invoice) migrate to Epicor InvcHead and InvcDtl. Odoo's partner_id resolves to Epicor Company/Contact; Odoo's invoice lines map to InvcDtl with part number, quantity, unit price, and tax code. Odoo's fiscal_position tax mapping translates to Epicor Tax Region assignments on the invoice header. Paid invoices migrate with payment records; open invoices migrate as outstanding AR/AP against the matched customer or vendor.

Odoo's Chart of Accounts entries migrate to Epicor GLAccount records with AccountCode, Description, and AccountType. This is a configuration step rather than a direct record copy because Epicor's Chart of Accounts ships with country-specific structures that must be installed before data loads. We flag each Odoo account code and recommend the nearest Epicor standard account during scoping, and the customer's Epicor partner or admin finalizes the account mapping against the installed localization template.

Odoo project.project migrates to Epicor Project with project.task records as Epicor ProjectTask under the corresponding Project. Odoo's analytic accounts (account.analytic.account) used for job costing map to Epicor Project with the WBS structure in ProjectTask. Assignee and stage data from Odoo migrate to ProjectTask.Resources and ProjectTask.PhaseID respectively. Odoo's timesheet data (account.analytic.line) migrates as Epicor LaborDtl records linked to the Project and ProjectTask.

Odoo hr.employee records map to Epicor EmpBasic with employee name, department, job title, and employment status. Odoo's employee contracts (hr.contract) migrate as Epicor Labor records with pay rate information where applicable. Odoo's attendance and leave data (hr.attendance, hr.leave) migrate as read-only historical records in Epicor's Time and Attendance module; active leave balances require manual re-entry or a separate time and attendance migration scope. Odoo's bank account and emergency contact data from employee records migrates to Epicor EmpBasic HR data sections.

Odoo stock.picking records (warehouse transfers and deliveries) that are linked to manufacturing work orders migrate as reference data in Epicor's JobMtl (material consumption) and JobOper (operations) context rather than standalone records. Internal transfers between Odoo warehouses map to Epicor PartTran records for audit trail reconstruction. Customer shipments linked to sale orders migrate as Epicor ShipDtl against the corresponding OrderHed.

Odoo stores file attachments in ir_attachment (PostgreSQL db_datas blob or filestore path). We extract both the binary data and the filestore directory tree, reconstruct the file hierarchy, and link documents to Epicor DocumentRevision records via the DocType and External Disk storage path. Linked attachments on sale orders, purchase orders, and invoices attach to the corresponding Epicor entity via DocType linkage rules. PDF attachments from Odoo stock reports and picking lists migrate as document revisions for shop floor reference.

Odoo custom fields created via Odoo Studio or ir.model.fields on standard models (res.partner, product.product, sale.order, etc.) migrate as Epicor User Defined fields (UD fields) on the corresponding Epicor table. Odoo custom model tables (x_custom_model) migrate as Epicor UD Tables with the same field structure. We read the custom model schema via xmlrpc model fields_get, create matching Epicor UD01-UD30 or custom tables, and migrate records preserving all field values and relationships. This step requires the Epicor partner or admin to configure UD field display labels and grid positioning post-migration.