Migrate from De Facto ERP to Dolibarr ERP

De Facto Customer records map to Dolibarr Third Parties (table llx_societe) with Type = Customer. We map customer name, primary contact, billing and delivery addresses, and account balance from De Facto's Financials module into Dolibarr's address fields (address, zip, town, country) and the account balance into a custom tracking field since Dolibarr tracks receivable via the invoices module rather than a standing balance field. Payment terms from De Facto map to Dolibarr cond_reglement_id.

De Facto Vendor records map to Dolibarr Third Parties with Type = Supplier. We preserve vendor address, bank details, currency assignment, and tax code from De Facto's multi-country supplier management. De Facto's supplier-specific fields (payment terms, Incoterms) map to Dolibarr's cond_reglement_id and fk_typent for supplier type classification. Currency codes from De Facto carry forward into Dolibarr's multi-currency configuration on the third-party record.

De Facto stock items including SKU, description, unit of measure, and cost price map to Dolibarr Product records. De Facto's landed cost components (freight, insurance, duty, tax per item) map to Dolibarr Extra fields or the Product Extra Prices module since standard Dolibarr does not natively model multi-element landed cost. We create a landed_cost_type field on each product to flag whether cost includes landed components and document the component breakdown in product notes for the customer's finance team to validate post-migration.

De Facto BOM (bill of materials) structures for manufactured items map to Dolibarr Product BOM (llx_product_bom). Each BOM line from De Facto maps to llx_bom_bomline with fk_product, fk_component, and qty required. We preserve the parent assembly product and the component ratios exactly; De Facto's multi-level BOM support maps to Dolibarr's nested BOM structure. BOM validation is performed in a Dolibarr test instance before production migration.

De Facto open invoices, credit notes, and outstanding balances map to Dolibarr Invoice (llx_facture) with status preserved (Draft, Validated, Paid, Cancelled). For open AP/AR, we set the invoice status to match De Facto's payment state and use Dolibarr's payment reconciliation (releve de facture) post-import to match payments. De Facto's transaction-level AP/AR tracking becomes individual Dolibarr invoice records; the customer's admin reconciles partial payments and credit note offsets against the imported documents.

De Facto's chart of accounts exports from TSQL scripts in structured CSV or XML format, which we parse into Dolibarr's llx_accounting_account table. Account numbers, labels, and parent-account hierarchy map 1:1. We flag account types ( receivable, payable, asset, liability, income, expense) against Dolibarr's account_type field. Multi-company chart of accounts from De Facto's multi-entity support map to separate Dolibarr accounting configurations per company entity.

De Facto user records and role assignments map to Dolibarr Users (llx_user) by extracting the user name, email, and active status via TSQL. De Facto's EDP role definitions are often highly custom and do not map 1:1 to Dolibarr's permission groups (Commercial, RH, Accountant). We extract all roles during discovery, present a role translation matrix to the customer's admin, and apply the agreed permission set during migration. Deactivated De Facto users are imported as inactive Dolibarr users with login disabled.

De Facto documents and OCR-linked records are exported from the EDP document management layer as files with their associated record metadata. We map the file content into Dolibarr's documents directory (dolibarr_main_data_root) and restore document-to-record linkages using a reconciliation table that maps De Facto's record IDs to Dolibarr's object IDs (Third Party, Product, Invoice). Any OCR-processed records retain their text content as Dolibarr notes on the linked object.

De Facto historical transactions including purchase orders, sales orders, and warehouse movements export via TSQL script output in CSV or XML. We map these to Dolibarr objects: completed sales orders become Dolibarr Customer Order (llx_commande) with status = Closed, purchase history becomes Supplier Order, and warehouse movements become Dolibarr Stock Movement records. Large transaction volumes are chunked by date range and validated in batches to avoid export timeouts on the De Facto side.

De Facto fixed asset registers including acquisition cost, depreciation method, accumulated depreciation, and asset location map to Dolibarr Asset (llx_asset). De Facto's landed cost tracking for imported items may overlap with fixed asset acquisition cost; we separate them by asset classification during scoping. Depreciation schedules from De Facto map to Dolibarr amortization records (llx_amortissement) with the original acquisition date and depreciation method preserved. Mid-life revaluation or impairment records from De Facto require custom mapping as Dolibarr does not natively handle in-service revaluation.

De Facto CRM opportunity tracking maps to Dolibarr Project (llx_projet) with the opca flag set to distinguish commercial opportunities from internal projects. We map opportunity name, estimated value, stage, expected close date, and associated contacts (linked via llx_element_contact). De Facto's custom CRM fields migrate as Dolibarr extra fields on the Project record. If the Dolibarr commercial opportunity module is activated, opportunities map to llx_societe_commerciaux with stage mapping agreed during scoping.

De Facto's Reporting & Analysis module uses Microsoft SSRS-based report definitions, which are not portable across platforms. We do not migrate SSRS templates. Instead, we export the data that feeds each SSRS report as structured CSVs and deliver a written inventory of every report (name, purpose, data source tables, parameters, scheduling) with a Dolibarr rebuild recommendation. Dolibarr's native reporting or a BI tool like Grafana connected to the Dolibarr database is the recommended replacement path.

De Facto's EDP architecture supports company-specific custom objects that have no standard Dolibarr equivalent. We pre-create the destination schema in Dolibarr by defining new tables (llx_custom_objectname) and custom field definitions (llx_extrafields) before data import begins. All custom field types (string, integer, date, dropdown, checkbox) are mapped to their corresponding Dolibarr field_type values. Lookup relationships between custom objects and standard objects (Third Party, Product, Invoice) are resolved at migration time by matching on the foreign key value extracted from De Facto's TSQL output.

De Facto notes and annotations linked to any master or transaction record map to Dolibarr Note records (llx_note) attached via the object_type and object_id foreign keys. We preserve note creation date and author from De Facto, and restore the parent record linkage by matching the De Facto record identifier against the migrated Dolibarr object ID using the reconciliation table built during the document migration phase.

De Facto warehouse records and multi-warehouse configurations map to Dolibarr Warehouse (llx_entrepot). Stock levels per item per warehouse from De Facto's Product Supply Chain module transfer as Dolibarr Stock Movement records (llx_product_stock) linked to the appropriate warehouse. De Facto's warranty stock tracking for importers maps to a Dolibarr warehouse flagged with a custom status field (warranty_stock) to preserve the operational distinction without losing the data in a generic stock import.