Migrate from MERCI to Dolibarr ERP

MERCI Customer records map to Dolibarr Third Party objects with the Tiers type flag set to Customer. We map MERCI's customer name to dolibarr.nom, address fields to address/zip/town/country columns, and contact phone/email to the contact sub-table linked via s.rowid as fk_soc. MERCI custom fields attached to customer records are discovered during profiling and mapped to dolibarr.extrafields columns or stored as dolilbarr.categorie entries. Billing and shipping addresses stored as separate MERCI records flatten into the Third Party address fields and the address_type sub-table.

MERCI Vendor records map to Dolibarr Third Party with the Tiers type flag set to Supplier. We map vendor name to dolibarr.nom, bank account details to rib fields, and payment terms to the suppliers_payment_module. Vendor contacts migrate as dolibarr.socpeople records linked via fk_soc. Address flattening logic mirrors the Customer mapping.

MERCI Sales Orders map to Dolibarr Proposal (propale) for quotations awaiting acceptance or to Commande (sales order) for confirmed orders. We map MERCI order header fields to dolibarr.propal (ref, date, client_ref, total_ht, total_tva, total_ttc) and line items to propal_ligne with fk_product resolved from the Items mapping. Order status maps from MERCI status codes to Dolibarr PropalStatus values (draft, open, signed, notsigned, closed). Source order IDs are preserved as a custom field for audit.

MERCI Invoices map to Dolibarr Facture records. We map invoice number to ref, invoice date to datef, due date to date_echeance, and line items to factureligne. VAT amounts map to local tax fields (tva_tx, total_tva). Open versus closed invoice status requires a pre-migration review of MERCI's status code taxonomy against Dolibarr's FactureStatus values (draft, validated, paid, abandoned). The MERCI order-to-invoice linkage is preserved by storing the source order ID in a custom field on the Dolibarr Facture record.

MERCI Items include product and service variants that map to dolibarr.product (type=0 for goods, type=1 for services). We map MERCI item code to ref, description to label, and pricing tiers to price levels in the product_price table. Bundle and kit compositions from MERCI must be expanded into flat Dolibarr line items because Dolibarr's BOM (Bill of Materials) module handles kit explosion separately. If the customer uses the DOLIBARR stock module, we configure warehouse references before importing stock quantities from MERCI.

MERCI's simplified five-type account taxonomy (asset, liability, equity, revenue, expense) maps to Dolibarr's double-entry accounting structure. We map MERCI account codes directly to dolibarr.accounting_account.account_number and account names to label. Account type translation requires verifying each MERCI account type against Dolibarr's account category taxonomy (Comptes financiers, Immobilisations, Stocks, Comptes fournisseurs, Comptes clients, Charges, Produits). We configure the accounting journal and financial year in Dolibarr before importing account records so that opening balances can be set correctly.

MERCI Employee records map to Dolibarr User records (for login-capable staff) and optionally to thehrm_recruitment_employee or other HR module tables if the customer activates Dolibarr's HR module. We map MERCI employee name to User lastname and firstname, email to login, and department to the relevant group or team assignment. Active versus inactive employment status maps to User status (0=inactive, 1=active). Effective-dated compensation history that lives in MERCI custom fields requires pre-migration cleanup or custom field creation in Dolibarr.

MERCI binary attachments (PDFs, order documents, images) stored in the proprietary blob store cannot be retrieved through any documented export endpoint. We flag Attachment objects as unsupported and direct customers to download files manually from the MERCI UI or to request a full blob export directly from MERCI's hosting team. If the customer has Gigabytes of attachments, a direct database dump of the blob storage is the only practical path and requires coordination with MERCI's infrastructure team.

MERCI order line items map to Dolibarr propal_ligne (for Proposal) or commande_ligne (for Order). We resolve fk_product by looking up the MERCI item SKU against the Dolibarr product ref field, and fall back to a description-only line if no match is found. Quantity, unit price (price_ht), VAT rate (tva_tx), and discount (remise_percent) map directly. Partial line failures are handled by logging the failure and continuing the import so that a single bad line does not block the entire order.

MERCI invoice line items map to Dolibarr facture_ligne with the same fk_product resolution strategy used for order lines. Line item sequencing is preserved by setting line order position. Credit note handling requires identifying MERCI negative-amount invoices and mapping them to Dolibarr Facture type=credit_note (facture type code = CREDIT_NO_CHARGE or factoring).

MERCI payment records linked to invoices map to Dolibarr paiement records with fk_facture resolved through the invoice number mapping. Payment method (cash, check, bank transfer) maps to dolibarr.c_paiement entries. We link each paiement to the corresponding facture via paiement_facture. If MERCI stores partial payments against a single invoice, each partial payment becomes a separate Dolibarr paiement record with the amount split proportionally.

MERCI deployments may carry custom fields on any standard object due to the single-tenant schema flexibility. During data profiling we discover all MERCI columns that are not part of the notional baseline schema and create corresponding Dolibarr extrafields entries (fk_extrafields on the target table) before importing any data. Custom picklist values in MERCI are translated to Dolibarr extrafields options during this phase. This step is the primary driver of timeline extension in MERCI migrations.