Migrate from Tryton to Odoo ERP

Tryton Party is the unified master record for customers, suppliers, and employees. Odoo res.partner separates commercial entities from contact persons: the commercial_partner_id on contacts must be set to the parent partner record during import. Party categories map to Odoo partner_category tags. Fiscal data (tax ID, VAT, CUIT) migrates to partner fields. We create a commercial_partner link for every contact record and set address delegation on the partner record so that child contact addresses resolve correctly in Odoo's ORM.

Tryton splits Sale Quotations (draft) and Sale Orders (confirmed) into separate records; Odoo uses state on a single sale.order model. We map Tryton states (quotation, confirmed, done, cancelled) to Odoo's sale_order states (draft, sent, sale_order, done, cancel). Party link resolves via the res.partner import completed in phase one. Line-level taxes, discounts, and descriptions map field-for-field. Lines reference the resolved product.product records.

Same structure as sale orders. We map supplier party references to Odoo res.partner (commercial_partner_id set), expected dates to date_planned on purchase.order.line, and line-level quantities and prices directly. Purchase order states migrate including confirmed and cancelled. Odoo's in_transit and receipt picking workflow requires a related stock.picking sequence to be configured post-import.

Tryton products map to Odoo product.template with type (service vs stockable vs consumable) preserved. Variant attributes in Tryton (if using product.configurator) create Odoo product.product variants linked to the template. We preserve the Tryton code as product.default_code, UPC/EAN as barcode, and cost price as standard_price. Category mapping goes to product.category hierarchy in Odoo.

Tryton invoices migrate to Odoo account.move records with move_type set to out_invoice, in_invoice, out_refund, or in_refund. Posted invoices in Tryton become Posted moves in Odoo (posted date preserved). Draft invoices migrate as draft moves requiring manual posting. Tryton's tax and total amount caches must be recomputed after import because Odoo recalculates amounts on write via the account.move compute method—we flag any invoice where migrated total deviates from computed total by more than 0.01 in the validation pass.

Tryton account_chart records map to Odoo account.account. Account type (expense, revenue, receivable, payable, liquidity) maps to user_type_id using Odoo's standard chart template classification. Code structure and name hierarchy migrate directly. OHADA-configured accounts are flagged during scoping and routed through a dedicated mapping pass that sets the correct user_type_id and tags; OHADA-specific module dependencies in Tryton do not exist in standard Odoo and must be verified by the customer's accountant before import.

Tryton analytic accounts map directly to Odoo account.analytic.account. Analytic lines in Tryton attach to moves and invoices as a separate axis; in Odoo they attach to account.move.line via analytic_distribution. We preserve the account hierarchy and root structure. Customers must verify that Odoo's analytic plan matches their reporting intent since Tryton's axis model differs from Odoo's distribution-key approach.

Tryton stock moves track goods from receipt to delivery. We preserve shipment states (pending, waiting, assigned, done), warehouse assignments from stock.location hierarchy, and quantities. Lot and lot number data maps to stock.production.lot records. Odoo's delivery validation workflow (picking -> validate -> done) requires a related stock.picking record to be created before moves can be confirmed; we generate this during the import pass.

Tryton project work entries and task hierarchy map to Odoo project.project with nested project.task records. We preserve active vs closed state, assigned party (project manager), and duration/time data. Timesheet data from Tryton project.work.time_lines migrates to account.analytic.line linked to the project if Odoo Timesheet app is active. Odoo project.task uses a stage kanban model; we map Tryton work state to Odoo stage records.

Tryton stores attachments as Binary fields with a file_id reference to external storage. We run a pre-export pass querying ir_attachment, extract content by file_id, and bundle attachments as a parallel export set. In Odoo, we re-attach by matching the original file_id stored as an external identifier field on the new record, preserving document linkage without re-uploading. Large attachments (>10MB) are chunked and validated post-import for integrity.

Tryton users map to Odoo res.users. Active/inactive status migrates. Group memberships do not map 1:1 because Tryton and Odoo use different permission models (Tryton permission groups vs Odoo's access rights and record rules). We preserve group assignments as notes in the migration handoff document and the customer's Odoo admin rebuilds access rights against the Odoo security model. Login credentials do not migrate; Odoo sends password reset emails to migrated user email addresses.

Tryton supports dynamic field extension via ir.model.field. Custom fields added by modules or administrators are migrated as key-value pairs when the destination schema supports them via Odoo's custom field mechanism. Fields that reference Tryton-specific models without Odoo equivalents are documented in the handoff inventory with suggested Odoo field type mappings. Custom fields referencing Tryton module objects that have no Odoo equivalent are flagged for manual review.