Migrate your Flectra data

Flectra's res.partner object holds both individual contacts and company records with standard fields (name, email, phone, address). The x_name field stores the display name and the parent_id field links contacts to companies. We map these directly to the destination CRM's Contact object using external identifiers.

Companies are a subtype of res.partner flagged by the is_company boolean. We preserve company-specific fields including website, vat number, and the child_ids relation back to individual contacts. The address fields (street, city, country) follow Flectra's multi-part address model and we flatten or restructure them as needed.

sale.order and sale.order.line represent the full sales pipeline. Flectra tracks order confirmed date, origin document reference, and line-level product/uom/qty/price data. We preserve the order-to-invoice linkage via the invoice_lines relation so the invoice history remains intact post-migration.

account.move with move_type='out_invoice' represents customer invoices. Flectra's payment state field (state_posted vs state_pending) does not map 1:1 to all destination ERPs; we explicitly map it to the destination's closest equivalent (e.g., 'Open' vs 'Paid'). Analytic accounting tags require field-level mapping per the customer's chart of accounts.

product.product (variants) and product.template (product master) form a two-level product model in Flectra. We extract both levels, preserving the template-to-variant relationship and attributes like list_price, standard_price, categ_id, and type (consumable/service/storable). UoM conversion rules from Flectra's uom.uom model are carried over.

purchase.order and purchase.order.line model the procurement side. We transfer vendor, order lines, and the picking linked via the picking_ids relation. Flectra's receipt status flags are mapped to the destination ERP's equivalent PO states.

project.project and project.task map to the destination PM tool. Flectra's task.stage_id, user_id (assignee), planned_hours, and effective_hours transfer directly. Sub-tasks are nested via the child_ids relation and we preserve the full hierarchy in the destination.

hr.employee holds the employee record with fields including department_id, job_id, work_email, and bank_account_id. We transfer employment details but note that salary/payroll history may reside in the payroll module (hr.payslip) which we handle separately as payroll records.

Flectra stores binary attachments (ir.attachment) with a res_model and res_id linking them to business objects. We export as base64-encoded files and re-attach in the destination by matching res_model to the destination object type and res_id to the new record ID. Custom attachment fields on custom models require additional mapping.

Flectra's ir.model.fields with state='manual' defines custom fields on any object. We enumerate all x_ prefixed fields during discovery and build a field map so the destination receives the same custom column and value data. Custom field types (selection, many2one, integer) are preserved individually.

Flectra's base CRM module uses crm_case objects and stage_id from crm.stage, but Pipeline Kanban boards are not a native Flectra feature in the Community edition. We do not migrate CRM pipelines from Flectra as there is no stable schema to map from; Leads and Opportunities are migrated as Contacts and Deals respectively.