Migrate from Tryton to Epicor Prophet 21

Tryton Parties are unified records for customers, suppliers, and employees. We split them at migration time using party.category and the party/account relationship. Customer-type parties map to Epicor Customer with Address, Contact, and PaymentMethod records created in dependency order. Supplier-type parties map to Epicor Supplier with the same address and contact structure. Party-specific fiscal data and tax identifiers migrate to the respective Customer or Supplier tax and payment fields. Multi-company party assignments in Tryton require mapping to Epicor's Plant-level customer and supplier hierarchies.

Tryton separates Sale Quotation from Sale Order; both map to Epicor SalesOrder with the OrderHed and OrderDtl records created sequentially. Tryton quotation states (quotation, confirmed, done, cancelled) map to Epicor OrderRel records with appropriate release status. Line-level pricing, taxes, and descriptions migrate to OrderDtl. Party links resolve via the Customer records created in the Party split pass. Tryton shipment states map to Epicor Shipment records attached to the SalesOrder.

Tryton Purchase Orders map to Epicor POHeader and PODetail with supplier party reference resolved to the Supplier record created from the Party split. Expected dates, quantities, and prices migrate directly. Order states including confirmed and cancelled transfer to Epicor POLine and PORel records with release status. Purchase invoicing linked to the PO migrates as separate AP invoices attached to the PO.

Tryton Stock Moves track goods from receipt to delivery with shipment state, warehouse assignment, and quantity. We map warehouse to Epicor Warehse, and each Stock Move becomes a PartTran record linked to a PartBin snapshot. Lot and serial tracking migrates to Epicor PartLot. Inventory valuation amounts from Tryton migrate to PartCost records. We run a quantity reconciliation after PartTran load to confirm PartBin balances match Tryton.

Tryton's account_chart model with account type, parent hierarchy, and tax applicability maps to Epicor's Account (COA) structure. Account codes and names migrate directly. Account type settings (expense, revenue, receivable, payable) map to Epicor NaturalAccount and Account Type. OHADA-specific accounts require a dedicated mapping pass since Epicor has no native OHADA module. We flag OHADA accounts during scoping and generate a separate OHADA account mapping spreadsheet for the customer's admin to configure in Epicor before GL posting data is loaded.

Tryton Analytic Accounts store a separate analytical axis against moves and invoices that Epicor does not replicate natively. Epicor uses Cost Elements or GL Analysis for similar purposes, but these require configuration per the customer's chart of accounts structure. We migrate analytic lines as dimension-tagged GLDetail records and recommend a BAQ-based lookup table in Epicor for reporting. The customer chooses the Epicor equivalent during scoping, and we document the mapping in the handoff spreadsheet.

Tryton Invoices carry a state machine (draft, validated, posted, paid, cancelled) and tax computation caches. Posted and paid invoices migrate to Epicor ARInvoice (for customer invoices) or APInvoice (for supplier invoices) with full line-level detail, tax amounts, and payment terms. Invoice payment allocations migrate as Epicor CashReceipt records. We trigger a post-import recompute pass for any invoices where cached amounts deviate from computed totals by more than a currency rounding threshold, consistent with Tryton's own migration documentation requirements for pre-7.0 invoice records.

Tryton Project and Work entries support hierarchy, status tracking, and time recording. We map to Epicor Project with WBS (Work Breakdown Structure) phases as ProjectPhase records. Party assignments and durations migrate to ProjectPhase and ProjectTask records. Active versus closed status carries forward. Note that Epicor's project-centric model differs from Tryton's task-centric model: Epicor Projects are containers for revenue recognition, billing, and scheduling, and the customer's admin may need to restructure the Tryton work hierarchy to match Epicor's phase-and-task structure.

Tryton stores file attachments as Binary fields with file_id references in ir_attachment. We run a pre-export pass that queries ir_attachment, extracts file content by file_id, and bundles attachments as a parallel export set. In Epicor, we create DocType records (one per attachment category identified during scoping) and load file content via Epicor's REST API with chunking for files exceeding 10 MB. Parent-record linkage is preserved by matching the original Tryton file_id to the newly created Epicor Doc2 record and linking it to the corresponding Order, Invoice, or Part record.

Tryton Users and Employees are separate models with role-based access control. Active users migrate to Epicor User with login and license assignment. Employee records map to Epicor Employee with department and supervisor assignments. Group memberships from Tryton remap to Epicor's Role-based security groups. Inactive users are migrated as inactive Epicor users with a note flagging their original Tryton status. Owner assignments on transactional records resolve via the User email lookup after User provisioning.

Financial accounts for payments and cash migrate to Epicor BankAcct with journal assignments and reconciliation settings. Open AP/AR balances from Tryton migrate as PartTran and GLJrnLine records linked to the correct party account. Payment methods associated with BankAcct records in Tryton map to Epicor PaymentMethod linked to the corresponding BankAcct.

Tryton supports dynamic field extension via ir.model.field and properties. Custom fields added by modules or administrators migrate as key-value pairs captured in a staging table during export. In Epicor, we pre-create UD columns (User Defined fields) on the target table (OrderHed, OrderDtl, Part, etc.) before transactional records are loaded, using Epicor's UD Column Map interface. Large multi-select or structured custom fields may require a custom BAQ-based lookup table rather than native UD columns, which we document in the mapping spreadsheet.