Migrate from Proteus ERP to Odoo ERP

Proteus Customer records map to Odoo res.partner with customer_rank set to distinguish from vendors. The Proteus customer code maps to Odoo's ref field as the dedupe key. Contact data (name, email, phone, address) transfers directly. Buying habits and referral source fields are custom fields in Proteus that may not appear in the standard export; we identify these during scoping and request a full field export that includes them before building the mapping table.

Proteus Vendor records map to Odoo res.partner with supplier_rank set to 1. Vendor code from Proteus maps to the ref field. We check for name collisions against existing Odoo partners during import. The vendor contact fields (email, phone, address) transfer directly, and any vendor-specific notes migrate to an Odoo internal note.

Proteus uses a structured COA with GST-compliant account codes that may use different segment lengths or naming conventions than Odoo's default chart. We build an account mapping table during scoping, mapping each Proteus account code to the corresponding Odoo account type (receivable, payable, revenue, expense, etc.) and ID. Where Proteus accounts do not have a direct Odoo equivalent, we create new accounts under the appropriate Odoo root type and document the decision.

Proteus Item records map to Odoo product.product linked to product.template. SKU, description, and stock levels transfer directly. Pricing tiers map to Odoo's seller_ids and pricelist entries. Multi-revenue-center flagging in Proteus requires Odoo's multi-warehouse and route configuration; we assess whether the destination uses a single warehouse or multiple warehouses and configure routes accordingly. Product category assignments in Proteus map to Odoo product.category.

Open and historical Sales Orders from Proteus map to Odoo sale.order. Header-level data (customer reference, order date, currency) transfers directly. Line items require mapping Proteus item codes to Odoo product.product IDs resolved at migration time. Order status in Proteus (Draft, Confirmed, Shipped, Invoiced) maps to Odoo order states. Any multi-revenue-center assignments on order lines require Odoo's sale.order.line with the route_id or warehouse_id set per line.

Purchase Orders map to Odoo purchase.order with vendor association and line items preserved. The PO-to-receive linkage in Proteus maps to Odoo's picking linked via procurement_group_id. Vendor item codes on PO lines may differ from the master product SKU; we preserve both the Proteus vendor-specific code and the internal SKU on the purchase order line as reference fields.

Proteus Invoice records (GST/HST data and payment status) map to Odoo account.move with move_type set to out_invoice or in_invoice as appropriate. Invoice lines map to account.move.line with debit/credit amounts and account assignments resolved through the COA mapping table. Payment status from Proteus (Paid, Outstanding, Overdue) maps to Odoo payment_state. Historical invoices may require date-range scoping given the potential file sizes from multi-year export batches.

Proteus Employee records require a split decision at migration time. Records that represent system users with login access map to Odoo res.users (provisioned by the customer's admin). Records that represent HR entities (employment history, leave records, dependents) map to Odoo hr.employee. The split depends on whether the customer intends to use Odoo HR apps and whether the Proteus employee records include login credentials. Employees without login access in Proteus migrate as hr.employee only.

Proteus e-commerce orders integrated through the built-in storefront back-end map to Odoo sale.order. The order source (web vs. POS) may be recorded differently in each system; we preserve the order origin in a custom field on the Odoo sale.order. If the customer uses a separate Odoo e-commerce platform (Website + eCommerce), the orders flow through the Odoo website sale module instead. Any historical e-commerce data that does not map cleanly to sale.order is preserved as a custom model or documented for manual review.

Proteus POS Transactions map to Odoo pos.order and linked pos.order.line records. The session-based nature of Odoo POS requires that we either create closed POS sessions in Odoo to match the historical transaction dates, or import the transactions as regular sale orders if the customer does not require POS session reporting. We confirm the preferred approach during scoping based on whether the customer needs historical POS session reports.