Migrate from Infor XA to Dolibarr ERP

Infor XA stores customer and supplier entity records in the Companies/Entities file with address, terms, and payment method fields. We map these directly to Dolibarr ThirdParty records, distinguishing customers from suppliers via a Type field (Customer or Supplier). The customer number or supplier number from XA becomes the Dolibarr ref_int or customer_code field for reconciliation. Multi-address and multi-contact records in XA map to Dolibarr contact and address sub-objects with the parent ThirdParty as the anchor.

XAM contact records associated with entity files map to Dolibarr Contact objects linked to the corresponding ThirdParty. We extract name fields, email addresses, phone numbers, and roles from XA's contact tables and map them to Dolibarr's contact structure with the parent llx_societe_id set at import time.

Infor XA item master records carry stocking codes, cost methods, unit-of-measure, and warehouse assignments. We map these to Dolibarr Product records with the type set to Product (not Service). Stock quantities map to llx_product_stock per warehouse. XAM's cost method (standard, average, FIFO) is preserved as a custom product property in Dolibarr since Dolibarr's default stock valuation does not expose all cost method variants natively.

Infor XA BOMs support multi-level, phantom, and substitute item structures with effective dates. Dolibarr has no native BOM or product recipe module in its standard distribution. We extract BOM structures from XA, document them in a written bill-of-materials inventory (item hierarchy, quantities per assembly, scrap percentages, effective dates), and recommend whether the customer's team rebuilds BOMs in a custom Dolibarr module, in a spreadsheet, or through a dedicated PLM add-on from the Dolibarr marketplace. This is a significant gap that must be acknowledged before migration scope is finalized.

Infor XA work orders drive shop floor control and link to routing, labor posting, and costing. Dolibarr has no dedicated work-order object. We map open and historical work orders to Dolibarr Project records with a custom work-order reference, and attach labor and material consumption as Project tasks and time entries. Customer-linked work orders reference the corresponding ThirdParty. This is a partial resolution that preserves history but does not replicate the production-scheduling and costing depth of XA's work-order module.

XAM routings define operation sequences, work centers, and labor or machine standards tied to production. Dolibarr has no routing or work-center object. We extract routing definitions and document them as structured task templates within Dolibarr Projects, with work center references preserved as text fields. Operation times and standards migrate as estimated durations on Project tasks.

XA PO headers and lines carry supplier assignments, terms, delivery schedules, quantities, and prices. We map open purchase orders (status Open or Released) to Dolibarr Supplier Order records, linking each to the corresponding ThirdParty supplier. Line items map with product reference, ordered quantity, unit price, and delivery date. Historical closed POs are not migrated unless the customer specifically requests them for audit or supplier reconciliation purposes.

XA sales orders link to pricing, availability checking, and inventory allocation with order headers, line items, delivery addresses, and order-specific discounts or special terms. We map open customer orders to Dolibarr Customer Order records linked to the ThirdParty customer. Line items preserve product reference, quantity, unit price, and delivery schedule.

XAM GL accounts are defined in a structured chart of accounts with account codes, descriptions, and posting controls. Standard GL account definitions export cleanly from Db2 and map 1:1 to Dolibarr Accounting Account records (if the Accounting module is enabled). We preserve account code structure, descriptions, and whether the account is a header or detail account.

Outstanding payables and receivables in XAM carry customer or supplier references, invoice numbers, due dates, and amounts. We extract open AP and AR documents and map them to Dolibarr Customer Invoice and Supplier Invoice records, flagging any invoice that references a GL account not present in the migrated chart of accounts. Historical closed invoices are not migrated unless required for audit trail reconstruction.

Time entries, labor posting, and operation completions in XAM's shop floor module tie to work orders and employees. We extract labor hours by work order and map them to Dolibarr Project task time entries linked to the corresponding Project. Employee references resolve to Dolibarr User records. This preserves labor cost history in aDolibarr Project but does not replicate the costing and variance reporting of XAM's shop floor module.

XAM user accounts and IBM i security profiles define access rights and default accounting entities. We extract user records (name, email if populated, department) and map them to Dolibarr User accounts. XAM's role-based access (purchasing approver, shop floor operator, finance clerk) maps to Dolibarr's permission groups, though Dolibarr's permission model is less granular than IBM i's profile-based security. We flag any XAM role that has no direct Dolibarr permission equivalent.