Migrate from Epicor BisTrack to Odoo ERP

BisTrack Customer records map directly to Odoo res.partner with partner_type=contact. The Customer Number field becomes Odoo's internal reference (ref). Address fields (street, city, state, zip, country) map to Odoo's address fields. We extract pricing tier and credit limit from BisTrack Customer Maintenance and populate Odoo's pricelist assignment and credit_limit fields. If a default salesperson is set in BisTrack, we map it to Odoo's user_id on res.partner.

BisTrack Vendor records map to Odoo res.partner with partner_type=supplier. Vendor-specific fields including PO terms, lead times, and EDI settings migrate to Odoo's purchase_order_route, property_supplier_payment_term, and custom vendor fields. EDI trading partner IDs are stored in a custom field on the partner record for integration rebuild. When a default customer is not set in BisTrack, we coordinate with the customer to assign a default buyer's contact during migration.

BisTrack Item master records map to Odoo product.product. SKU becomes product.default_code; description becomes name. Bin location migrates to Odoo's warehouse.location_id structure, which we pre-configure per the customer's warehouse hierarchy. Kit assembly rules (Bill of Materials in BisTrack) map to Odoo mrp.bom records with BOM type=kit. The Max Description Length setting in BisTrack (default 254 chars) may truncate item descriptions; we flag any items with descriptions exceeding Odoo's name field length during the pre-migration audit.

BisTrack Sales Order headers and lines map to Odoo sale.order and sale.order.line. Special order SKUs generated with the DefaultSKU prefix pattern (e.g., zz_SOWINDOWS_0001) are resolved against the product.product records we created during Item migration; we suppress auto-generation during import to prevent SKU conflicts. Line-level pricing, back-reference to the customer (res.partner), and order status (open, closed, cancelled) migrate directly. We sequence Sales Order import after res.partner and product.product to satisfy foreign-key constraints.

BisTrack PO records extract via Smart View SQL and map to Odoo purchase.order and purchase.order.line. Line items reference Vendor (res.partner, supplier type) and Item (product.product), so we load Vendors and Items before POs to maintain referential integrity. PO terms and expected delivery dates migrate to Odoo's date_planned and order_line fields. If the PO references a blanket order in BisTrack, we create an Odoo blanket purchase agreement as the parent document.

BisTrack Quotes accessible via API and the outside sales module map to Odoo sale.order records with state=draft. Quote status, expiration dates, and conversion history are preserved in custom fields (quote_validity_date, quote_status, converted_to_order_id). Quoted line items reference current item pricing from the product.pricelist. We flag any quotes with expired dates for customer review before import.

BisTrack inventory levels, bin locations, and on-hand quantities per warehouse map to Odoo stock.quant records. Each unique bin location in BisTrack becomes a location_id within the customer's warehouse location hierarchy in Odoo. We extract via Smart View SQL and map to the stock.quant table with product_id, location_id, quantity, and reserved_quantity. Stock history (valuation layers) is available but may require additional transformation if the customer needs full valuation trail; we scope this during pre-migration audit.

BisTrack AR invoices and payment records migrate to Odoo account.move with move_type=out_invoice and related out_payment records. The invoice-to-payment reconciliation (reconciled boolean on account.move.line) is computed during import. Open invoices import as draft for customer review before posting; paid invoices import as posted. We extract via Smart View SQL and map to Odoo's account.move and account.move.line structure.

BisTrack AP data including vendor invoices and payment records map to Odoo account.move with move_type=in_invoice and related in_payment records. Duplicate invoice controls native to BisTrack are flagged during import scoping to avoid re-triggering duplicate detection in Odoo (Odoo does not have an equivalent built-in; we document the check for the customer's AP team to review post-migration). Vendor invoice numbers map to Odoo's ref for cross-reference.

BisTrack GL accounts accessible via Smart View map to Odoo account.account records. Account numbers and hierarchies migrate directly. Segment structures (e.g., department cost centers) may require mapping to Odoo's analytic accounting model if the customer uses cost center segmentation. We note any multi-segment account structures during pre-migration audit and discuss whether analytic accounts or a separate dimension are appropriate for the customer's reporting needs.

BisTrack user-defined fields (UD codes) with per-field user-level security via Field Security Maintenance extract as field definitions and data. We pre-create equivalent custom fields in Odoo (ir.model.fields with groups restriction matching the source security model), then migrate the data. UD code field types (text, numeric, date, picklist) are mapped to Odoo field types (char, float, datetime, selection). Custom field metadata is documented in the handoff data dictionary.

BisTrack kit assembly rules (Bill of Materials structures) map to Odoo mrp.bom records with type=kit or normal depending on the assembly method. Component quantities and routing steps migrate to mrp.bom.line and mrp.routing.workcenter records. Kit pricing rules from BisTrack are captured as custom fields on mrp.bom for the customer's admin to implement as Odoo product variants or multi-step pricing rules post-migration.