Migrate from Pronto Xi to Odoo ERP

Pronto Xi's hierarchical GL account codes stored in IBM Informix map to Odoo Account records under Accounting / Configuration / Accounting / Accounts. We extract account codes, descriptions, and parent-child relationships via direct DB queries, preserving the f (hierarchy preserved via parent_id on Odoo Account). Account types (Asset, Liability, Equity, Revenue, Expense) map to Odoo's internal_type selection. Account codes with non-numeric characters require normalisation before insert because Odoo Account.code uses Char but enforces a regex configurable per company.

Pronto Xi customer records with address books, contact details, payment terms, and tax codes map to Odoo Contact with the Customer flag enabled. Multi-address scenarios (billing address vs delivery address) map to separate Contact records linked via type (contact / invoice / delivery) under a common commercial partner. Tax identification numbers migrate to Odoo's vat field for VAT reporting.

Pronto Xi supplier records map to Odoo Contact with the Supplier flag enabled. Payment terms from Pronto Xi (days, net, EOM) map to Odoo Payment Term records linked via property_payment_term_id. Supplier-specific fields such as bank account details,tax codes, and purchasing contacts migrate as custom fields on the Contact record.

Pronto Xi item masters with BOMs, cost layers, reorder points, and multi-warehouse location assignments map to Odoo Product records of type Storable. We extract current stock quantities per location and create Odoo Quant records at migration time. Product cost layers map to Odoo's standard cost and avco (average cost) valuation methods; the customer selects during scoping. Item codes map to Product.default_code as the dedupe key.

Pronto Xi BOMs store component items, quantities per assembly, and revision versions tied to manufacturing processes. We extract BOM headers and component lines, mapping them to Odoo's mrp_bom record with mrp_bom_line children. BOM revisions map to Odoo's active/inactive BoM versioning. We flag any BOMs with process manufacturing steps (routing labour, continuous consumption, co-products) that Odoo's discrete BoM model cannot natively represent, and document the gap for the customer's admin.

Pronto Xi work orders carry routing steps, labour allocations, and component consumption records tied to specific BOM versions. We map these to Odoo Manufacturing Order (mrp.production) with source BoM resolved from the BOM migration phase. We flag work order steps referencing rework, tear-down scrap, or process-consumption patterns that Odoo's MO model does not support natively. Work order status (planned, in progress, closed) maps to Odoo's state field (confirmed, in_production, done).

Pronto Xi sales order headers and lines with pricing, discounting, and delivery scheduling map to Odoo Sale Order (sale.order / sale.order.line). We set destination order states based on fulfilment progress to avoid inadvertently confirming back-to-back orders. If Pronto Xi carries multi-company sales assignments, we map them to Odoo's company_id field and ensure the user's access rights cover each company.

Pronto Xi purchase order headers and lines with pricing, lead times, and delivery scheduling map to Odoo Purchase Order (purchase.order / purchase.order.line). We preserve vendor-specific pricing and discount structures in Odoo's purchase order line model, and resolve supplier contacts against the Supplier contact migration phase. PO status mapping follows the same state-based approach as Sales Orders.

Pronto Xi outstanding invoices and credit memos require careful sequencing — we extract open items with aging buckets and reference numbers, then create Odoo Account Move records in the appropriate Sales or Purchase Journal. Payments or credit allocations are applied at the destination in chronological order to preserve clean aging reports. We sequence open AR/AP extraction before triggering the final period close at source to prevent duplicate postings or payment allocation mismatches entering the migration pipeline.

Pronto Xi fixed assets with acquisition date, depreciation method, book value, and asset category map to Odoo Asset records under Accounting / Configuration / Assets. Depreciation types (straight-line, declining balance) map to Odoo's depreciation method selection. Assets linked to specific GL accounts resolve against the Account migration phase.

Pronto Xi environments frequently contain bespoke modules built on the SDK or RAD framework. We identify these during scoping, extract their data structures via direct DB queries, and map them to Odoo custom fields (ir.model.field) on the equivalent standard model or to custom Odoo models if no standard model matches. Any bespoke modules with no Odoo equivalent are flagged in the inventory document with a recommended rebuild approach.

Pronto Xi payroll data is sensitive and often edition-gated. We extract employee records (name, employee number, department, employment status) into Odoo hr.employee. Compensation history, leave balances, and pay categories migrate as custom fields or linked records; the customer specifies which historical payroll fields are required for continuity. We do not migrate active payroll processing or payslip history that requires integration with an Australian payroll platform.