Migrate from proALPHA ERP to Dolibarr ERP

proALPHA treats Customers as distinct business partner records with address, contact, classification, and payment-term data. We map these to Dolibarr Third Party records with the Type set to Customer. The proALPHA partner code becomes Dolibarr's customer code. We resolve multi-address structures by creating Dolibarr contact addresses linked to the Third Party. Payment terms, credit limits, and price level assignments from proALPHA map to Dolibarr's Term, CondReglement, and LocalTax columns on the Third Party.

proALPHA Vendors map to Dolibarr Third Party with Type set to Supplier. The proALPHA vendor code maps to Dolibarr's supplier code. We preserve vendor-specific payment terms and bank details from proALPHA's vendor record into Dolibarr's supplier setup. If the same partner record in proALPHA serves both customer and vendor roles, we create two Dolibarr Third Party entries (one of each type) linked by the original partner identifier.

proALPHA Items include the product master with BOM, routing, variant configuration, and unit-of-measure data. We map Item number to Dolibarr Product ref, description to label, and unit of measure to unit. Unit price from proALPHA's sales price or purchase price conditions map to Sell price and Buy price on the Dolibarr Product. Variants handled via proALPHA's product configurator are decomposed into individual Product variants in Dolibarr with the configuration reference stored in a custom field.

proALPHA multi-level BOMs (parent assemblies with nested sub-assemblies and components) require decomposition for Dolibarr's flat BOM model. We flatten the hierarchy: the top-level finished good becomes a Dolibarr Product with type 'assembly', and each component at every level becomes a separate Product with type 'product' or 'assembly' as appropriate. The top-level BOM relationship is stored using Dolibarr's BOM module (if enabled) with quantities and unit-of-measure per component. We flag any BOM routing data tied to APS scheduling constraints as notes requiring manual work-center reconfiguration in Dolibarr.

proALPHA maintains a structured COA with cost center and department assignments. The standard export maps cleanly to Dolibarr's accounting module account structure. We verify account types (asset, liability, equity, expense, revenue) against Dolibarr's account type taxonomy and flag any proALPHA cost-center-specific accounts that have no direct Dolibarr equivalent. The customer configures the target chart of accounts in Dolibarr before migration using the accounting module's import tool.

proALPHA journal entries (G/L postings) map to Dolibarr accounting entries of the corresponding type (sale, purchase, payment, general). Each line in a proALPHA journal entry becomes a separate line in the Dolibarr accounting entry. We validate that debit and credit totals balance before importing into Dolibarr; entries that do not balance after mapping are held in a reconciliation queue. Historical journal entries are scoped by fiscal year during discovery, and entries older than the agreed retention cutoff are archived as flat CSV exports rather than imported into the live accounting ledger.

proALPHA fixed asset records include acquisition cost, depreciation schedules, useful life, location assignments, and asset class. We map these to Dolibarr's Asset module (if enabled) with acquisition date, acquisition value, and depreciation method preserved. Proalpha's depreciation method (linear, declining balance, sum-of-years-digits) maps to the corresponding Dolibarr Asset amortization type. Any proALPHA asset linked to a specific cost center or department requires the equivalent Dolibarr project or warehouse assignment to be configured before import.

Outstanding payables and receivables in proALPHA carry payment terms, due dates, and partial allocations. We extract open items at a fixed extraction timestamp and map them to Dolibarr Supplier Invoice (unpaid) or Customer Invoice records. The open item status (partial, full) and remaining amount are preserved. We do not replicate proALPHA's payment allocation engine; the customer reconciles payments against open invoices post-migration using Dolibarr's payment recording workflow.

proALPHA work orders include operation sequences, work center assignments, and scheduling constraints tied to APS. Dolibarr's manufacturing module (if enabled) supports basic production orders but lacks APS-level scheduling, bottleneck detection, and alternate resource suggestions. We extract work order status, material allocations, and backflush records, and map them to Dolibarr Project with manufacturing-linked tasks. APS-specific scheduling data is flagged as out-of-scope and documented for the customer's admin to reconfigure manually in Dolibarr or an external scheduling tool.

proALPHA inventory records span multiple sites with stock quantities, locations, and lot/serial numbers. We map site-level warehouse data to Dolibarr warehouses created per proALPHA location. Stock quantities per item per warehouse migrate as Dolibarr stock movements. Lot and serial number tracking migrates if Dolibarr's lot/serial module is enabled; otherwise we store the lot reference in a custom field on the Product for traceability.

proALPHA supports custom fields per module, but naming conventions and data types vary by customer instance. We document every custom field encountered during the discovery scan, map each to a Dolibarr Extrafield with the equivalent data type (string, integer, select, date, checkbox), and preserve the original proALPHA field name as a label note. Custom fields without a direct Dolibarr type equivalent are migrated as string and flagged for the customer to refine post-migration.

proALPHA's integrated document management stores binary files linked to business objects (Customers, Items, Work Orders). The documents themselves require a separate extraction operation because standard data export does not include binary attachments. We extract document metadata (filename, file type, linked object, creation date) and perform a parallel file transfer to a Dolibarr-accessible file location, then create Dolibarr document links referencing the transferred files. We flag any binary files that cannot be matched to a Dolibarr object for manual handoff.