Migrate from Foundry Bean to Dolibarr ERP

Foundry Bean's chart of accounts auto-categorizes accounts into Balance Sheet and Income Statement types. Dolibarr's accounting module requires explicit account type assignment (Actif, Passif, Charge, Produit) for each imported account. We map each Foundry Bean account code to a Dolibarr account number, preserving the account name and original categorization. Account type mapping is validated against Dolibarr's accounting plan structure before import to ensure the trial balance reconstructs correctly.

Foundry Bean customer records with addresses, contacts, payment terms, and invoice linkages map directly to Dolibarr Third-Party records with the Client category enabled. Payment terms migrate as Dolibarrcond_reglement_id values. Custom fields on Foundry Bean customers migrate to Dolibarr's CustomFields module where installed, or to supplementary record notes where no custom fields module is present.

Foundry Bean vendor master records containing addresses, banking information, purchase orders, and payable records map to Dolibarr Third-Party records with the Supplier category enabled. Banking information transfers to Dolibarr's rib (bank account) fields on the third-party record. Open purchase order history and payable aging data migrate as Dolibarr Purchase Order and Bill records respectively.

Foundry Bean sales invoices and subscription-generated invoices map to Dolibarr Customer Invoice records. We preserve the invoice-to-payment linkage so that payment status and aging data reconstruct in Dolibarr. Invoice status (Draft, Open, Paid, Void) maps to Dolibarr's pj and fp status fields. Line items with tiered pricing units map as individual invoice lines with explicit unit prices rather than as a linked pricing schedule.

Foundry Bean vendor invoices and approved expense report conversions map to Dolibarr Supplier Invoice records. The expense-report-to-vendor-invoice auto-conversion in Foundry Bean requires a deduplication step before import: we extract only the source expense report with its settlement state and suppress any duplicate vendor invoice record that would otherwise represent the same liability twice in Dolibarr.

Approved expense reports in Foundry Bean auto-convert to vendor invoices upon approval, but rejected or pending reports remain as standalone expense records. We export the expense report records in two passes: approved reports export once as Dolibarr Supplier Invoice records with settlement status preserved, and non-approved reports export as Dolibarr Expense Report records linked to the employee third-party. This prevents duplicate liability creation.

Foundry Bean subscriptions with flat-fee, usage-based, volume, or tiered pricing do not have a direct Dolibarr equivalent as a single object. We decompose each subscription into a recurring invoice template (for flat-fee and volume tiers) and individual invoice line items for tiered ranges. Nested tier rate definitions are flattened into discrete rate records during transformation. Any subscription relying on tier stacking is flagged for manual review before import.

Foundry Bean contract records linked to subscription billing and revenue recognition schedules map to Dolibarr Contract records. The contract-to-revenue schedule linkage is documented as a written record during migration because Dolibarr does not include a native ASC 606 recognition engine. Contract terms, start dates, end dates, and renewal flags migrate directly.

ASC 606 schedules in Foundry Bean are derived from contract terms and billing data rather than stored as independent records. We extract each schedule's milestone or time-based recognition rules, start date, end date, total recognized amount, and recognition method. Because Dolibarr has no native ASC 606 engine, we deliver a written schedule inventory document with all fields needed to configure recognition rules manually in Dolibarr or a compatible third-party module. We do not create live recognition schedule records in Dolibarr.

Foundry Bean purchase orders linking vendors to items map directly to Dolibarr Purchase Order records. We preserve the PO-to-invoice relationship so that received quantities and invoice matching reconstruct in Dolibarr's procure-to-pay workflow. Open and closed PO history migrates in full with status and receipt quantities.

Foundry Bean item records with multi-warehouse tracking, costing methods, and custom pricing tiers map to Dolibarr Product records. Item numbers map to ref, costing methods map to Dolibarr's cost price field, and warehouse assignments map to Dolibarr's stock location module if installed. Custom pricing tiers that reference nested rate ranges are flagged for transformation into explicit price list entries.

Foundry Bean employee records with compensation history, benefits, and organizational assignments map to Dolibarr User records if the HR module is not installed, or to Dolibarr Employee third-parties if the HR module is active. Effective-dated compensation changes require careful sequencing: we import the current employment state first, then apply historical compensation records in date order. Organizational hierarchy maps to Dolibarr's department structure where the HR module is present.

Foundry Bean bank and credit card accounts with real-time balance tracking and auto-reconciliation map to Dolibarr Bank Account records. Account numbers, bank details, and opening balances migrate directly. Reconciliation state is preserved as Dolibarr transaction records linked to the bank account.

All Foundry Bean journal entries from bank reconciliation, invoice processing, and manual entries stored chronologically migrate to Dolibarr accounting entries. We extract the full GL transaction history including adjustment entries, preserving debit and credit amounts, account references, and transaction dates. Opening balances for the migration date are established as a balancing journal entry before historical transactions are imported in date sequence.

Foundry Bean custom objects require explicit discovery before migration because they are not documented in a public API schema. We catalog every distinct custom object during discovery, map its fields to Dolibarr's CustomFields module (if installed) or to supplementary record notes, and create a written schema map for the customer to validate. Any custom object with lookup relationships to standard Foundry Bean objects requires parent-record resolution during import.