Migrate from Visibility ERP to Dolibarr ERP

Visibility ERP Companies map to Dolibarr Third Parties. The Company Name, Address, Phone, Email, Tax ID, and Payment Terms fields migrate directly. Dolibarr distinguishes between Customers (type societe + client=1), Suppliers (type societe + fournisseur=1), and Prospects (type societe + client=0 or 2). We determine the type from Visibility's account classification during scoping. A custom field visibility_account_type__c preserves the original classification if it does not map cleanly to Dolibarr's three-tier model.

Open and historical Sales Orders from Visibility map to Dolibarr Commandes clients. The order header (customer reference, order date, delivery date, payment terms) migrates directly. Line items map to Commandes lignes with product reference, quantity, unit price, and discount preserved. Order status (Draft, Submitted, Shipped, Invoiced, Closed) maps to Dolibarr's statut field (0-4). Lines linked to configured BOM items in Visibility are migrated as standard product lines in Dolibarr; the BOM hierarchy is not recreated in Dolibarr's standard schema.

Open Purchase Orders from Visibility map to Dolibarr Commandes fournisseurs. Vendor reference, PO number, line items (product, quantity, unit cost, scheduled receipt date), and status migrate directly. Closed POs are migrated as historical records with statut=5 (Canceled) or 4 (Shipped) as appropriate. POs with multi-line shipments in Visibility are flattened to the PO line level in Dolibarr, which does not natively track partial receipts at the PO line granularity without the reception tracking module enabled.

Visibility inventory items map to Dolibarr Products (type=1 for stockable, type=0 for service). SKU, description, unit of measure, cost price, and selling price migrate directly. Lot and serial number tracking maps to Dolibarr's lot/serial module if enabled; we flag this as a module activation requirement during scoping. Bin locations from Visibility do not map to a standard Dolibarr field and are stored in a custom extrafield warehouse_location__c for manual bin management in Dolibarr's stock menu.

Lot-controlled items in Visibility require us to map the lot assignment at the inventory transaction level, not just the item master. Each lot carries lot number, expiration date, and linked transactions. We migrate these to Dolibarr's llx_product_lot table, which requires the stock module to be activated. Lot-linked quality records from Visibility are stored as notes attached to the lot record in Dolibarr; there is no native QC module in standard Dolibarr. If lot traceability is mission-critical, we flag the module activation and validate the lot import separately during the sandbox test.

Visibility's hierarchical GL code structure varies by deployment (segmented vs. flat). We extract the full account tree, map account types (Asset, Liability, Equity, Revenue, Expense), and validate that Dolibarr's account structure (plan comptable Français or a custom chart) accommodates the imported codes. Dolibarr's accounting module must be explicitly enabled and configured with the appropriate chart of accounts before any GL data imports. We do not migrate account balances (open AP/AR carry their own aging amounts) — balance carryforward is a period-open task for the customer's accountant post-migration.

Open vendor invoices, credit memos, and payment records from Visibility map to Dolibarr Factures fournisseurs. We map invoice number, vendor reference, invoice date, due date, and aging amount. Payment status (Paid, Partially Paid, Unpaid) migrates to Dolibarr's paiemente定于 field. Each invoice is created with statut=0 (Draft) and validated in sequence so that the account balances accumulate correctly against the corresponding vendor account. Credit memos are created as type=2 (credit note) in Dolibarr.

Open customer invoices, credit memos, and payment records from Visibility map to Dolibarr Factures clients. Invoice number, customer reference, invoice date, due date, and aging amount migrate directly. Aging period buckets (Current, 30, 60, 90, 120+) from Visibility are preserved as a custom field aging_bucket__c on each invoice record for reconciliation after migration. Credit memos are created as type=2 (credit note) and can be linked to outstanding invoices for offset during the first reconciliation cycle.

Visibility ERP multi-level BOMs (phantom, configured, and standard) have no direct Dolibarr equivalent in the standard distribution. Dolibarr's Product-on-Product BOMs support single-level assembly structures only, and the manufacturing module is not part of the core distribution. We do not migrate BOM hierarchies as automated records. We produce a written BOM inventory from Visibility (parent part, component parts, quantities, routing association, revision) as a CSV that the customer's team uses to manually rebuild assemblies in Dolibarr's Product module or a third-party manufacturing module. Work Orders referencing BOMs in Visibility are flagged as a manual reconstruction scope.

Visibility Work Orders carry routing steps, labor estimates, material allocations, and status histories that do not exist as a standard object in Dolibarr. We migrate the Work Order header (part number, quantity, scheduled start/end, status) as a Dolibarr Project record with a custom extrafield work_order_number__c for cross-reference. Material allocations and routing steps are not migratable in standard Dolibarr and are documented in a written workback plan for manual entry or MES integration.

Production Orders in Visibility reference the BOM and Routing to generate material and labor requirements. Dolibarr has no native production order module in the standard distribution. We produce a written inventory of open Production Orders (header, linked BOM revision, operation step sequence, status) as a migration artifact. Customers who require shop-floor scheduling post-migration should evaluate Dolibarr-compatible manufacturing modules or a separate MES before deciding how to cover this gap.

Visibility Routings define the sequence of manufacturing operations, work centers, and standard times. Dolibarr does not have a native routing or work-center object in its standard distribution. We export routing headers and operation steps as a structured CSV during scoping and deliver it as a manual-rebuild artifact. If Dolibarr's Project module is used to approximate routing steps as project tasks, we note that this is an approximation only and does not integrate with Dolibarr's stock or purchasing modules.

QC inspection results, non-conformance records, and corrective actions linked to Work Orders and inventory transactions in Visibility have no Dolibarr equivalent. We export QC records as a CSV artifact during scoping with links to the parent Work Order (if present) and inventory lot. If the customer requires quality management post-migration, we recommend a dedicated QMS or a Dolibarr-compatible third-party quality module; this is documented in the gap assessment rather than migrated as live records.

Visibility ERP user accounts, role profiles, and security permissions migrate to Dolibarr Users. Role names are mapped to Dolibarr's permission set model (module-based read/write/delete flags). We extract user email, first name, last name, and active status from Visibility and create corresponding Dolibarr user accounts. Permissions requiring Dolibarr module activation (e.g., accounting, stock, project) are flagged as a module prerequisite in the migration scope. Users with no active Dolibarr equivalent are archived as inactive records in a reconciliation log.

Visibility ERP allows user-defined fields across most major objects, but the custom field schema is not exposed in any public API documentation. We request a custom field export during scoping — typically via a database-level query or a Visibility-supported report — and build a bespoke field map before any import begins. Dolibarr stores custom fields in llx_extrafields, and each extrafield must be registered in the Dolibarr database schema before an import populates it. Without this step, imports silently drop custom field values or write them into wrong columns, which is irreversible once migration is live.