Migrate from Grade to Dolibarr ERP

Grade's organizational records map to Dolibarr's llx_societe table. We discover the source column names during the schema discovery phase (mandatory before this mapping can be confirmed). Dolibarr stores the primary contact on each third-party record and supports separate contact sub-records on llx_socpeople. We use the Grade organization name as the nom (company name) field and infer the country code, VAT number, and postal address from any labeled Grade fields. Third parties must import before contacts because llx_socpeople.fk_soc references llx_societe.rowid.

Individual contacts from Grade map to llx_socpeople linked to a parent llx_societe record via fk_soc. We extract first name, last name, email, phone, and role/position from Grade. If Grade stores multiple contact roles per person, we create separate llx_socpeople records and use the llx_element_contact table to manage the many-to-many role linkage to Dolibarr objects (invoices, projects, orders). Dolibarr's contact type (customer, supplier, prospect) is set via the llx_socpeople.prospect, llx_socpeople.client, and llx_socpeople.fournisseur flags.

Grade products map to llx_product. We discover Grade's product fields (SKU, name, description, unit price, cost price, stock quantity) during the schema discovery phase. Dolibarr distinguishes products with stock tracking (type=0) from services (type=1). If Grade has a stock quantity field, we map it to llx_product.pmp (weighted average cost) and rely on Dolibarr's llx_product_stock table for actual stock levels. Product must exist before any invoice line items reference it.

Grade customer invoices map to llx_facture with faciture=0 (customer invoice, not supplier). We map invoice number to ref, issue date to datef, due date to date_echeance, and total amount to total_ht, total_tva, and total_ttc. The fk_soc field links to llx_societe.rowid. Line items migrate to llx_facturedet with fk_product resolved against the product table. Invoice status (draft, validated, paid, abandoned) maps to Dolibarr's fk_statut field (0-2 range).

Grade supplier invoices map to llx_facture_fournisseur. The same field mapping logic applies (datef, date_echeance, total_ht, total_tva, total_ttc) with faciture=1 flag. The fk_soc field links to the supplier's llx_societe record. Supplier invoice lines migrate to llx_facture_fourn_det with product references resolved. If Grade does not distinguish customer from supplier invoices, we flag this for customer confirmation during scoping.

Grade quotes or sales proposals map to llx_propal. We map quote number to ref, date to datep, expiry date to date_lim_reglement, and line items to llx_propaldet. The fk_soc links to the customer. Quote status (draft, sent, won, lost) maps to fk_statut (0-3). Dolibarr's proposal can be converted to an invoice directly; we flag this workflow option for the customer admin post-migration.

Grade customer orders map to llx_commande. We map order number to ref, order date to date_commande, expected delivery to date_livraison, and line items to llx_commandedet. The fk_soc field links to the customer. If Grade has purchase orders (supplier orders), these map to llx_commande_fournisseur with a separate import run and fk_soc pointing to the supplier third party.

Grade projects map to llx_projet with title, description, date_start, date_end, and budget amounts. We map the project status to fk_statut (0-2 for draft/active/closed). Tasks under a project map to llx_projet_task with fk_projet as the parent reference. If Grade stores task assignments, we resolve the assignee to llx_user.rowid via email matching. Dolibarr's project module must be enabled in Module setup before project data can import.

Grade contracts or subscriptions map to llx_contrat linked to llx_societe via fk_soc. Contract start date, end date, and terms migrate to the corresponding llx_contrat fields. Line items for recurring services migrate to llx_contratdet. Dolibarr's contract module tracks service line status (in progress, fulfilled, terminated) via fk_statut. The llx_contrat_extrafields table is available for any Grade custom contract fields discovered during schema analysis.

Grade expense records map to llx_expensereport for the report header and llx_expensereport_det for individual expense lines. Expense date, amount, category, and description migrate to the corresponding fields. If Grade expense records are standalone (not wrapped in a report), we create a single llx_expensereport per record and set status to validated. The linked llx_user.fk_user_author field is resolved via email matching against the Dolibarr user table.

Grade user accounts that represent employees or system operators map to llx_user. We resolve by email address as the dedupe key. The migration user (FlitStack AI's service account) is created in Dolibarr before any data import begins to serve as the fk_user_author on audit fields. Grade users that are purely contact records (no system login) are mapped to llx_socpeople instead. The customer's Dolibarr admin provisions the active user accounts post-migration if Grade user data is incomplete or the password hashes cannot be imported.

Grade's undocumented custom objects require discovery before mapping. We inspect the Grade database for tables not matching standard ERP naming conventions, identify foreign key relationships, and either map them to existing Dolibarr modules (Projects, Contracts, Orders) or create a Dolibarr custom table. Custom fields on standard objects (e.g., extra fields on invoices) use Dolibarr's llx_extrafields tables with the pattern llx_[object]_extrafields. The migration does not include custom module code from Grade; only the data migrates if the module structure can be reverse-engineered.