Migrate from Kinetic to Dolibarr ERP

Kinetic Customer records map to Dolibarr llx_societe with Type = 'Customer'. The kinetic CustID becomes the ref (reference) field in Dolibarr; Customer.Name becomes the nominal field. Address, city, state/province, country, phone, and email map to Dolibarr address and contact fields. Payment terms from Kinetic (TermsCode) map to the Dolibarr cond_reglement field. Customer is migrated before any Sales Order records because the foreign key constraint on the order header requires a valid third-party ID.

Kinetic Vendor records map to Dolibarr llx_societe with Type = 'Supplier'. VendorID becomes ref. Multi-address vendor setups in Kinetic map to multiple Dolibarr address records under one third-party entry. Vendor payment terms and PO approval workflow assignments from Kinetic do not have direct Dolibarr equivalents; we preserve the terms code and flag any active approval workflows for manual reconfiguration in Dolibarr's Purchase workflow settings.

Kinetic Part records map to Dolibarr llx_product. PartNum becomes ref. TypeCode maps: 'M' (manufactured) and 'P' (phantom) map to Dolibarr type = '0' (product) with the manufactured flag set; 'P' (purchased) maps to type = '0'; 'S' (service) maps to type = '1' (service). Cost data from Kinetic's standard and last cost fields map to Dolibarr's cost_price. UOM translations require a UOM mapping table because Kinetic and Dolibarr use different internal UOM codes. Class and COMCAT behavior from Kinetic have no direct Dolibarr equivalent; we map class to a Dolibarr category where one exists.

Kinetic BOM records map to Dolibarr llx_product_nomenclature with the parent part as product_id and child lines as lines. Kinetic BOM revision and approval states are not tracked in Dolibarr's BOM nomenclature table; we preserve revision information in a custom field on the product record. If the source BOM has multiple revisions, we migrate the current active revision by default and flag others for manual handoff. Where Kinetic uses phantom assemblies for sub-boms, we translate the phantom flag to Dolibarr's is_pшефак type setting.

Kinetic Routings do not have a single Dolibarr equivalent. The routing operations and sequences translate partially to Dolibarr's MRP Work Order module (llx_mrp_production) as production lines, but Kinetic's step-level work-center assignments, labor estimates, and setup/cycle times are more granular than Dolibarr's default Work Order structure. We map routing operations to Dolibarr Project tasks under a manufacturing project, preserving operation sequence, work center reference, and estimated time. Customers requiring full routing fidelity should plan for a post-migration configuration pass in Dolibarr's MRP settings.

Kinetic Sales Order headers map to Dolibarr llx_commande with source = 'customer'. The order number maps to ref; OrderDate maps to date_creation; the ship-from site maps to the Dolibarr warehouse_id. Kinetic order types (e.g., standard, blanket) map to a Dolibarr input source or a custom field. Customer must be migrated and have a valid rowid before the Sales Order header can insert due to the fk_soc foreign key constraint.

Kinetic Order Details map to Dolibarr order lines (llx_commandedet) linked to the parent order. Quantity ordered and unit price map directly. Part number resolves to the Dolibarr product_id via the part number mapping created during the Product migration phase. Discount percentages from Kinetic map to the remise_percent field. Order Detail must load after the Order Header and after the Product catalog is present in Dolibarr.

Kinetic PO headers map to Dolibarr llx_commande_fournisseur. Vendor must exist as a Dolibarr third party before PO headers can insert. Kinetic PO approval workflow status (pending, approved, rejected) is preserved as an order status note; Dolibarr's workflow requires manual reconfiguration by the admin post-migration. Multi-site PO ship-to logic maps to Dolibarr's warehouse or address reference on the order.

Kinetic PO lines map to Dolibarr order lines with the same resolution logic as Sales Order lines — product_id resolved via the Part number mapping, quantity and price mapping directly. Unit of measure mapping applies here as well.

Kinetic Work Orders map to Dolibarr MRP production records. The JobNum becomes ref. Part must be migrated and have an active BOM in Dolibarr before the Work Order can link. Kinetic's work order status (released, in process, complete, closed) maps to Dolibarr's status field. JobNum generation rules from Kinetic's site configuration require a mapping table because Dolibarr generates production IDs differently. Open Work Orders migrate with their current status; completed or closed Work Orders migrate as historical records with a closed flag.

Kinetic Chart of Accounts records must load before any transactional records (invoices, payments, journal entries) because account numbers are referenced by every financial transaction. Kinetic's segment-based account structure (e.g., Division-Company-Account) maps to Dolibarr's chart of accounts format. Where Kinetic uses inter-company clearing accounts, we map to equivalent Dolibarr accounting account codes and configure the inter-company module if the customer activates it. The natural account vs statistical account distinction from Kinetic translates to Dolibarr's pcg_type field.

Kinetic Site records and their associated Warehouses map to Dolibarr llx_entrepot. Site-specific parameters (default warehouse, shipping calendars, inter-site transfer rules) do not have direct Dolibarr equivalents; we document these in a site-parameter handoff sheet for manual configuration in Dolibarr's warehouse and shipping modules. Multi-site configurations in Dolibarr may require the multi-company or multi-entity module activation for equivalent centralized visibility.

Kinetic Employee records map to Dolibarr llx_societe (if external) or llx_user (if internal system user). Internal employees who need Dolibarr system login credentials map to llx_user; the employee's name, email, and department map directly. Owner assignments on records (Sales Order, Work Order) require the Employee to exist in Dolibarr so that the assigned user record is valid at insert time. Effective-dated employee status changes are preserved as notes on the user record.

Open receivables migrate as Dolibarr customer invoices in draft or validated status depending on the invoice's current state in Kinetic. The customer, GL account, and payment terms must be present in Dolibarr first. We migrate the current open balance as the invoice amount and flag which records need payment-term recalculation after migration. Historical invoices that are closed in Kinetic do not migrate; only open items with an outstanding balance carry forward.

Open payables migrate as Dolibarr supplier invoices in draft or validated status. Vendor must be present as a Dolibarr third party before the invoice can link. The open balance migrates as the invoice amount. Approval workflow state from Kinetic is preserved as a note on the invoice; Dolibarr's supplier invoice approval workflow requires manual reconfiguration.

Kinetic UD Fields per tenant and per object do not map to a Dolibarr extrafield schema automatically. We discover the UD field metadata via the Kinetic API during discovery, document each custom field's name, type, and object association, then create an extrafield definition in Dolibarr for each one that the Dolibarr module supports. UD fields on Dolibarr objects that do not support extrafields are preserved in a migration handoff spreadsheet. Custom logic embedded in Kinetic UD Field behavior (calculations, defaults, validations) does not migrate and requires manual rebuild in Dolibarr.