Migrate from metasfresh to Odoo ERP

metasfresh Business Partners (C_BPartner table) cover both customers and vendors with roles stored in the PartnerType property. We map vendor records to res.partner with type=supplier, customer records to res.partner with type=contact or type=company depending on whether the record has sub-contact entries. metasfresh contact persons stored in AD_User map to additional res.partner records linked via parent_id to the owning company partner. Bank account references stored in C_BP_BankAccount map to res.partner.bank_ids in Odoo. Address and location data from C_Location transfers to res.partner (street, city, country, zip). The is_customer and is_vendor boolean flags from metasfresh set the corresponding flags on res.partner. We preserve the metasfresh BPartner value (document number) as a reference field for audit traceability.

metasfresh products (M_Product and M_Product_Category) map to Odoo product.template with product.product variants when the metasfresh product has attribute values set. The M_Product_Category hierarchy becomes product.category in Odoo. Product codes (value) map to default_code, SKUs from the XLS export map to barcodes, and product types (item vs service) map to Odoo's type field (product vs service). If metasfresh uses multi-variant products via its attribute system, we split into product.template plus product.product variants in Odoo. Products without variants create a single product.product record with no variants. Stockable, consumable, and service product types all transfer directly.

metasfresh BOM data lives in pp_product_bom and pp_product_bomline tables, with dependencies on the MRP module that must be confirmed active during discovery. Each pp_product_bom record maps to Odoo mrp.bom with bom_line records for every component. The pp_product_bomline quantities_per_bom and is_active flags transfer to Odoo's product_qty and active fields. Component products are resolved to their Odoo product.product IDs before bom_line insert. We inspect the PP_Product_BOM table during discovery to confirm the MRP module is populated; BOM migration is skipped if the tables are empty. Work center and routing data (pp_order_bomrecord) maps to mrp.routing_workcenter if the metasfresh installation uses routings.

metasfresh orders span the C_Order header and C_OrderLine lines table with a document direction flag determining whether an order is a sales or purchase document. We split on that direction flag: sales orders map to Odoo sale.order with sol lines; purchase orders map to Odoo purchase.order with pol lines. Order document status (draft, in progress, completed, closed, cancelled) maps to Odoo's state field. Header-level financial terms (pricing list, payment rule, incoterms) transfer to the Odoo order header; line-level discount, tax, and quantity fields transfer to each order line. Completed and closed orders migrate as confirmed records; draft orders migrate as draft in Odoo. Order-to-order references (linking a purchase order to a sales order) are preserved as notes or via the Odoo procurement group if the customer activates the supply chain module.

metasfresh invoices are stored in C_Invoice (header) and C_InvoiceLine (lines) with a DocStatus flag that determines whether the record is a Customer Invoice (AR) or Vendor Bill (AP). We split on document type: AR invoices map to Odoo account.move with move_type=out_invoice, AP invoices map to move_type=in_invoice. Payment terms stored in C_PaymentTerm resolve to account.payment.term lines in Odoo. Tax lines in C_Tax are resolved to account.tax records in Odoo before invoice import so that tax_id lookups succeed. The invoice-to-order reference (C_Invoice.C_Order_ID) is preserved as a link to the corresponding Odoo sale.order or purchase.order. Historical invoices with DocStatus=CO (completed) and payment records in C_Payment are migrated together so that Odoo shows open or paid state accurately.

metasfresh pricing organizes into M_PricingSystem containing multiple M_PriceList versions with effective-from dates. Each M_PriceList maps to Odoo product.pricelist, and each M_PriceList_Version becomes a product.pricelist.version record linked to its parent pricelist. Price list item records (M_PriceListItem) map to product.pricelist.item with the original metasfresh price, surcharge, and discount percentage fields transferred to Odoo's base_price, price_surcharge, and percent_price. We order version inserts by effective date so that the correct price is active on the correct date in Odoo. Currency data from C_Currency maps to res.currency; the customer country pricing rules in metasfresh become Odoo country_id rules on the pricelist item.

metasfresh projects (C_Project header plus project lines tracking time, costs, and deliverables) map to Odoo project.project with project.task records for each project line. Project phases stored as C_ProjectPhase map to Odoo task records with the parent project reference. Milestones map to Odoo milestones if the Odoo project module version supports them. The owning Business Partner reference on the metasfresh project transfers as partner_id on the Odoo project. Project status, dates, and budget information migrate to project.project fields. Deliverables and costs stored in project line columns map to task description and task-level planned/actual hour fields.

metasfresh bank accounts stored per organization in C_BP_BankAccount map to res.partner.bank records in Odoo with the IBAN, SWIFT/BIC, and bank name fields transferred. Payment terms (net 30, net 60, 2/10 net 30) stored in C_PaymentTerm map to Odoo account.payment.term with line definitions matching the metasfresh discount days, discount percentage, and net days. These reference records must migrate before Orders and Invoices so that the payment term lookups are satisfied at insert time.

metasfresh tax configuration in C_Tax with country and effective date ranges maps to Odoo account.tax with the rate, tax_scope (sale vs purchase vs none), and applicable countries transferred. Tax groups from C_TaxCategory map to account.tax.group in Odoo. metasfresh uses taxIncludedInPrice flags that we translate to Odoo's price_include field on account.tax. Tax jurisdictions per geographic zone become Odoo tax.repartition.line records for the customer tax accounts if the Odoo country localization module supports it. We preserve effective-from dates so that the correct tax rate is active in Odoo on the correct date.

metasfresh customer complaints and repair workflows create service project records linked to returned products (C_Project with project category = service/repair). These migrate to Odoo helpdesk.ticket if the customer activates the Odoo Helpdesk module, or to project.project with a service task type if Helpdesk is not in scope. The link back to the originating sales order is preserved as a note on the ticket or project record. We flag this object as configuration-dependent and confirm the customer's Odoo app set during scoping.

metasfresh custom fields added via the Table and Column system are stored as rows in AD_Column with a custom flag. They are not surfaced in metasfresh's standard export format. We query AD_Column during the discovery phase to identify all custom fields per table and add them as additional columns to the export. In Odoo, we pre-create each custom field as ir.model.fields with the correct type (Char, Integer, Many2one, Selection, etc.) before the relevant object migration begins. The custom field identification and Odoo schema extension step adds approximately one to two days to the discovery phase.