Migrate from iCast to Odoo ERP

iCast customer records with payment terms, credit limits, and account manager references map to Odoo res.partner records with the customer_rank field set to 1 (or 0 for the vendor flag). We preserve the iCast payment term as an account_payment_term reference, credit limit as credit_limit on res.partner, and the account manager as a user_id lookup. Any custom fields on the iCast customer record are inventoried during discovery and mapped to custom res.partner fields in Odoo before import. Multi-entity iCast customers may have company_code prefixes that require stripping or mapping to a separate company_id in Odoo's multi-company configuration.

iCast vendor records including address, payment terms, and account numbers map to Odoo res.partner with the vendor_rank field set. We preserve the vendor account number as a ref string for reconciliation with Odoo's account_move partner_bank mapping. Duplicate detection during import runs against the vendor name and tax ID fields to prevent duplicate res.partner records that would break purchase order linkage.

iCast inventory items with SKU, description, unit of measure, cost, and warehouse location codes map to Odoo product_template records with product_product variants where needed. The iCast unit of measure maps to uom_id and uom_po_id on the Odoo product. We handle multi-location inventory by mapping each iCast location code to a specific stock.warehouse and stock.location in Odoo, creating stock.quant records that reflect the current on-hand quantity per SKU per warehouse at cutover. Serialized inventory requires additional mapping from iCast's serial number fields to Odoo's stock.production lot table linked to the relevant stock.quant.

Open and historical iCast sales orders with line items, pricing, and order status map to Odoo sale.order and sale.order.line. We map iCast order statuses to Odoo sale.order state values (draft, sale, done, cancel), flagging held or pending orders for manual review before import to confirm whether they should be created as draft or confirmed sale orders. Customer and product references on the order lines are resolved against the already-imported res.partner and product_template records during the transform phase. Historical orders that are already fulfilled are migrated with state=done to preserve the closed-book record in Odoo.

iCast purchase orders containing vendor references, line items, quantities, and expected delivery dates map to Odoo purchase.order and purchase.order.line. Vendor linkage is preserved by resolving the iCast vendor account number to the res.partner record imported in the vendor phase. Expected dates migrate to the Odoo date_planned field on each purchase order line. Completed purchase orders are imported as done-state records to maintain closed-book history.

iCast maintains a hierarchical chart of accounts used for all financial posting. We map each iCast account number and type (asset, liability, equity, revenue, expense) to the corresponding Odoo account.account record with the correct user_type_id. Accounts that appear in transaction history but do not yet exist in the destination chart are flagged during discovery and pre-created before journal entry import begins. We also map any iCast tax codes to Odoo account_tax records so that sales and purchase transactions carry the correct tax rate post-migration.

iCast general journal entries with date, account references, debit/credit amounts, and memo fields map to Odoo account.move records with account.move.line children. We resolve each iCast account number to the pre-created account.account record before line insertion to satisfy Odoo's foreign-key constraint on account_id. Entries with non-standard or unmapped account references are flagged and held in a reconciliation queue until the destination chart is updated. We scope the journal entry migration window with the customer upfront, balancing complete history against migration cost and destination data hygiene, and recommend a cutover date for open-period entries to be imported as current-state records.

iCast user accounts with login credentials, roles, and access permissions map to Odoo res.users records. We extract the iCast role structure during discovery and map it to Odoo access groups and record rules. Active and inactive status is preserved so that terminated users remain in the Odoo database as inactive records for audit continuity. The customer's Odoo administrator provisions the actual login credentials post-migration as part of the Odoo configuration phase.

iCast customers frequently add custom fields to Customers, Vendors, Products, and Orders beyond the standard field set. These have no automatic export path and must be manually inventoried during discovery. We list every custom field with its data type, purpose, and the objects it extends, then pre-create the corresponding custom field in Odoo using ir.model.fields before the main data import begins. Custom fields that contain calculated or derived logic require the customer to review whether the business rule can be expressed as an Odoo computed field, a related field, or an on-change method in the destination system.

iCast attachments associated with Customers, Vendors, Orders, or Products migrate as ir.attachment records linked via res_model and res_id to the corresponding Odoo record. We export file content and metadata from iCast, map the original record reference to the newly created Odoo ID during import, and store the binary in Odoo's filestore. Attachments without a resolvable parent record (deleted or orphaned in iCast) are listed separately for the customer to handle manually after go-live.