Migrate from JD Edwards World to Odoo ERP

World's F0101 Address Book (AN8 as primary key) is the cross-reference backbone of the entire World database. We split F0101 into Odoo's Contact records (for persons) and Company records (for organizations), with the AN8 address number preserved as a legacy_id field for cross-reference. World address formats (city/state/zip) vary in length and delimiter conventions; we normalize these to Odoo's address fields during transformation. World-specific roles (Customer, Supplier, Employee flag) map to Odoo contact type tags rather than separate record types.

World's F0911 is the journal entry engine for all financial transactions. Each F0911 batch (G/L Date, Batch Number, Document Number) maps to an Odoo Account Move with multiple Account Move Lines. The Object.Subsidiary account number from F0911 must be resolved against the World F0901 Account Master, which defines the segment meaning per company code. We normalize Object.Subsidiary to Odoo's account codes during transformation, validated by the customer's finance team before load. We carry forward the current fiscal year plus one prior year of journal history; older history is archived as a CSV export for compliance rather than migrated into live Odoo records.

World's F0901 defines the Chart of Accounts using Object.Subsidiary segments that vary per company code, meaning the same account number can represent different account types in different World subsidiaries. We map each World company code to a corresponding Odoo Chart of Accounts, and the Object.Subsidiary segments to Odoo's account code structure. Odoo's Analytic Accounts provide dimensional analysis (departments, projects, cost centers) to replicate some of the subsidiary-level detail that World handles through segment variation. Finance team validation of the account mapping is required before Account Master load.

World F4311 open purchase orders migrate to Odoo Purchase Orders with line-level detail including item number, quantity, unit price, and receipt routing. World stores receipt routing and branch-plant assignments at the line level; we extract these as Odoo order line warehouse assignments. We migrate open POs only; closed POs are flagged for optional historical carry-forward based on the customer's fiscal year cutoff preference. Vendor address resolves via the F0101 AN8 lookup.

World F4211 header and line records migrate to Odoo Sales Order. The embedded pricing structure in World (which stores pricing at multiple levels within the order) must be flattened to Odoo's price list model. Backorder flags, order holds, and payment terms migrate as Odoo sale.order.line fields. Customer address resolves via the F0101 AN8 to Odoo Contact lookup. Historical closed orders are optionally carried forward as Odoo Quotation records in a closed state.

World F4801 Work Orders (including shop floor Work Orders and Maintenance Work Orders) migrate to Odoo Manufacturing Orders. Routing sequences from F3002 map to Odoo Work Order operations with work center assignments and cycle times. Bill of Materials from F3003 map to Odoo BoM with component lines. We distinguish between Manufacturing Work Orders and Maintenance Work Orders during scoping and apply Odoo's Maintenance app to the latter if the customer's Odoo scope includes it.

World F4101 Item Master is the central product catalog controlling inventory, procurement, and costing. Branch-plant overrides from F4102 (plant-specific lead times, reorder points, and on-hand quantities) must be merged into Odoo's product record with warehouse-specific settings. Unit of Measure conversions from F41003 migrate as Odoo Units of Measure categories and conversion rules. The Item Branch file (F41026) on-hand balances seed Odoo's initial inventory quantities by warehouse.

World F4111 transaction history (receipts, issues, adjustments) is mapped to Odoo's stock.move records for the active and prior fiscal years. On-hand balances at migration date come from F41026 and seed Odoo's stock.quant table as the initial inventory snapshot. Transactional history beyond the current year is migrated for the prior 12 months based on the customer's reporting cutoff; older transaction history is archived as a CSV for compliance.

World F0301 billing and credit customer records link to F0101 by AN8 address number. We preserve parent-child customer hierarchies (global customer accounts with subsidiary bill-to and ship-to locations) in Odoo's Contact model using address hierarchy. Payment terms from F0301 migrate as Odoo payment.term records. Credit limits from F0301 migrate to Odoo partner credit limits, but Odoo does not enforce credit holds at order entry by default; the customer's admin configures this as an Odoo automation post-migration if required.

World F0401 AP vendor records link to F0101 by AN8, similar to Customer Master. We extract 1099 reporting data and bank account information (for ACH setup in Odoo) as vendor Contact fields. Payment terms migrate to Odoo payment.term records. Tax identification numbers migrate as Odoo contact field values subject to the customer's country-specific configuration.

World HR master records from F060116 migrate to Odoo Employees with compensation, job data, and org assignment. Effective-dated history from World (which stores HR changes with from/through dates) must be simplified during migration; Odoo maintains a current snapshot of employee data with historical changes stored in the attendance and timesheet apps rather than a full effective-dated history. Compliance records (EEOC, benefits enrollment) require separate handoff documentation.

World installations frequently include custom Z-prefixed table files (e.g., F55Z100) that handle industry-specific or company-unique processes. These are not part of the standard World schema and Oracle's conversion programs do not handle them. We explicitly scope Z-file handling during discovery. If specifications for Z-file structures are provided, we extract them as CSV exports for manual entry or custom Odoo development. Z-files integral to core business processes require the customer to budget for a separate custom development engagement after migration.