Migrate from Pronto Xi to Dolibarr ERP

Pronto Xi GL account hierarchies use a hierarchical code system stored in IBM Informix. We extract account codes, descriptions, and parent-child relationships via direct DB queries, preserving the full accounting tree. Dolibarr's Accounting Account object stores account codes, labels, and parent references. Account type mapping (asset, liability, equity, revenue, expense) transfers from Pronto Xi category codes to Dolibarr pcg_type values. Account reconciliation flags and bank account indicators map to Dolibarr reconcilable and bank fields.

Pronto Xi Customer records include address books, payment terms, tax codes, and credit limits. Dolibarr consolidates Customer and Supplier into a single Third Party object with a client/prospect/supplier type flag. We map Pronto Xi customer addresses to Dolibarr address records, payment terms to the terms field, and tax codes to the Tiers模式和 tax identification. Credit limits require a custom Extrafield in Dolibarr since the field is not native.

Pronto Xi Supplier records map to Dolibarr Third Party with type = Supplier. Supplier-specific fields including account codes, lead times, and preferred carriers map to Dolibarr Extrafields since standard Third Party does not capture these natively. Multi-address supplier locations require careful address record deduplication during import.

Pronto Xi items include BOM references, cost layers, reorder points, and multi-warehouse location assignments. We extract item masters and current stock quantities per location. Dolibarr's Product object handles both goods and services; inventory tracking requires activating the Stock module. Multi-warehouse quantities map to Dolibarr warehouse-specific stock entries, and cost layers require Extrafields since Dolibarr tracks a single cost price per product. BOM associations require separate handling through the Project or Bill of Materials approach.

Pronto Xi BOMs store component items, quantities per assembly, and revision versions tied to manufacturing processes. Dolibarr has no native BOM or manufacturing module. We evaluate whether to use Dolibarr's third-party BOM module (available from the Dolibarr MarketPlace) or to map BOMs as Products with kit/assembly flag plus associated component relationships. The customer chooses the approach during scoping based on whether they actively use manufacturing routing and work order tracking post-migration.

Pronto Xi Work Orders carry routing steps, labor allocations, and component consumption records tied to specific BOM versions. Dolibarr has no direct Work Order object. We map active and historical Work Orders to Dolibarr Projects with Tasks representing individual routing steps, and component consumption as task notes or custom line items. Closed Work Orders migrate as read-only Projects. Customers relying on active manufacturing execution should plan to use a third-party manufacturing module or accept a process change.

Open receivables require careful sequencing. We extract open invoices and credit memos with aging buckets and reference numbers before triggering the final period close at source. At Dolibarr destination, we create Customer Invoice records in Draft or Validated status matching the original document state, then apply payments or credit allocations in chronological order to maintain clean aging reports. Payment terms, discount percentages, and late fee flags transfer from Pronto Xi terms records.

Open payables migrate as Supplier Invoice records in Dolibarr, with the same sequencing approach as AR: extract all open AP before source period close, create supplier invoices at destination in matching statuses, then apply payments or credit notes in chronological order. Bank account details on supplier records require Extrafield mapping since Dolibarr stores these at the third-party level.

Pronto Xi Sales Orders include line items with pricing, discounting, and delivery scheduling. We extract order headers and lines, then set Dolibarr order statuses based on fulfillment progress to avoid inadvertent invoice generation. Shipping address maps to the delivery address field, and order-level discounts map to the discount field. Open orders carry forward; completed or cancelled orders migrate as historical records with locked status.

Pronto Xi Purchase Orders map to Dolibarr Supplier Order. Line items transfer with quantities, unit prices, and discount rates. Expected delivery dates map to the delivery date field. Status mapping handles the Pronto Xi order lifecycle (entered, approved, received, invoiced) against Dolibarr order statuses (Draft, Validated, Approved, Sent, Received, Closed).

Linked documents stored in Pronto Xi's document management system require extraction via file references or direct DB blob access. We handle file naming conventions and preserve document associations by creating Dolibarr document directory entries and linking them to the relevant Third Party, Product, or Project record. Dolibarr's document storage uses a flat directory structure per object type, which requires flattening any nested Pronto Xi folder hierarchies during migration.

Pronto Xi environments frequently contain bespoke modules built on the SDK or RAD framework with no direct Dolibarr equivalent. We identify each bespoke module during scoping, extract their data structures, and map field values to Dolibarr ExtraFields on the relevant standard objects. Any module with no clear destination object is flagged in the handoff document with a recommendation (rebuild as Dolibarr module, archive as reference data, or recreate manually). The customer decides the fate of each orphaned module during scoping.

Pronto Xi payroll data is sensitive and often edition-gated. Dolibarr's HR module handles employee records, leave management, and expense reports. We extract employee name, contact details, and pay category information, mapping to Dolibarr User records with HR module activation. Historical salary data and detailed compensation history require ExtraFields since Dolibarr HR is not a full payroll system. We flag any regulatory or compliance-specific fields (Australian tax file number fields, superannuation codes) for manual verification.