Migrate from Triumph to Epicor Prophet 21

Triumph Debtors records map to Epicor Erp.Customer rows scoped to the destination Company. CustID becomes the Epicor customer key (typically maintained as the Triumph customer code where format allows, or remapped per Epicor numbering conventions if Triumph codes exceed Epicor field lengths). Customer billing address loads to BillToAddr1/2/3/City/State/Zip; shipping addresses split into ShipTo records as separate Erp.ShipTo rows. Payment terms reference Erp.Terms pre-created during reference data load. We load via DMT Customer template or POST to /v2/Erp.BO.CustomerSvc/Customers.

Triumph Creditors map to Epicor Erp.Vendor rows. VendorID carries the Triumph supplier code where Epicor field length allows. Where a third party exists in both Triumph Debtors and Creditors, Epicor allows linking via the Customer-Supplier relationship table (Erp.CustomerVendor), so both Customer and Vendor records are loaded with the link row connecting them. Payment terms reference Erp.Terms; remittance addresses and 1099/withholding tax flags load to vendor-specific fields. Loaded via DMT Vendor template.

Triumph GL account codes map to Epicor Erp.GLAccount rows under the destination Company's Chart of Accounts (COAID). Triumph's flat account number maps to Epicor's segmented account structure (Natural Account + Cost Center + Division + custom segments) per the customer's Epicor implementation. Account type (Asset, Liability, Equity, Income, Expense) maps to the corresponding Epicor account class. We require the Epicor COA structure designed and approved before this load, because account segmentation is a one-time design decision that affects all transactional history.

Triumph open AR invoices load into Erp.InvcHead (header) and Erp.InvcDtl (line items) as Posted invoices (OpenInvoice=true, Posted=true). InvoiceNum preserves the original Triumph invoice number. Line GL distribution (Erp.InvcTax, Erp.InvcDtlTax) requires the COA mapping completed first. Open invoices load via DMT AR Invoice template, which handles the posted-state metadata that the REST endpoint does not expose directly. Original invoice date carries to InvoiceDate; due date to DueDate.

Triumph open AP invoices load into Erp.APInvHed and Erp.APInvDtl as Posted, Open. InvoiceNum carries the supplier's invoice reference; InvoiceRef carries the Epicor internal reference. The GL expense distribution per line references Erp.GLAccount entries from the COA load. Tax detail loads into Erp.APInvTax. We use DMT APInvoice template for the bulk load and validate Vendor AP aging in Epicor matches the Triumph creditors aging at cutover.

Triumph customer receipts split into Erp.CashHead (cash receipt header with bank account, amount, date) and Erp.CashDtl (allocation lines tying the cash to specific InvoiceNum values). Where a single Triumph receipt was applied across multiple invoices, we preserve each allocation as a separate Erp.CashDtl row rather than collapsing. Bank account reference points at Erp.BankAcct rows pre-created during reference data load. Payment method maps to Erp.PaymentMethod records.

Triumph supplier payments and Electronic Funds Payment runs split into Erp.CheckHed (payment header per supplier) and Erp.CheckDtl (allocation to specific AP invoices). EFT batch IDs from Triumph migrate as a UD field on Erp.CheckHed because Epicor's native payment batch model is structured differently. CheckNum, CheckDate, BankAcctID, and PaymentMethod all map per Epicor's standard AP payment schema. Validation requires matching Vendor open balance in Epicor against Triumph at cutover.

Triumph Inventory items map to Erp.Part rows scoped to the destination Company. PartNum takes the Triumph item code (subject to Epicor's 50-character limit and naming rule constraints). Class (Erp.ProdGrup) and Product Group references resolve against pre-loaded reference data. Stock-on-hand at cutover loads into Erp.PartBin keyed by Plant, Warehouse, and Bin. We require Plant, Warehouse, and Bin records pre-created in Epicor before stock import. Loaded via DMT Part template plus PartBin balance template.

Triumph service items map to Erp.Part rows with TrackInventory=false and NonStock=true. These appear in Sales Order line entry and AR Invoice line entry but do not carry stock balances or generate Part Transaction history. Sales unit of measure and Purchasing UOM still apply, and GL revenue and COGS accounts must be set on the Part record so that sales of the service post to the correct GL natural accounts. Loaded via the standard DMT Part template with the TrackInventory flag set false.

Triumph customer quotes migrate to Erp.QuoteHed records with quote status mapped to Epicor's quote lifecycle (Open, Quoted, Won, Lost). Quote lines load to Erp.QuoteDtl with Part reference, quantity, unit price, and unit of measure. Quote-to-Order conversion history preserves via the OrderNum reference back to the originating Erp.OrderHed if the Triumph quote was already converted to an order at migration time. Loaded via DMT Quote template.

Triumph sales orders map to Erp.OrderHed (header) plus Erp.OrderDtl (line items) plus Erp.OrderRel (release schedules for partial-shipment or scheduled-delivery orders). Order status maps from Triumph's order state to Epicor's OpenOrder, Shipped, Invoiced, Closed lifecycle. Customer PO number, ShipTo reference, and salesperson all carry over. We use DMT Sales Order template for the bulk load and reconcile open-order value in Epicor against Triumph at cutover.

Triumph purchase orders map to Erp.POHeader + Erp.PODetail + Erp.PORel. PONum carries the Triumph PO reference. Each line carries Part reference, quantity, unit cost, and expected receipt date. Release records (Erp.PORel) handle multi-delivery POs and tie to specific Plant/Warehouse/Bin for the inbound receipt. PO status maps to Epicor's Open, Closed, Voided states. Approval status loads to the ApproveDate field for already-approved POs. Loaded via DMT PO template.

Triumph inventory transactions (receipts, issues, adjustments) map to Erp.PartTran rows with TranType codes (PUR-STK for purchase receipts, STK-CUS for customer shipments, STK-MTL for material issues, ADJ-CST for cost adjustments). Each row carries Part, Plant, Warehouse, Bin, Quantity, UnitCost, TranDate. Where the originating Triumph document was not in migration scope, we use TranType=ADJ-QTY with a Reference field flagging the legacy source. We require the Part, Plant, Warehouse, Bin, and Cost Set records all pre-loaded before this transactional load.

Triumph Bank Reconciliation accounts map to Erp.BankAcct rows. BankAcctID, BankAccount (the actual account number), BSBNumber (loaded into the routing-equivalent field), Currency, and GLAccount reference all carry over. We pre-create Erp.BankAcct during reference data load because every cash receipt and AP payment carries a BankAcctID lookup that must resolve at insert time.

Triumph bank transactions map to Erp.BankTran rows. Each transaction carries BankAcctID, TranDate, Amount, Description, and TranType. Reconciled transactions tie to the corresponding AR cash receipt (CashHeadNum) or AP payment (CheckHedNum) via the BankTran link, preserving reconciliation history. Statement reference numbers from Triumph map to the StatementRef field for audit traceability against historical bank statements.

Triumph operators split into two Epicor objects: Ice.UserFile (Epicor login identity with username, password reset link, role assignments) and Erp.EmpBasic (employee record carrying salesperson code, default warehouse, default plant). For users who are also salespeople in Triumph, both records load with the SalesPerCode linking them. Passwords do not migrate; users receive an Epicor password reset link at cutover. Triumph operator codes preserve in a UD field for audit traceability.

Triumph GST codes map to Erp.TaxType rows with associated Erp.TaxRate rows carrying the percentage and effective dates. Australian GST (10%), GST-free, Input-Taxed, and Export tax types all map to corresponding Epicor TaxType records pre-loaded during reference data setup. Tax liability accounts (GST Collected, GST Paid) link via the COA mapping. We require the Australian tax configuration loaded before any AR or AP transactional data because invoice-line tax details cannot resolve without a valid TaxType reference.