Migrate from Infor XA to Odoo ERP

Item master records in XA carry manufacturing attributes including stocking codes, cost methods (FIFO, standard, average), warehouse assignments, and unit of measure. We map these to Odoo product records, setting the product type (stockable, consumable, service) based on the item's stocking code. Unit of measure conversions and product category assignments require field-level mapping. Multi-company item sites map to Odoo warehouse-specific stock locations. Lot/serial number tracking configuration migrates to Odoo's lot/serial traceability settings.

XA BOMs support multi-level, phantom, and substitute item structures with effective dates and BOM type codes. Migration requires recursive BOM explosion to flatten nested hierarchies into Odoo's parent-component model, preserving operation sequences, scrap percentages, and routing references. Phantom BOMs map to Odoo's phantom BoM type. Substitute items require separate product links in Odoo after the primary BoM is created. We flag any BOMs with unresolved component items as a reconciliation item before the import phase.

XAM routings define operation sequences, work center assignments, and labor or machine time standards tied to production. We extract routing definitions and map them to Odoo Work Center records (with capacity, time efficiency, and costs) and Odoo Routing records that link operations to work centers. Work center costing rates from XA (labor rate, machine rate) map to Odoo's Work Center costs field. Operation sequences and step dependencies migrate directly to Odoo routing operation lines.

Open and historical work orders in XA drive shop floor control and link to routing, labor posting, and costing. We extract work order headers and operation lines, map their statuses (released, in-progress, completed, closed) to Odoo MO states, and preserve the component allocation, routed operations, and associated item and BOM references. Historical closed work orders migrate as MO records in a done state for costing and audit purposes. Any work order without a valid item or BOM reference is flagged for manual resolution.

PO headers and lines in XA carry supplier assignments, terms, delivery schedules, and line status. We map header-level fields (PO number, date, terms, buyer) and line-item details (item number, quantity ordered, unit price, delivery date, status) to Odoo purchase.order and purchase.order.line. Open POs migrate with their full line detail and outstanding quantities. Closed and cancelled POs migrate as historical records. Purchase agreement references from XA map to Odoo's Blanket Orders when applicable.

Supplier records in XA include address, payment terms, tax registration, and purchasing defaults. We map suppliers to Odoo res.partner records with the is_company and supplier_rank flags set. Payment terms, fiscal position, and purchase currency map to the partner's accounting settings. Multi-address supplier records require address-type resolution (ship-to vs bill-to). Supplier-specific item pricing in XA maps to Odoo's seller_ids on the product form.

Customer records in XA include address, payment terms, credit limits, and sales defaults. We map customers to Odoo res.partner records with is_company and customer_rank flags. Multi-address customer records require address-type resolution in Odoo. Credit limits and payment terms map to partner accounting settings. Sales area and territory assignments from XA map to Odoo's sales team or area fields if configured.

Sales orders in XA link to pricing, availability checking, and inventory allocation. We map order headers, line items, delivery addresses, and order-specific discounts or special terms. Open sales orders migrate with outstanding quantities and delivery schedules intact. Pricing rules and discount matrices from XA are documented as Odoo Pricelist configurations to be rebuilt post-migration. Order history migrates as closed sale.order records for audit and reference.

GL accounts in XA are defined in a structured chart of accounts with account codes, descriptions, and posting controls (natural account, posting edit code, unit controller). Standard GL account definitions export cleanly and map 1:1 to Odoo account.account records. Account type (asset, liability, equity, revenue, expense), reconcile flag, and group assignments migrate directly. Cost center and department coding from XA maps to Odoo's analytic account structure or dimension tags depending on the customer's Odoo configuration.

Outstanding payables and receivables carry customer or supplier references, invoice numbers, due dates, and amounts. We extract open AP/AR documents and map them to Odoo account.move records with type set to in_invoice or out_invoice, preserving the partner reference, invoice date, due date, and open amount. Partial payments and payment terms require line-level resolution. Currency conversion for multi-currency AP/AR records uses the exchange rate at the migration effective date, documented for reconciliation. Historical AP/AR aging reports serve as the opening balance validation reference.

Time entries, labor posting, and operation completions recorded in XA's shop floor module tie to work orders and employees. We extract these records to reconstruct labor cost histories in Odoo analytic account lines linked to manufacturing orders. Operation-level time tracking maps to Odoo MO work orders with workcenter time logs. Labor cost summaries migrate to Odoo's analytic accounting for production costing analysis. Detailed clock-in/clock-out records require additional discussion as Odoo's standard timesheet module may require configuration.

XAM user accounts and IBM i security profiles define access rights and default accounting entities. We extract user records and map them to Odoo res.users with internal users flagged. IBM i security profiles (special authorities, menu access) do not have a direct Odoo equivalent; we map them to Odoo's Groups (access rights per application module) based on the user's XAM role. Any user without a valid email in XAM is flagged as a manual provisioning item before Odoo access is granted. Active vs inactive status migrates to Odoo active field.

XAM supports user-defined alphanumeric, numeric, and date fields attached to items, suppliers, and purchase agreement headers via CMS470. These require explicit field-level mapping to Odoo custom fields created before migration. We pre-create Odoo custom fields with appropriate types (char, float, date, selection), attach them to the target model (product.product, res.partner, purchase.order), and migrate the values during the parent record import. Any custom field without a matching Odoo field definition is flagged as a configuration gap before data import begins.