Migrate from Proteus E12ERP to Dolibarr ERP

Proteus E12ERP Customer records map to Dolibarr ThirdParty objects with type=T. We extract customer name, address fields, contact phone, email, and GST/tax identification from the delimited export. Dolibarr stores third-party addresses in the llx_socpeople table linked to llx_societe; we resolve the contact-to-third-party relationship at migration time. Any lifecycle or stage property from Proteus maps to a Dolibarr extrafield or category.

Proteus E12ERP Vendor records map to Dolibarr ThirdParty objects with type=F (fournisseur). We extract vendor name, contact details, and payment terms. Dolibarr requires the Supplier module to be activated before vendor objects are accessible; we verify module activation during the configuration step. Vendor ID references from Purchase Orders are resolved by creating vendors before purchase order records.

Proteus E12ERP Inventory Items with SKU, description, unit cost, and quantity on hand map to Dolibarr Product records. We distinguish between product types: items with stock tracking map to Dolibarr type=0 (stockable), service-only items map to type=1 (service). Quantity on hand migrates as an initial stock value into llx_product_stock with the relevant warehouse reference. Dolibarr requires the Stock module to be activated for warehouse tracking to function.

Proteus E12ERP Sales Orders map to Dolibarr Customer Order objects (commande client). The Proteus order status (open, dispatched, closed) maps to Dolibarr Statut values (0=draft, 1=validated, 2=shipped, 3=delivered, etc.). Line items map to llx_commandedet with Product references resolved via SKU lookup, and order totals compute from quantity multiplied by unit price. We preserve the customer reference and order date.

Proteus E12ERP Purchase Orders map to Dolibarr Supplier Order objects (commande_fournisseur). Vendor ID references resolve to the Dolibarr ThirdParty supplier created in the vendor migration step. PO status (open, received, closed) maps to Dolibarr Statut values. Line items map to llx_commandedet_fournisseur with Product references resolved by SKU. Receipt of goods workflow in Dolibarr (reception against purchase order) is documented separately as a post-migration procedure.

Proteus E12ERP Revenue Centers represent branches or cost centres in a multi-location setup and are a non-standard ERP concept. We map each Revenue Center to a Dolibarr Project with the project type set to internal or customer-facing as appropriate. Cost-centre categorization within Dolibarr's accounting module requires the accounting module to be activated and may need account-level cost-centre configuration by the customer's admin post-migration. This is the highest-complexity object mapping in the pair because Revenue Centers have no native Dolibarr equivalent.

Proteus E12ERP Chart of Accounts records with account codes and types map to Dolibarr's accounting module llx_accounting_account. Account type (asset, liability, income, expense) maps directly. Currency denomination from Proteus migrates to Dolibarr account currency fields if multi-currency accounting is enabled. Dolibarr's accounting module must be activated before importing chart-of-accounts records; the first account in each class acts as the class header in Dolibarr.

Open invoice state (unpaid purchase orders and outstanding customer invoices) is not documented as an exportable object in Proteus E12ERP's CSV evidence. We cannot migrate open AP or open AR as a direct record load. We flag this gap in the migration scope and recommend that customers export open invoice data manually from Proteus reports and re-enter them as draft invoices in Dolibarr's invoice module post-migration, setting the status to unpaid with the original due date preserved. This is a manual step outside the automated migration scope.

Proteus E12ERP call logs and meeting records map to Dolibarr Agenda events (actioncomm). Call duration, date, and outcome map to Dolibarr fields daterun, duration, and note. Dolibarr's Agenda module must be activated before event records load. Attendee and participant associations from Proteus map to Dolibarr's llx_actioncomm_resources table. Note that Dolibarr's recurring event feature has known limitations per community reports; we document this as a post-migration configuration note.

Email content and thread history exported from Proteus E12ERP migrates to Dolibarr Note records (note) linked to the relevant ThirdParty or Order via llx_element_contact. Dolibarr stores email attachments as Document records in the llx_document_model table linked to the parent element. We preserve the original email date, sender, recipient, and body. Dolibarr does not have a native threaded email object; thread ordering is preserved by date sequence in the linked Note records.

Task records from Proteus E12ERP including task title, description, due date, status, and assigned owner map to Dolibarr Actioncomm records with type=TASK. Owner assignment in Proteus maps to the corresponding Dolibarr User by email match. Tasks linked to specific Customer or Order records resolve their llx_element_element foreign key during migration by looking up the target record by reference.

If the Proteus E12ERP export exposes pre-confirmation sales proposals (quotes or estimates prior to order conversion), these map to Dolibarr Commercial Proposal objects (propal). Proposal status (open, accepted, rejected) maps to Dolibarr Statut values (0=draft, 1=opened, 2=signed, 3=not signed). The customer reference, line items, pricing, and validity date migrate. Dolibarr allows proposals to be converted to Orders; we note this for the customer's admin to execute post-migration.

An alternative mapping for Proteus E12ERP Revenue Centers where the customer's Dolibarr setup uses the HR module's Department object rather than Projects. We determine the correct target during discovery based on how the customer uses Revenue Centers in Proteus: branch representation maps to Departments, cost-centre accounting maps to Projects. Dolibarr's HR module must be activated for the Department object to be available.

Any custom fields defined in Proteus E12ERP for standard objects migrate as Dolibarr ExtraFields on the equivalent target object. ExtraFields are defined via Dolibarr's modulebuilder or extrafields interface and require the relevant Dolibarr module to be activated. Custom fields on objects with no Dolibarr equivalent are documented as part of the migration scope and require manual schema creation in Dolibarr before data load. We do not create Dolibarr custom PHP modules as part of the standard migration scope.

Product category or classification hierarchies from Proteus E12ERP map to Dolibarr Category records with type=0 (product category). Category assignments on individual products migrate as llx_categories_products links. Dolibarr's Category module must be activated before importing categories.

If Proteus E12ERP manages multi-currency vendor or customer records, the currency codes and any stored exchange rates map to Dolibarr's multi-currency accounting configuration. Dolibarr's multi-currency module must be activated. Exchange rates are stored as a reference table in Dolibarr and may require manual update or an external rate provider integration post-migration. This mapping is conditional on Proteus exposing currency fields in its export.

Document references and file attachment paths exported from Proteus E12ERP map to Dolibarr Document records linked to the parent object (ThirdParty, Order, Product, or Project). We preserve the original filename, file type, and upload date. Actual file content (PDFs, images, spreadsheets) migrates as binary data into Dolibarr's documents directory structure. The migration process requires read access to Proteus's document store and write access to Dolibarr's document directory.