Migrate from Embrace ERP to Odoo ERP

Embrace account codes, descriptions, and hierarchical structure map directly to Odoo's account.account model with type, parent_id, and tags. We extract the full account tree from Embrace and create corresponding Odoo accounts before any transaction data lands. Any account codes that conflict with Odoo's reserved code ranges (view, receivable, payable, bank, cash, credit) are prefixed or remapped during the transform phase. South African statutory account types are mapped to Odoo's account.group structure for balance sheet and income statement categorization.

Embrace's SARS-compliant tax codes and rate tables map to Odoo's account.tax records with the correct tax_scope set to Sale, Purchase, or None. We extract all active tax codes with current effective rates from Embrace and create Odoo taxes with the same name and percentage before any invoices are imported. Any compound tax configurations (e.g., VAT inclusive pricing splits) are noted for manual review and rebuilt as Odoo tax groups.

Embrace customer master records (billing address, contact details, tax registration number, payment terms) map to Odoo res.partner with customer_rank set to positive so the record appears in the customer list. Tax registration fields from Embrace (VAT number, company registration) migrate to the partner's tax_id field. Payment terms migrate to account.payment.term and are linked via property_payment_term_id on the partner.

Embrace vendor master records mirror customer structure with supplier-specific fields (banking details for payment configuration, supplier catalog references) and map to Odoo res.partner with supplier_rank set to positive. Banking details from Embrace are stored in a dedicated contact bank account (res.partner.bank) linked to the vendor partner. Vendor payment terms migrate to account.payment.term and are linked via property_supplier_payment_term_id.

Embrace inventory items (stock codes, costing methods, warehouse locations, reorder parameters) map to Odoo product.product with type = product_type set to storable. Stock code becomes the product's default_code. Costing method (standard, average, FIFO) migrates to Odoo's costing_method field on the product category. Reorder parameters migrate to product.rule records for low-stock rules if Odoo's manufacturing or inventory module is active.

Embrace BOM hierarchies and variant structures map to Odoo's mrp.bom records with type = normal or kit depending on the source structure. Component items resolve to product.product references already imported in the product phase. Routing dependencies (work center sequences, cycle times) migrate to mrp.workcenter and mrp.routing records if present in Embrace. BOM mapping requires the manufacturing module to be active in Odoo; if the customer does not activate it, BOM data is delivered as a structured inventory document for manual entry.

Embrace outstanding AP items (unpaid vendor invoices and credit notes) migrate to Odoo account.move with move_type = entry and a matching vendor bill journal entry. We extract the full aging detail (invoice date, due date, amount, partial payment history) and create Odoo bills in draft state so the customer's AP team can post them after verifying against source documents. Partial payments already processed in Embrace reduce the outstanding balance migrated.

Embrace outstanding AR items (unpaid customer invoices and credit notes) migrate to Odoo account.move with move_type = entry and a matching customer invoice journal entry. We extract aging detail with invoice date, due date, amount, and partial payment history, and create Odoo invoices in draft state for the customer's AR team to post after reconciliation. Any credit notes linked to open invoices are migrated as related entries so that the AR aging report reflects net outstanding correctly.

Embrace user-defined fields on master and transaction records vary between installations. We discover the complete custom-field schema during scoping (field name, data type, assigned object) and create matching Odoo custom fields using ir.model.fields before any data import. Any fields with unsupported data types (e.g., bespoke picklist values not documented in the base schema) are flagged for manual review before final import. Custom field values migrate as mapped property fields on the relevant Odoo model.

Documents linked to transactions or master records in Embrace's document management layer are extracted via the accessible file export path and imported as ir.attachment records in Odoo linked to the corresponding res.partner, account.move, or stock.move via res_model and res_id. Any documents stored in non-standard paths or with proprietary formats that cannot be reached via the file export are flagged for manual migration and documented in the handoff report.

Embrace user accounts and role-based permissions are extracted and mapped to Odoo's res.users and ir.model.access records. We export role definitions as structured records and flag any permission sets that do not have a direct Odoo equivalent (e.g., module-restricted access in Embrace). Active and inactive user status is preserved. Passwords do not transfer; the customer's admin provisions new Odoo credentials post-migration.

Workflows defined in iMBrace or the native Embrace workflow engine governing approval chains are exported as structured rule definitions and delivered as a written inventory for the customer's admin to rebuild in Odoo Studio or as Python server actions. We do not migrate workflows as executable code because Odoo's action-trigger model differs from Embrace's workflow engine. The inventory document lists each workflow's trigger, conditions, approvers, and recommended Odoo Studio equivalent.