Migrate from Astral Manufacturing ERP to Dolibarr ERP

Astral Customer and Vendor master records map to Dolibarr ThirdParty (societe) records with separate customer and supplier flags. We preserve the vendor code and payment terms from Astral as a Dolibarr code prefix (CUST_ or SUP_) and map contact name, email, phone, and address fields directly. The dedupe key is the Astral party code, which we store as the Dolibarr code field. If Astral uses distinct customer and vendor records with separate IDs for the same legal entity, we create two ThirdParty records in Dolibarr (one as customer, one as supplier) to preserve the separate audit trails.

Astral Items with Bill of Materials decompose into a Dolibarr Product record (the finished good) plus one or more BOM Recipe records (the manufacturing instructions). Each BOM line references a child Product record (the component) with a quantity-per-unit. Multi-level BOMs (sub-assemblies) require recursive decomposition into nested recipe structures. Purchased items without a BOM migrate as simple Product records with type Service or Product and no recipe. The hs_sku field maps to Dolibarr's ref field as the product code.

Astral Purchase Orders map to Dolibarr Fournisseur commande (supplier order). PO header fields (vendor reference, order date, delivery date) map directly; PO lines map to order line records with product reference, quantity, and unit price. Open POs at migration cutover migrate as validated orders with status set to pending receipt; closed POs migrate as historical records. Dolibarr's numbering sequence must be configured before import to accommodate the source PO numbering scheme, or we set the code manually during import using the source PO number.

Astral batch tracking records map to Dolibarr Stock product records with batch lot numbers tracked via the lot_id field if the Stock Another Number module is enabled. We migrate stock-on-hand quantity per product per warehouse, the batch serial number, and the warehouse location code. Open production orders at cutover may hold reserved stock that must be reconciled after production order migration completes; we flag any stock record linked to an unresolved production order for manual reconciliation before the customer accepts the migration output.

Astral Production Process records map to Dolibarr MRP Production orders. We map the production order header, linked BOM recipe reference, planned start and end dates, and status. Routing steps and custom operation-level tracking from Astral (including custom fields on production process records) require manual reconfiguration in Dolibarr's production order detail view. Custom quality checkpoint configurations migrate as extra field data on the production order but require threshold redefinition in Dolibarr's quality workflow settings.

Astral Sales Orders map to Dolibarr Commande client (customer order). Open orders at migration cutover migrate as validated orders ready for fulfillment; historical closed orders migrate with a status of billed and a migration flag in an extra field to prevent re-processing. Order line product references, quantities, and unit prices map directly. Dolibarr's order workflow (draft > validated > shipped > billed) must be configured to match the customer's post-migration order fulfillment process before migration begins.

Astral Payment Collection and Expense Management records map to Dolibarr Facture (invoice) records with status set to unpaid. We extract the outstanding balance, due date, and the linked party (customer for AR, supplier for AP). Payment history and bank reconciliation records are not independently stored in Astral as separate objects; they are derived from the ledger. We do not migrate closed or paid invoices as a standard scope item unless the customer specifies historical invoice archiving as a requirement, because importing closed invoices creates unnecessary record volume and can distort opening balances.

Astral Sales Invoices map to Dolibarr Facture records. Line-item product references, quantities, unit prices, tax amounts, and discount values migrate as structured invoice lines. PDF attachments (invoice documents stored in Astral) require separate document migration handling via Dolibarr's document management upload. Dolibarr's invoice numbering sequence must be pre-configured or manually assigned during import to match the source invoice numbering scheme, which must align with the customer's statutory numbering requirements.

Astral Quality Test records attached to production batches migrate as extra field data on the Dolibarr Production Order and Product records. Test result values (pass/fail, measured values) map to custom extra fields we define before migration. The threshold rules and pass/fail configurations that govern quality gates in Astral are destination-specific business rules that must be re-defined in Dolibarr as conditional workflow triggers or extra field validation rules. We document the source threshold configuration in the migration inventory for the customer's quality team to re-implement.

Astral User records with role assignments map to Dolibarr User accounts. We map the user login, email, and active/inactive status. Role-based permissions (shop-floor operator, supervisor, admin) map to Dolibarr's permission groups under Home > Setup > Users & Groups > Permissions. Any Astral permission that has no direct Dolibarr equivalent is flagged in the inventory for the admin to assign during post-migration access control configuration.

Astral custom fields added during implementation have no published extension API and must be identified via schema inspection during discovery. We map each identified custom property to a Dolibarr extra field on the corresponding object (ThirdParty, Product, Order, Invoice, etc.), defining the field type (text, int, double, select, date) to match the source data type. Dropdown-style custom fields require a corresponding dictionary entry in Dolibarr before the extra field can be created. We perform all extra field definition as a pre-migration configuration step before any data import begins.

Astral HRMS module employee records migrate partially to Dolibarr User records with core fields (name, email, department, employee code) mapped. Compensation history, PTO balances, leave records, and benefits data are not migrated because Dolibarr's HR module (if activated) does not store these as equivalent structured objects and the data represents a significant manual entry commitment. We flag these records in the migration inventory with a data-entry template so the customer's HR team can re-enter compensation and leave data post-migration.