Migrate from Deacom ERP to Dolibarr ERP

Deacom dmprod records (pr_id primary key) map to Dolibarr llx_product. Item code becomes ref, item description becomes label, UOM definitions map to unit_of_measurement (Dolibarr's uo base unit). Catch-weight settings from Deacom (cw_enable, cw_uom) have no native Dolibarr equivalent — we create custom decimal fields pjt_weight and pjt_weight_uom on llx_product_extrafields. Facility restrictions on Items require us to evaluate Dolibarr's multi-company or warehouse-scoping approach per the customer's configuration. Item status (active/inactive) maps to finished and stock_quantity at import time.

Deacom BOMs are versioned per Item per Revision with lab-only and regulatory-only variants. Dolibarr's BOM module (llx_bom_bom, llx_bom_bomline) requires explicit activation and does not natively support BOM revision history — it stores one active BOM per product. We export Deacom BOM revisions sorted by revision date, identify Items with multiple active revisions, and present two options: consolidate to the most recent revision at import or create multiple BOM rows per revision (Dolibarr allows multiple BOMs per product with an active flag). The customer selects during scoping.

Deacom customer records (cu_id primary key) map to Dolibarr llx_thirdparty with typethirdparty = 'C' for customer. Customer hierarchies (parent-child customer relationships in Deacom) require us to resolve the parent reference at migration time and set parent_id on the Dolibarr third-party record. Credit terms, customer-specific pricing sheets, and customer-part associations from Deacom dmcust cross-links map to llx_societe_remise and llx_product_customer (or Dolibarr extrafields) depending on which pricing module is activated at the destination.

Deacom vendor master records (dm-type maintenance tables) map to Dolibarr llx_thirdparty with typethirdparty = 'F' for supplier. Vendor purchasing lead times, preferred UOMs, and vendor-specific part cross-references migrate to llx_societe_remise and llx_product_fournisseur_price. We resolve vendor-part cross-references at migration time by matching vendor part numbers to the corresponding llx_product record created from Deacom dmprod.

Deacom sales order headers (dt-type records referencing dmcust and dmprod) map to Dolibarr llx_commande. Order status (open/fulfilled/invoiced) maps to Dolibarr's statut field, and the customer reference maps to llx_commande.fk_soc. Sales order lines map to llx_commandedet with product reference, quantity, and pricing resolved from the linked Item and pricing sheet records. Drop-ship and DSD order flags require custom fields or workflow notes in Dolibarr since DSD workflows are Deacom-specific.

All Deacom inventory movements — receipts, issues, adjustments, and transfers — stored in dt-type tables map to Dolibarr llx_stock_mouvement. We sequence these in timestamp order and resolve the product reference (fk_product) and warehouse reference (fk_entrepot) at migration time. Catch-weight values from Deacom's inventory transactions require us to write them into custom fields pjt_weight and pjt_weight_uom on llx_stock_mouvement_extrafields because Dolibarr's native quantity field does not support dual-weight-per-unit semantics.

Deacom lot numbers, shelf-life dates, and parent-child lot genealogy records require Dolibarr's productbatch module to be activated before migration (llx_product_batch stores batch_number, eatby, sellby, and fk_product). We export lot genealogy records from Deacom and map them to batch entries in Dolibarr. Serial number tracking similarly requires llx_product_lot. If the customer does not activate productbatch at the destination, lot traceability data is preserved in a separate migration report for manual entry rather than silently dropped.

Deacom GL postings (real-time, drill-down to dt transaction level) map to Dolibarr llx_accounting_record. Account codes from Deacom migrate to llx_accounting_account, and journal line items migrate to llx_accouting_movement. We export account codes, journal line items, and source document references (AR/AP/inventory) from Deacom's dxcaption2 and dt-type financial tables. Multi-currency AR from Deacom requires us to also export exchange rate records and store them as Dolibarr llx_multicurrency_rate entries linked to the relevant transactions.

Deacom accounts payable and receivable modules map to Dolibarr llx_facture_fourn (supplier invoices) and llx_facture (customer invoices). Open invoices, payment applications, credit memos, and aging details migrate to llx_paiement and llx_paiement_facture. Multi-currency AP/AR requires us to also export exchange rate records and link them to the Dolibarr invoice records. Status flags (paid, unpaid, overdue) migrate to Dolibarr's statut and paye fields.

Deacom user-defined fields use dmd3 for pick-list options with d3_c2guid links to dxcaption2's system-generated uniqueidentifier values. These _guid values are non-transferable — importing them into Dolibarr creates orphaned references with no validation error. We export the human-readable labels alongside the guids and create a remapping table that maps each Deacom d3_c2guid to the newly created Dolibarr extrafield option ID at the destination. All UDF pick-list fields in Deacom must be recreated as Dolibarr extrafields on the relevant llx_ tables before record import begins.

Deacom production orders (dt-type transaction records referencing pr_id and BOM revision) map to Dolibarr llx_mrp_production if the MRP module is activated. Job costing, routing steps, and labor tracking entries from Deacom require custom fields on llx_mrp_production because Dolibarr's production module does not natively carry job costing or labor tracking. Open production orders require handling as llx_mrp_production with statut set to draft or validated; completed orders migrate as status = produced. If the MRP module is not activated at the destination, production order data is preserved in a structured report for manual entry.

Deacom QC tests are set up per Item/Revision with threshold values, test types, pass/fail criteria, and cross-references to dmd3 pick-list UDF options. There is no native QC module in standard Dolibarr. We map the QC test schema — threshold values and test criteria — to custom extrafields on llx_product_extrafields (per-product QC specification fields) and preserve the test result history in a structured migration report rather than as live records in a QC module. The customer configures a Dolibarr workflow or project-based QC tracking approach post-migration.

Deacom EDI transaction records are stored as document references linked to trading partner setups. We export EDI mapping configurations and functional acknowledgements from Deacom as document metadata and attach them to the relevant llx_thirdparty or llx_commande records. EDI translation rules (the logic that transforms EDI 850/810/856 messages into Deacom transactions) are Deacom-specific and cannot migrate — they require reconfiguration in any EDI-capable Dolibarr module or third-party EDI translator post-migration.

Deacom vendor-specific part cross-references (linking Deacom dmprod items to vendor part numbers and pricing) map to Dolibarr llx_product_fournisseur_price, which stores the vendor third-party reference, unit purchase price, and quantity multiples per product-vendor combination. We resolve the vendor third-party record (fk_societe) and product record (fk_product) at migration time so that all cross-reference records are linked correctly.