Migrate from Priority ERP to Odoo ERP

Priority Customers (header records with price lists, credit limits, and multi-address hierarchies) map to Odoo res.partner with partner_type=contact. Priority ship-to and bill-to address hierarchies map to Odoo's multi-address structure using the partner address fields. Price lists map to Odoo product.pricelist records. We extract customer reference numbers, payment terms, and credit limits as partner fields, noting that Odoo requires a separate commercial entity partner for B2B hierarchies.

Priority Vendors share the same structure as Customers with purchasing-specific fields (payment terms, W-9 status, 1099 eligibility). They map to Odoo res.partner with supplier_rank > 0 to flag them in the vendor filter views. Priority purchasing terms migrate as Odoo purchase.lead_days and fiscal position rules. Pay-to and ship-from address hierarchies in Priority map to the Odoo partner address model.

Priority Items carry rich attributes: part numbers (hs_sku equivalent), BOM links for manufacturing, stocking dimensions, and warehouse-specific quantities. We extract item headers and variant attributes, handling multi-UOM and BOM relationships during extraction. Items map to Odoo product.product for storable products and product.template for the product definition, with BOMs migrating to Odoo's mrp.bom if the manufacturing module is active in the destination.

Priority Sales Orders include header fields (customer reference, payment terms, freight terms) and multi-line order details with pricing, discounts, and tax allocation. We extract the full order structure and map line-level data to Odoo sale.order.line. Order status (draft, confirmed, shipped, invoiced) maps to Odoo state and picking fields. Historical orders (completed/cancelled) migrate with state preserved but without active picking relations.

Priority Purchase Orders follow a mirror structure to Sales Orders but belong to the Vendors dimension. We extract PO headers and lines, mapping them to Odoo purchase.order and purchase.order.line. Approval workflows in Priority (PO approval chains) are documented as Odoo approval records requiring rebuild in Odoo. Received quantities and pending receipts map to Odoo picking state.

Priority's multi-segment account codes (for example, 01-100-320 representing company-department-cost center) require structural decomposition. Most organizations flatten these into Odoo account codes with the first segment as the account code and the remaining segments mapped to Odoo analytic account dimensions. We validate the segment count and semantics during discovery, present the decomposition strategy to the customer for approval, and configure Odoo's analytic accounts to match the Priority cost center structure. GL account type (asset, liability, equity, revenue, expense) maps to Odoo account_type.

Outstanding payables in Priority carry aging information calculated from the due date. We extract open invoice totals, vendor references, due dates, and aging buckets, then map them as Odoo account.move records with move_type=in_invoice in draft state. Sequential date sequencing is critical: Vendors must insert before vendor bills so that partner lookups resolve correctly. We validate aging totals against Priority's open AP aging report post-load.

Outstanding receivables migrate as Odoo account.move records with move_type=out_invoice in draft state. Priority invoice numbers map to Odoo's ref field, and due dates preserve aging calculation. Credit memos migrate as out_refund moves. Customer must insert before invoices so that partner_id lookups resolve. We validate AR aging totals against Priority's open invoice aging report after load.

Priority Projects track budgets, assignments, billing records, and milestones. We extract project headers and associated WBS rows, time entries, and billing details, mapping them to Odoo project.project and project.task. If Priority uses billing milestones tied to specific GL accounts, those map to Odoo's project billing rules and sale.order.template integration. Active vs archived project state migrates to Odoo's active flag.

Priority Employee records include org unit assignments, role-based permissions, and compensation history. We extract the employee file with department, job title, and manager hierarchy mapping to Odoo hr.employee and hr.department. Salary and benefits data require explicit customer sign-off before migration due to data sensitivity. We note that Odoo's HR module may require activation depending on the customer's Odoo edition.

Priority Journal Entries consist of debit and credit lines linked to account codes, with support for reversing entries and recurring templates. We extract full entry details including posting date, period, and source document reference. Recurring templates are documented as Odoo recurring journal items or scheduled actions for manual rebuild. Reversing entries map to Odoo's reversal mechanism (move_id andreversal_move_id).

Priority's open architecture supports custom tables that hold supplementary business data beyond standard objects. We treat these as custom object data during scoping. We map custom table structures to Odoo custom models using ir.model and ir.model.fields, preserving field types, relationships, and data. If the Priority custom table references standard objects via foreign keys, we maintain those relationships during import using Odoo's many2one fields.