Migrate from Grade to Odoo ERP

Grade's assumed contact or vendor records map to Odoo's res.partner model. Odoo uses a single partner model for customers, vendors, and employees rather than separate objects. We identify the source object through live-environment audit, map address fields (street, city, zip, country) to res.partner address fields, and preserve any phone, email, or website data. partner_id is the primary key in Odoo and is referenced by all transactional models.

If Grade uses separate Company and Contact objects, the Grade Company maps to a res.partner record of type 'contact' with a child address or as a commercial partner linked to contacts. Odoo uses the commercial partner concept to group child contacts under one parent partner for reporting and pricing. We configure this hierarchy during migration design based on Grade's actual schema.

Grade product or item records map to Odoo's product.product (variant level) and product.template (product level) models. Odoo enforces the template-variant split: product.template holds the shared product definition, product.product holds the specific variant (size, color, etc.). If Grade products have no variants, we create a single variant per template. The Grade SKU maps to product.default_code, name maps to product.template.name, and unit of measure maps to uom_id.

Grade inventory quantities map to Odoo stock.quant records. We map the product reference, location (warehouse/stock location), and quantity on hand. Odoo requires stock.location records to exist before quant records are created, so we provision the location hierarchy (Warehouse > Stock > Shelves) during the schema phase. On-hand quantity and reserved quantity are tracked separately in Odoo; Grade's inventory status maps to the quant's inventory_quantity field.

Grade purchase orders map to Odoo's purchase.order (header) and purchase.order.line (line) models. We map the vendor partner reference, order date, confirmation date, and line-level product, quantity, and price. Odoo purchase orders reference product.supplierinfo for vendor-specific pricing; we resolve or create supplierinfo records during import to ensure the PO lines have correct landed costs.

Grade invoices map to Odoo account.move records with move_type of 'in_invoice' (vendor bills) or 'out_invoice' (customer invoices). Odoo uses a journal-based accounting model: we identify the correct account.move record type and journal before import, then map the invoice lines to account.move.line with the appropriate account_id, debit, and credit values. Historical paid invoices require reconciled account.payment records.

Grade payment records map to Odoo account.payment, which is a separate model from account.move in Odoo's invoice-to-payment reconciliation workflow. We map the payment date, amount, partner_id, and payment_method. account.payment must be linked to an account.move via the reconciled_account_move_ids field for the Odoo accounting ledger to balance correctly.

Grade project records map to Odoo project.project. We map the project name, description, partner_id (customer), date_start, and date_end. Odoo's project module has dependencies on res.partner (for customer linkage) and optionally on sale_order (if the project is linked to sales). We create the project before importing any linked tasks.

Grade tasks map to Odoo project.task, linked to project.project via project_id. We map the task name, description, planned_hours, effective_hours, stage_id (task stage Kanban state), user_id (assignee), and date_deadline. Task dependencies in Odoo use project.task.depend_on_ids; we resolve these as foreign key lookups after both the parent and child task records exist.

Grade user or staff records map to Odoo res.users. We map the user's name, login (email), and active status. Odoo stores password hashes in a separate auth_totp table; we do not migrate passwords. Active status maps directly. res.users is referenced by project.task (user_id), account.move (create_uid), and purchase.order (user_id); it must be imported before these transactional models.

If Grade contains custom objects not present in standard ERP schemas, we create the equivalent Odoo model via Odoo Studio or programmatically via the ORM before importing data. Custom Odoo models require the model name (x_<object>_), the XML external identifier, and field definitions including field type (char, integer, float, many2one, etc.). Odoo custom models can have many2one lookups to standard objects (res.partner, product.product) once those records are imported.

Grade file attachments map to Odoo ir.attachment records linked to the parent model (res.partner, account.move, project.task, etc.) via res_model and res_id. Binary file content is stored in ir.attachment.datas as base64. If Grade attachments reference external URLs rather than binary files, we map those to ir.attachment.type = 'url' with the URL stored in the external URL field. Each attachment is linked to its parent record after the parent record's Odoo ID is known.