Migrate from Orderry to Odoo CRM

Orderry Client maps to Odoo res.partner as a company-type partner (type=contact or type=company depending on whether the client is an individual or organization). FlitStack creates the partner record first so that contacts and work orders can reference it via partner_id foreign key. Address fields (street, city, phone, email) map directly; Odoo stores addresses on the partner record itself rather than a separate address object.

When an Orderry Client has multiple named individuals (e.g., a corporate customer with three service contacts), FlitStack creates one company-type res.partner as the parent and splits each named individual into a contact-type res.partner with parent_id pointing to the company partner. This preserves the full contact hierarchy that Orderry tracks per-location.

Orderry Work Order maps to Odoo crm.lead as the primary sales pipeline record. Work order name becomes crm.lead name (displayed as opportunity title in Odoo's Kanban pipeline view). Work order status (New, In Progress, Completed, Cancelled) maps to crm.lead stage_id via value mapping. The assigned employee email resolves to Odoo res.users via email match for crm.lead user_id assignment.

Orderry Work Order line items (parts used, labor hours, services) map to Odoo sale.order.line records on a sale.order created alongside each crm.lead. Products map via product_id to product.product; service lines map with product_type=service. Quantity and price carry over; Odoo's sale.order.line tracks order quantity, delivered quantity, and invoiced quantity separately from the pipeline crm.lead.

Orderry Work Orders that represent operational task tracking (not just sales pipeline) may need a companion record: either logged as crm.lead activities with type and date fields, or mapped to project.task if the Odoo Project module is installed. FlitStack surfaces this as a migration-plan decision — you choose whether operational work orders become pipeline opportunities, activity logs, or project tasks.

Orderry Products map to Odoo product.product records. Product type in Orderry (stock item vs. service) sets product.product type to stockable or service respectively. Orderry product categories map to Odoo product.category for inventory grouping. Product unit of measure (unit, hour, day) maps to product.product uom_id against Odoo's uom.uom unit list.

Orderry Estimates map to Odoo sale.order in draft/quotation state (state=draft). Estimate line items map to sale.order.line using the same product.product translation as Work Order lines. Orderry's accepted/rejected estimate status maps to Odoo sale.order state: sent → quotation sent; approved → sale_order confirmed; rejected → cancelled.

Orderry Invoices map to Odoo account.move records of type out_invoice. Invoice line items map to account.move.line with product_id, quantity, price_unit, and tax_ids from the Orderry invoice. Partner payment terms and journal assignments are applied based on Odoo's default account configuration for the partner.

Orderry Locations are first-class business units with separate inventory, staff, and client pools. Odoo has no native multi-location CRM concept — FlitStack maps each Orderry Location to either a separate res.company (if Odoo multi-company is configured) or to a custom Location__c char field on res.partner. Multi-location clients get multiple partner records or a single partner with location arrayed in the custom field.

Orderry Assets track customer-owned equipment under repair. FlitStack creates a product.product record for each Asset (type=product) linked to the client res.partner via product_variant_ids. Asset serial number maps to product.product lot_id if Odoo Inventory is installed; otherwise stored as a custom char field for reference. Asset status history is preserved as crm.lead activity logs.

Orderry Employees map to Odoo res.users for owner and assignee resolution. FlitStack matches Orderry employee email against Odoo user emails to populate crm.lead user_id. If no Odoo user exists for an employee, records are assigned to a fallback admin user and flagged for manual reassignment. res.partner records for employees are created separately if needed for HR purposes.

Orderry custom fields on Client, Work Order, and Product migrate to Odoo custom fields via Settings > Technical > Database Structure > Models. Char fields become char fields; pick-list fields become selection fields with value-by-value mapping. FlitStack creates the custom field definitions in Odoo before data loads so the target fields exist at migration time.