Migrate from Iptor ERP to Odoo ERP

Iptor Business Partners with BP Type = Customer map to Odoo Contact. We extract the BP name, address fields (street, city, state, zip, country), phone, email, tax ID, payment terms, and credit limit. The Iptor BP code becomes the Contact's internal reference. Customer-specific shipping addresses migrate as separate Contact addresses linked to the parent. BP classifications map to Odoo Contact tags or industry tags.

Iptor Business Partners with BP Type = Vendor map to Odoo Vendor (res.partner with supplier = True). Vendor-specific fields including bank details, W-9/W-8BEN status, and purchase payment terms migrate to the Vendor's accounting and purchasing tabs. Vendor contacts migrate as child Contact records linked to the vendor company.

Iptor Items migrate to Odoo Product (product.product for variants, product.template for the product master). Item code maps to Product's default_code (SKU). Item descriptions, specifications, and images migrate to product description fields. Configurable items with multiple variants map to Odoo product variants with attribute lines. The Item Classification hierarchy is preserved separately in Product Categories and is referenced in the category mapping step.

Iptor's multi-level Item Classification tree (up to 5+ levels for Distribution) does not map 1:1 to Odoo's two-level Product Category hierarchy (Parent Category + Child Category). We extract the full classification path per item as a dot-separated string (e.g., 'Food.Beverages.SoftDrinks.Soda'), populate Odoo's Product Category to the deepest available level, and attach the full path as a tag or note field on the Product for full-text search and reporting. Publishing items use a separate classification scheme that maps to Odoo product tags with industry-specific naming.

Iptor Sales Orders migrate to Odoo Sale Order. Order number, order date, customer reference, and payment terms transfer directly. Line items migrate with product, quantity, unit of measure, unit price, taxes, and discount percent. Order status (Open, Fulfilled, Cancelled) maps to Odoo's sale order states (sale, done, cancel). Partially fulfilled orders migrate with delivered quantities tracked via delivery orders.

Iptor Purchase Orders migrate to Odoo Purchase Order. Vendor assignment, order date, expected delivery date, and line items migrate with product, quantity, unit, price, and taxes. Partially received POs migrate with received quantities flagged so the destination reflects in-progress receipts. PO status maps to Odoo's purchase order states.

Iptor AR Invoices migrate to Odoo Account Move (type = out_invoice). Invoice number, date, due date, customer, line items, tax codes, and totals transfer. Payment terms link to Odoo's payment term records. Historical paid invoices migrate as posted Account Moves; open invoices remain in draft for reconciliation after go-live. Credit notes migrate as out_refund Account Moves.

Iptor AP Invoices migrate to Odoo Account Move (type = in_invoice). Vendor, invoice number, date, due date, line items, and tax codes transfer. Open AP invoices remain in draft for the vendor payable reconciliation after go-live. Historical paid vendor bills migrate as posted Account Moves. Debit notes migrate as in_refund Account Moves.

Iptor Delivery Notes migrate to Odoo Stock Picking (type = outgoing). Header data includes origin sale order reference, carrier, and shipping address. Line data includes product, quantity ordered, quantity shipped, and lot/serial number if tracked. The picking is linked back to the originating Sale Order for traceability. Completed deliveries update the related sale order's delivered quantity.

We extract open payables and receivables as explicit draft Account Moves at migration time so Odoo begins with accurate aged trial balance data. Each open invoice migrates as a draft entry (not posted) so the customer can run aged payable and receivable reports immediately after go-live and reconcile against statements. Closed historical invoices migrate as posted moves for audit continuity. A reconciliation mapping document accompanies the data so the customer's accountant can match open items manually.

Iptor's configurable segment-based account structure maps to Odoo's standard chart of accounts. We map each Iptor account code and name to an Odoo account code and name, flagging any accounts with non-standard segment assignments for manual review. Multi-segment Iptor accounts (e.g., 4-4-4-4 structure) map to the deepest Odoo account level available, with parent segment data preserved in the account description for reference.

Historical journal entries migrate to Odoo Account Move (type not set, posted state). Entry date, journal, description, and all debit/credit lines transfer. Recurring journal entries from Iptor are documented as a separate reference list for manual configuration in Odoo's recurring entries feature. Journal entry numbering follows Odoo's sequence configuration post-migration.

Iptor stock levels migrate to Odoo Stock Quant records representing current on-hand quantity per product per location. Multi-warehouse Iptor setups require warehouse code mapping to Odoo stock location hierarchy (Warehouse > Location > Sub-location). Lot and serial numbers migrate to Odoo's lot/serial number tracking. Stock valuation amounts transfer to product valuation fields, with the customer confirming whether to use standard cost or average cost method in Odoo.

Only present where Iptor Publishing module is active. Royalties, Rights, Permissions, and Contract records have multi-dimensional structures that do not map to any native Odoo object. We convert these to structured CSV/Excel exports with flattened columns: contract ID, right type, royalty rate, entitlement period, counterparty, and payment terms. The customer reviews and approves the flattened schema before we commit. For active ongoing contracts, we propose target Odoo fields (custom fields on product or partner) to preserve key values for operational reference.