Migrate from Epicor Prophet 21 to Odoo ERP

P21 customer records (cust_mast, custShipTo) map to Odoo res.partner records with address data split into contact addresses. The P21 Customer ID becomes partner_ref on the res.partner; ship-to addresses become child contact records linked to the parent customer partner. Credit limits, pricing tiers, and buyer assignments from P21 cust_mast map to custom fields on res.partner or to dedicated Odoo pricelist records that the Odoo partner configures before migration.

P21 vendor records (vendor_mast) map to res.partner with supplier=True. The vendor-to-item linkage in P21's vendor_part table preserves the preferred-vendor flag on the product-supplierinfo record in Odoo, maintaining replenishment relationships. Payment terms and buyer assignment migrate as custom fields or as Odoo res.partner property fields.

P21 item master records (inv_mast) map to Odoo product.template with type set to product, consumable, or service based on P21's item_type. UoM conversions from P21 default_selling_unit and default_purchasing_unit map to Odoo uom.uom records. Replenishment method (min-max, order point) does not have a native Odoo equivalent without the stock_horizontal_integration or a custom module; we document the gap and the Odoo partner builds the replenishment rules post-migration. Lot/serial controls from P21 inv_mast.lot_tracked and inv_mast.serial_tracked flags set Odoo tracking=lot or tracking=serial on the product.template.

P21 open and historical sales orders extract from oe_hdr (header) and oe_line (line) tables. Order number, order date, warehouse code, terms, and salesrep assignment migrate as order fields. Line items map to sale.order.line with product, quantity, unit price, discount, and warehouse assignment. P21's order-to-customer linkage preserves through the customer-to-contact mapping already completed. Back-order relationships and kit explosions from P21 kit_bom tables require pre-processing before line insertion; we document kit structure dependencies and defer kit BOM migration until product templates are confirmed in Odoo.

P21 PO records extract from po_hdr and po_line tables with vendor pricing, lead times, and receipt schedule data. Partially received POs require line-level receipt quantities to be preserved so that Odoo receives the correct on-order quantity at go-live. PO-to-vendor linkage resolves through the vendor mapping already completed. Odoo purchase.order records are created after product templates are loaded so that product variants are available for line item resolution.

P21 quote headers and lines (quote_hdr, quote_dtl) map to sale.order in draft/quotation state. Expiration dates from P21 exp_date map to validity_date on the Odoo quotation. We flag expired quotes (P21 status = expired) before migration so that Odoo receives only active quotations at go-live, with expired records archived as a separate export for the customer's reference.

P21 GL accounts from the gl_account table export with full account code strings preserved. Odoo requires a PostgreSQL-level CSV import of account.account records with code, name, account_type, and reconcile flag set. Account segment structure in P21 (company-configured segments, sometimes multi-dimensional) maps to Odoo's account code prefix structure. We preserve the full account code string as the Odoo account code and document any segment meaning for the customer's accountant to finalize account type mapping.

Open payables and receivables require careful sequencing and partial-payment tracking. P21 invoice_hdr and invoice_line tables carry payment status flags (paid, partially paid, open) that we use to set Odoo move.state to draft, posted, or locked. For partially paid invoices, the paid amount migrates as a credit or residual, and the Odoo customer's accountant confirms the residual posting at reconciliation. We load open AP/AR after chart of accounts is confirmed in Odoo so that account codes satisfy required field constraints.

P21 warehouse records include bin locations, picking priorities, and cross-dock configurations from inv_loc and related tables. We map each P21 warehouse to an Odoo stock.warehouse, and bin locations map to stock.location records with location_type = internal. Cross-dock configurations in P21 require a custom Odoo route (route_id = cross-dock) set on the warehouse or product; we document the gap and flag it for the Odoo partner to configure.

P21 lot and serial number tracking links to inv_tran (inventory transaction) history. We preserve lot_number, expiration_date, and cost layer (FIFO or lot-specific) from the P21 inv_lot table. Each lot/serial record links to the mapped product.template in Odoo via product_id. Full traceability chains (lot-to-receipt-to-shipment) migrate as stock.move.line records with lot_id and location_dest_id resolved through the warehouse and location mapping. Cost layer information migrates to stock.valuation_layer or as a custom field depending on Odoo's inventory valuation configuration.

P21 user accounts and employee records extract with role-based permissions. We map P21 users to Odoo res.users by email, and role assignments map to Odoo access groups (res.groups) based on the P21 role matrix. Owner assignment on orders and quotes migrates by resolving P21 user_id to Odoo res.users id via the user mapping table. Any P21 user without a matching Odoo user goes to a reconciliation queue for the customer's admin to provision before record import.

P21 user-defined fields stored in extension tables or custom columns do not migrate as data. We audit every P21 UDF column during discovery, document the table.column name, data type, and which P21 table it extends, and deliver this as a UDF inventory. The customer's Odoo partner creates corresponding custom fields (ir.model.fields) on the equivalent Odoo model before migration so that UDF data can be loaded as a supplemental CSV import in a second pass.