Migrate from JD Edwards World to Dolibarr ERP

World's F0101 Address Master holds all business entities (customers, vendors, employees, prospects) under a single AN8 key. We split into Dolibarr llx_societe (third-party organizations) and llx_socpeople (individual contacts). The AN8 becomes a custom external reference field (ref_ext) preserved for audit. Address lines, city, state, postal code, and country map to Dolibarr's address fields with country code validation. We also preserve the World address type flags (Ship To, Bill To, Remit To) as Dolibarr contact type labels.

World F0301 stores AR customer records linked to F0101 by AN8. We extract payment terms, credit limits, tax exemption codes, and AR aging method. In Dolibarr, these map to the llx_societe row with typent_code = 'TE_CUSTOMER'. Credit limit enforcement in World is a business rule; Dolibarr does not enforce credit limits natively, so we store the limit as a custom field and recommend configuring a Dolibarr alert workflow post-migration if credit control is critical.

World F0401 stores AP vendor records with payment terms, 1099 reporting flags, and bank account information for ACH. We extract Remit-To address, 1099 box codes, and vendor bank account detail (Routing Number + Account Number) for ACH setup in Dolibarr. In Dolibarr, typent_code = 'TE_SUPPLIER'. ACH bank data migrates to llx_societe_rib with careful field mapping since Dolibarr's bank account structure differs from World's ACH record layout.

World's F0901 defines the Chart of Accounts using Object.Subsidiary segments that vary by company code. We normalize each World company to a target Dolibarr Chart of Accounts (each company in Dolibarr can have its own chart of accounts). The Object.Subsidiary string is parsed and concatenated into a single Dolibarr account code (e.g., 4100-0001 or 4100.001) with the description preserved. This normalization must be validated by the customer's finance team before import because mis-mapped accounts corrupt financial reporting. We flag any World accounts that reference inactive Cost Codes or Business Units not present in the target chart.

World F0911 stores every journal entry with account, amount, batch number, fiscal period, and subsidiary coding. We extract the current-year open entries and selected historical periods based on the customer's fiscal year cutoff. Post-migration, Dolibarr's Accounting Export module can be used for ongoing journal entry creation, but historical F0911 records are imported as bookkeeping entries with doc_date, code_journal, and num_compte resolved to the target chart of accounts. We flag any F0911 records that reference obsolete Cost Codes, Business Units, or Subledgers not present in the target account mapping.

World F4101 is the central product catalog controlling inventory, procurement, and pricing. We extract item number (LITM/PSITM), description, unit of measure, cost method, and item type flags. World's branch-plant-specific overrides in F4102 (on-hand quantities, location-specific pricing) merge into Dolibarr llx_product as multi-warehouse stock entries. Unit of measure conversions require a mapping table because World uses a defined UOM class system (each item has an owning UOM with defined conversions) while Dolibarr uses a simpler per-product UOM with sell/buy/packaging ratios.

World F4111 stores all inventory transactions (receipts, issues, adjustments, transfers). We extract the on-hand balance snapshot from the most recent F41021 (Item Location) records for immediate seeding in Dolibarr's warehouse stock. Selected transaction history (typically current fiscal year) migrates as Dolibarr stock movement records (llx_stock_movement) linked to the source warehouse and product. Very large F4111 archives (multi-year) are excluded from standard migration to avoid oversized load times; the customer's finance team decides the history cutoff.

World F4311 stores open and historical PO records with line-level detail, delivery addresses, terms, and receipt routing. We extract open POs (status not equal to closed) for migration into Dolibarr Supplier Orders (llx_commande_fournisseur). Line items map to llx_commande_fournisseurdet with product reference resolved to the migrated llx_product record. Closed POs are optionally carried forward as reference records without line-level migration. Receipt Routing information from F4311 does not have a Dolibarr equivalent; we store it as a custom field on the PO for manual follow-up.

World F4211 stores order header and line detail with pricing, backorder flags, and freight terms. We extract open orders for migration into Dolibarr Customer Orders (llx_commande). Line items map to llx_commandedet with the product reference resolved to the migrated llx_product. World's embedded pricing structure (which can reference price tables, discounts, and UOM conversions) is resolved at migration time and stored as fixed amounts in Dolibarr's line price fields. We flag any line items referencing products not yet migrated as a separate reconciliation list.

World F4801 stores manufacturing work orders with routing steps and material requirements (F4802). Dolibarr's Projects module (llx_projet) handles project tracking but lacks native routing, capacity planning, or labor tracking. We map Work Order header to llx_projet, Work Order line (bill of materials from F3111) to llx_projet_task with a flag indicating it originated as a manufacturing BOM. Material requirements from F3111 migrate as Dolibarr stock reservation records. Routing steps have no direct Dolibarr equivalent; we document them as task descriptions within the project plan for manual rebuild if shop floor scheduling is required.

World F060116 stores HR master records including compensation, job data, and organizational assignment. We extract employee name, department, job title, pay grade, and effective-dated history for compliance. In Dolibarr, employees map to llx_user (for system login access) and optionally to llx_societe as contacts of type 'Employee' if the organization tracks employees as third-party records for project assignment. We preserve World cost center and Business Unit assignments as Dolibarr project tags or custom fields. Effective-dated history is stored as a JSON audit trail in a custom field on the user record.

World F0902 stores period and cumulative account balances. We extract the current period opening balance and year-to-date cumulative balance for each account, computing the balance forward from F0911 if F0902 is inconsistent. In Dolibarr, we seed the opening balance on llx_accounting_account as a beginning balance journal entry on the account's first active period rather than storing period-level balances directly, since Dolibarr computes period balances from the bookkeeping entries in llx_accounting_bookkeeping.

World Z-prefixed custom tables (e.g., F55Z100) hold company-unique data that does not map to standard World tables. If the customer provides Z-file specifications during discovery, we attempt to map them to Dolibarr custom fields (llx_extrafields) on the matching standard object. Z-files with complex structures that have no Dolibarr equivalent are excluded from automated migration; we deliver a written specification of Z-file contents, record counts, and recommended Dolibarr implementation approach for the customer's development team. Custom World modified programs (P-prefixed) that alter standard field behavior cannot migrate at all.