Migrate from Sage Business Cloud X3 to Odoo ERP

X3 Business Partners of type Customer map to Odoo Partner records of category Customer, with contact details extracted into separate Odoo Address records (res.partner.addresses). The X3 BP address block, payment terms, credit limit, and currency settings become fields on the Odoo Partner. X3 BP email, phone, and tax ID migrate as Partner fields. We preserve the X3 BP code as the Odoo Partner's ref field for traceability. Supplier BPs follow the same pattern under category Supplier.

X3 supplier Business Partners map to Odoo Partner records under category Supplier. The X3 supplier address, payment terms, bank details, and fiscal ID migrate as fields on the Partner. Multiple X3 delivery addresses per supplier are split into separate Odoo Address records. Tax registration numbers from X3 map to Odoo's fiscal position matching for tax calculations in the destination.

X3 Sales Orders exported via template ZSOH map to Odoo sale.order. We map order header fields (customer reference, order date, currency, payment terms) and order lines (product, quantity, unit price, discount, tax, warehouse) directly. X3 delivery addresses embedded in the order become linked Address records on the Odoo sale.order. Order status is preserved in a custom field x3_order_status__c for reconciliation against the source during validation.

X3 Purchase Orders map to Odoo purchase.order with the same field-level mapping as Sales Orders but against the supplier Partner. X3 approval workflow status is not transferred as a constraint; all approved X3 POs are migrated as confirmed Purchase Orders in Odoo. X3 commitments (POs not yet received) are migrated as confirmed but pending receipts.

X3 hierarchical chart of accounts maps to Odoo account.account with careful attention to account type (view, receivable, payable, liquidity, revenue, expense, other). Segment codes and cost centre dimensions from X3 map to Odoo analytic.account records for multi-dimensional reporting. We preserve the full X3 account code structure, including leading zeros, as the Odoo code field. Multi-currency settings on X3 accounts become currency restriction rules in Odoo.

Open AP invoices in X3 are extracted and posted as draft Vendor Bills in Odoo. The X3 BP vendor code links to the mapped Odoo Supplier Partner. We set the Odoo bill to draft status so the customer's AP team can review and post after validation. Payment terms, due dates, and outstanding amounts are preserved. Historical paid invoices are migrated as journal entries rather than bills to avoid re-triggering payment reconciliation.

Open AR invoices in X3 map to draft Customer Invoices in Odoo. Each invoice links to the mapped Customer Partner and the correct receivable account from the Odoo chart of accounts. We preserve invoice dates, numbers, currency, and line-level detail including tax codes mapped from X3 to Odoo tax configurations. Historical closed invoices are migrated as completed journal entries to preserve the audit trail without re-opening the reconciliation.

X3 Fixed Assets with acquisition cost, depreciation schedules, and asset registers map to Odoo account.asset.asset. The X3 acquisition date, original cost, and depreciation method (straight-line, declining balance, sum-of-years) are mapped to Odoo asset profile and depreciation lines. For X3 assets with multiple depreciation books (GAAP, tax, statutory), we create separate Odoo asset records per book or configure multiple depreciation schedules on a single asset depending on the customer's reporting requirements.

X3 parallel depreciation books per asset require mapping to Odoo depreciation schedules. We extract all active depreciation books with their method, convention, and annual/monthly depreciation amounts, then configure matching depreciation boards in Odoo. Tax book and statutory book values migrate as separate depreciation schedules against the same asset record, with the Odoo account.asset.asset model supporting multiple lines per schedule for period-level precision.

X3 Products (stock items) map to Odoo product.product with type=product. The X3 product code, name, unit of measure, and cost price migrate directly. X3 multi-location stock levels (site-based) map to Odoo stock.quant records at the location level, with lot/serial numbers preserved from X3 lot tracking. Products with BOMs (bill of materials) are flagged for BOM migration in the production module step.

X3 Production Orders map to Odoo mrp.production. We migrate Work Order headers, component consumption, and operation sequences. The BOM-routing linkage from X3 must be re-established in Odoo because Odoo's manufacturing module stores BOMs and workcentres as separate objects. We extract X3 BOM and routing data, then create the equivalent Odoo mrp.bom and mrp.routing records, linking them to the migrated Manufacturing Orders. Manufacturing quantities, states (draft, confirmed, in progress, done), and scheduled dates transfer directly.

X3 named-user accounts map to Odoo res.users. We resolve X3 user IDs to email-based logins in Odoo (or flag for admin provisioning if email is unavailable from X3). X3 function-level permissions per site and company map to Odoo's access rights groups. The X3 multi-site access assignments are reconstructed as Odoo multi-company and warehouse access rules. A role mapping table is produced as part of the discovery output so the customer's Odoo admin can validate group assignments before go-live.

X3 custom fields on business objects (stored as extended table columns) are detected during discovery and mapped to Odoo ir.model.fields as extra fields on the corresponding Odoo model. We use Odoo's native extra field creation mechanism rather than modifying the core schema. Custom field type mapping accounts for X3 data types (string, integer, decimal, date, selection) against Odoo field types (char, integer, float, date, selection). Fields that cannot be represented natively in Odoo are documented as custom fields requiring Odoo developer configuration.