Migrate from Achiever Technology to Dolibarr ERP

Achiever Technology's customer and vendor records map to Dolibarr's ThirdParty object (llx_societe), with a Tiers_type field distinguishing Client from Supplier. Extensive custom fields for regional compliance and trade documentation migrate to Dolibarr's extrafields system (llx_extrafields) or the CustomFields module (llx_customfields_cases). We preserve all associated addresses (llx_societe_address), contact persons (llx_socpeople), and credit terms. Bank account details migrate to llx_societe_bank. If Achiever uses separate tables for customers and vendors, we consolidate into a single ThirdParty table with type filtering.

Achiever Technology stores account structures tailored to Hong Kong and Mainland China chart layouts, often including multi-segment accounts (e.g., company-department-account). Dolibarr's accounting module uses a flat chart of accounts (llx_accounting_account) with mandatory account number, label, and category fields. We split multi-segment Achiever accounts into individual segments mapped to Dolibarr's account structure, flagging multi-segment conventions in the mapping notes. Account categories (asset, liability, equity, revenue, expense) map to Dolibarr's chart of accounts category system.

Open invoices and credit notes must migrate with payee/receivable linkage intact to preserve aging reports and payment processing continuity. We extract open invoice headers and line items, resolve the supplier/customer ThirdParty reference, and map to Dolibarr's llx_facture (customer invoices) or llx_facture_fourn (supplier invoices). Payment terms and due dates transfer to llx_paiement_facture and llx_paiement. We sequence the cutover to avoid duplicate postings in open periods, and freeze the Achiever system to a cutover date before final delta extraction.

Ledger history in Achiever Technology is stored in customer-specific formats that may include accrual reversals, intercompany entries, and localized journal line conventions. We extract complete journal lines (date, account number, debit, credit, narrative, reference) and map to Dolibarr's llx_accounting_bookkeeping table, which stores all accounting entries for the double-entry ledger. If Achiever stores period/year data separately, we consolidate into a continuous journal. Dolibarr requires the accounting module to be activated and a chart of accounts to be configured before journal import.

Bank account masters and cash GL accounts migrate with standard mapping. We extract bank account identifiers, names, currencies, and initial balances from Achiever's bank module and map to llx_bank and llx_bank_account. Opening balances are reconciled against the source trial balance before cutover. Bank statement lines (llx_bank_line) migrate if historical statements are available, enabling reconciliation continuity in Dolibarr.

Hong Kong and China tax codes including GST/VAT, withholding tax rates, and deferred tax configurations require mapping to Dolibarr's jurisdiction-specific tax engine. We preserve effective dates and rate values, and configure Dolibarr's VAT collection account and payment account per tax code. Note that Dolibarr's native VAT handling is oriented toward EU VAT; Hong Kong companies using Dolibarr typically configure the system without VAT or with custom tax modules. We flag any Achiever-specific tax logic that requires custom calculation rules in Dolibarr.

HRM records including employee profiles, compensation history, and organizational hierarchy migrate into Dolibarr's User table (llx_user) and, if the HR module is activated, into the Contracts (llx_contrat), Leaves (llx_holiday), and Expenses (llx_expensereport) modules. We handle effective-dated compensation rows, preserving salary, bonuses, and deductions as separate expense report entries or as llx_user entries with custom extrafields. Department and reporting hierarchy map to Dolibarr's hierarchical User reporting structure (llx_user where fk_user_supervisor references the manager). Active and inactive status transfers directly.

Project accounting data including budgets, WBS structures, and cost allocations require field-level mapping to Dolibarr's project module (llx_projet) and, if the Task module is active, to llx_projet_task. Custom project statuses are translated to Dolibarr's status enumeration (Open, Closed, Archived). Budget data migrates to llx_projet_budget_line if the budget extension is available, otherwise we document the budget figures for manual entry post-migration. Cost center assignments map to Dolibarr's project-level cost tracking or to the accounting dimension system if configured.

If Achiever Technology includes inventory management, product records migrate to Dolibarr's llx_product table with type distinction between Stockable, Service, and Product variants. Unit of measure, barcode, and price lists map to llx_product_price. Stock levels transfer to llx_product_stock with warehouse assignment. If Achiever uses multi-warehouse, we create multiple llx_entrepot records and distribute stock accordingly.

Open and historical purchase orders migrate to llx_commande_fournisseur; sales orders migrate to llx_commande. Order status transfers to Dolibarr's status enumeration (Draft, Validated, Approved, Shipped, Closed). Line items carry product references, quantities, unit prices, and discounts. If Achiever stores order-specific notes or approvals, these transfer to llx_element_element links or to the order's description field.

Documents stored within Achiever Technology's file management layer are exported by file path and reattached to the corresponding records in Dolibarr. We preserve original filenames and associations by matching document paths to migrated record IDs (e.g., invoice number to llx_facture). Dolibarr stores documents in /documents/ with subdirectories by module. We restore the directory structure and register files in llx_ecm_files for Dolibarr's document indexer.

Because Achiever Technology builds bespoke modules per-customer engagement, custom objects have no standard schema. We do not migrate these without a pre-migration schema discovery session where the customer provides a full list of all custom modules, fields, and workflow states in use. For each discovered bespoke module, we assess whether it can be mapped to a standard Dolibarr module (CRM, Project, HR, etc.) or requires a custom Dolibarr module built post-migration. We deliver a written schema inventory and a custom module development scope for the customer's PHP developer or a Dolibarr integration partner.