Migrate from iDempiere to Dolibarr ERP

iDempiere Business Partners map to Dolibarr Third Parties. We map the BP category (Customer, Vendor, or both) to Dolibarr's Prospect/Customer/Supplier type flags. Address and contact tabs map to Dolibarr's address and contact records (llx_socpeople) with the parent Third Party as fk_soc. Credit limit from iDempiere maps to the credit note threshold in Dolibarr's Third Party settings. BP pricing schemas require translation to Dolibarr's price supplier and customer pricing rules.

iDempiere Products map to Dolibarr Products (type 0 = item, type 1 = service). BOM structures in iDempiere map to Dolibarr's BOM module if installed, or are decomposed into multi-level product relationships documented for manual configuration. Cost methods (Standard, Average, FIFO) require translation: Dolibarr's accounting module provides stock valuation; for advanced costing the customer may need the Product Batch or Margins module. Product categories map directly to Dolibarr's category system.

iDempiere C_Order records map to Dolibarr Propal (proposal/quotation) for quotations or Commande client (sales order) for confirmed orders. Document status (Draft, CO, VO, CL) maps to Dolibarr's statut (billed, closed, draft, open, signed). Order lines with product references resolve via the Product mapping. Payment terms map to Dolibarr cond_reglement. Note that iDempiere's multi-line sales regions for grouping do not have a Dolibarr equivalent and are documented for manual reorganization.

iDempiere M_PurchaseOrder records map to Dolibarr Supplier Proposal or Supplier Order (Commande fournisseur) depending on the confirmed status. Vendor pricing agreements in iDempiere map to Dolibarr's supplier price lists (llx_product_fournisseur_price). Line-level taxes, discounts, and UoM conversions carry over with the same precision. iDempiere's blanket PO concept maps to Dolibarr's Supplier Proposal with a validity period.

iDempiere C_Invoice (both AR and AP) maps to Dolibarr Facture. We separate iDempiere's C_BPartner_Location-driven invoice header from its line structure. Tax codes in iDempiere map to Dolibarr's tax rate system (taux and localtax). Payment allocations (C_PaymentAllocate) map to Dolibarr's payment/payment_supplier_detail lines. Historical paid invoices carry their settled status; open invoices are flagged as unpaid for the customer to apply payments post-migration.

iDempiere C_Payment records map to Dolibarr Payment (llx_paiement). Bank statement entries (C_BankStatementLine) map to Dolibarr's Accountancy module for reconciliation. Cash journal entries map to Dolibarr's Banque accounting entries. Payment terms (C_PaymentTerm) translate to Dolibarr cond_reglement records. The allocation between invoice and payment migrates so that open invoices show correct aging post-migration.

iDempiere C_Project records map to Dolibarr Project (llx_projet). Project phases and tasks map to Dolibarr's task structure under the project. Time entries in iDempiere map to Dolibarr's expense reports or timesheet lines if the Timesheet module is activated. Milestone tracking maps to Dolibarr's task progress fields. Resource assignments (C_ProjectLine) require translation to Dolibarr's contact/user project roles. Custom project types defined in the Application Dictionary do not migrate as types; we document them for Dolibarr module configuration.

Dolibarr does not include a native fixed asset management module in its core package. Assets in iDempiere (A_Asset) require the customer to either activate a third-party asset module from Dolibarr's marketplace or use the accounting module to manage depreciation through journal entries. We export the full asset register (asset book, depreciation method, book value, service history) and deliver a written configuration plan for the selected Dolibarr asset approach. Depreciation schedules convert to recurring journal entry templates in Dolibarr's accounting module.

iDempiere's multi-schema dimensional GL (with Account, Legal Entity, Business Partner, Product, Location, and Project dimensions) maps to Dolibarr's standard double-entry accounting structure. We translate the chart of accounts, recreate account mappings for the most-used dimension combinations as sub-accounts, and preserve opening balances as GL journal entries in the target accounting schema. Multi-schema organizations require separate Dolibarr accounting configurations per entity. The dimensional GL structure beyond standard account hierarchies is simplified; complex dimensional reporting requires Dolibarr's optional reporting modules or a BI tool.

iDempiere AD_User records map to Dolibarr llx_user with login, email, and status. Role-privilege records (AD_Role) map to Dolibarr's permission groups (permission_profil). iDempiere's Client > Organization hierarchy does not translate directly because Dolibarr uses a flat entity model; we assign users directly to Dolibarr entities (Establishments) and configure Dolibarr's permission profile for row-level access control. Users without a matching email in the destination require admin provisioning before migration proceeds.

iDempiere attachments stored in the database (LOB) or filesystem are exported and mapped to Dolibarr's /documents/ directory structure. We detect the iDempiere storage provider at scoping and run the Migrate Storage Provider plugin if needed before extraction to normalize all attachments to filesystem. Attachments are organized by module in Dolibarr (third party documents under the Third Party record, product files under Product, project files under Project). The AD_Changelog history table is not migrated; it is archived as a SQL dump for audit purposes only.

Custom windows registered in iDempiere's Application Dictionary are backed by custom database tables. We export the underlying table data and AD registration metadata as a written specification for the customer to re-implement in Dolibarr. The visual form layout cannot migrate automatically because Dolibarr's UI framework is entirely different. We deliver a field-level inventory of each custom table's columns, data types, and any foreign key dependencies so that the customer's developer can recreate the structure using Dolibarr's extra fields (for additions to standard tables) or a custom PHP module (for new entities).