Migrate from ERP BOS to Odoo ERP

ERP BOS customer records map to Odoo res.partner with partner_type set to contact or company. We preserve billing address, credit limit, account balance, and account status (active/inactive). Inactive accounts in ERP BOS are migrated with the active flag set to False in Odoo to prevent inflated customer counts. If ERP BOS stores branch-level customer accounts as separate records, we consolidate them under a single res.partner with Odoo's child contacts for branch tracking.

ERP BOS vendor master records map to Odoo res.partner with supplier_rank set to 1. Payment terms, tax registration numbers, and banking details migrate to res.partner bank accounts and property_supplier_payment_term_id. Address and contact person fields map to Odoo's street, city, country, and email fields.

ERP BOS Items cover both stockable and non-stock products. We map stockable items to product.product with type set to product and create product.template for the product definition. Non-stock items (services, materials) map to type set to service or consumable. SKU (item code) becomes product.default_code. Unit of measure and cost price migrate to uom_id and standard_price respectively.

Items in ERP BOS that carry multi-level Bills of Materials require a split into Odoo's product.template and mrp.bom models. ERP BOS BOM routing steps (work centers, operation sequences) are flattened into Odoo's single-level mrp.bom structure with mrp.routing/workcenter references. We extract the full BOM hierarchy during scoping, map each level to an Odoo mrp.bom record, and preserve the original BOM level as a custom field for audit. Multi-level BOMs that exceed Odoo's single-level model are flattened with a note in the mapping table indicating the original nesting depth.

ERP BOS hierarchical Chart of Accounts (account code, description, classification) maps to Odoo account.account with code, name, and user_type_id mapped to Odoo's account.account.type selection (asset, liability, equity, income, expense). We preserve account code structure for reconciliation continuity. Odoo requires company_id on each account, which means multi-entity ERP BOS deployments need a company record in Odoo created before COA migration begins.

ERP BOS entity-per-ledger structure maps to Odoo res.company records (one per ERP BOS entity) plus account.account records scoped to each company. Inter-company transactions (entity-to-entity journal entries in ERP BOS) are extracted as a separate reconciliation set. We map them to Odoo inter-company journal entries or mark them for elimination during Odoo consolidation setup. Customer-side finance review is required before finalizing elimination account treatment to prevent consolidated reporting errors in Odoo.

ERP BOS open AR invoices migrate to Odoo account.move with move_type set to out_invoice. Each line item becomes an account.move.line record with partner_id, account_id, debit/credit, and reconcile flags set to True for open items. Aged trial balance data migrates for reporting continuity. Before migration, we extract both the AR sub-ledger balance and the COA control account balance from ERP BOS and flag any discrepancy; the customer must reconcile in ERP BOS before we transfer open items.

ERP BOS open AP invoices migrate to Odoo account.move with move_type set to in_invoice. Line items follow the same mapping pattern as AR. Due dates, payment terms, and amounts are preserved. AP sub-ledger to control account reconciliation follows the same pre-migration flag-and-hold process as AR.

ERP BOS tax codes and rates map to Odoo account.tax with name, amount, and tax_type mapped to the Odoo tax configuration. Jurisdiction-based tax mapping is preserved. If ERP BOS uses compound taxes or tax groups, we decompose these into Odoo's account.tax.group structure.

ERP BOS bank and cash ledgers map to Odoo account.journal records with type set to bank or cash. Account balances reconcile against the last ERP BOS statement date. Bank account numbers become journal_code. We do not migrate historical bank transaction lines as individual journal entries; opening balances are set on the journal and the account to establish continuity.

ERP BOS Service Manager records (customer enquiries, opportunity tracking) migrate to Odoo crm.lead for pre-sale pipeline tracking or helpdesk.ticket for post-sale support records depending on record type. Open service records are associated with the migrated Customer (res.partner) via partner_id. Closed service records migrate with a closed state flag. The customer selects the target object during scoping based on whether they intend to use Odoo CRM or Helpdesk.

ERP BOS document management stores binary blobs (invoices, purchase orders, images, signed documents) linked to transactions. We extract document metadata (filename, document type, linked transaction reference) into a CSV index during migration. The binary files themselves require a separate file transfer process coordinated alongside the data migration but executed independently to avoid timeout issues with large attachment volumes. We produce a file-to-record mapping CSV that the customer's admin uses to reattach documents post-migration.