Migrate from Orion ERP to Epicor Prophet 21

Orion COA records map to Epicor GLAccount with account code as the natural account, account description as GLAccountDesc, and segment structure mapped to Epicor's segment codes (GLBook and GLAccountType). Multi-segment Orion charts require us to decompose each segment into Epicor's segment-value hierarchy before import. Effective dates and inactive flags transfer to GLAccount. The mapping is validated against Epicor's fiscal calendar to ensure account activation dates align with open periods.

Orion GL transactions export as line-level records with header metadata (journal number, date, description) and per-line account code, debit, and credit. We split header and line data from Orion's flat export into Epicor's two-table structure: GLJrnGrp holds the batch and journal group metadata; GLJrnLine holds each posting with AccountNum, DebitSeq, and CreditSeq references. Fiscal period and fiscal year are resolved from the transaction date against Epicor's GLBook fiscal calendar. Historical GL entries are imported as posted journals with Open = false to prevent reopening closed periods.

Orion customer master records map to Epicor Customer by company, custNum, andcustID. Billing address, payment terms, credit limit, and currency code transfer to Epicor Customer address and credit metadata. The Orion customer tax ID maps to TaxPayerID on Epicor Customer. Where Orion stores multiple contacts per customer, we create Epicor ShipTo and ConTact records linked to the parent Customer. Customer payment terms are resolved from Orion's terms code against Epicor's PaymentTerms table.

Orion vendor master records map to Epicor Supplier (Vendor) with vendor code, name, tax ID, payment terms, and bank details. The Orion vendor tax ID maps to TaxPayerID on Supplier. Payment terms are matched to Epicor's PaymentTerms records, and bank details transfer to SupplierBankAcct if present in the Orion export. Vendor address maps to SupplierNum as the primary address record, with RemitTo mapped separately if Orion stores distinct remittance addresses.

Orion open AP invoices are extracted as a distinct migration scope item separate from historical AP. We map vendor reference, invoice number, invoice date, amount due, and due date to Epicor APInvoiceHed and APInvoiceDtl. These records are injected as opening-balance AP invoices rather than new transactions, setting the InvoiceDate to the original invoice date and DueDate to the original due date to preserve aging accuracy in Epicor's AP aging report. Invoice reference numbers transfer to the invoice description field for reconciliation.

Orion open AR invoices follow the same pattern as open AP: extracted as a distinct scope item and injected as opening-balance AR invoices in Epicor. Customer reference, invoice number, amount receivable, and due date map to Epicor ARInvoiceHed and ARInvoiceDtl. InvoiceDate and DueDate are preserved to maintain aging accuracy. Credit memos and adjustments stored as negative AR in Orion are imported as negative AR invoices in Epicor with the same logic applied.

Orion inventory items map to Epicor Part with part number as PartNum, description as PartDescription, unit of measure as UOMClass and UOMCode, standard cost as StandardCost, and the primary warehouse to PartBin. Orion's on-hand quantity per warehouse maps to PartBin OnHandQty for each warehouse record. If Orion stores multiple sites, we create one PartBin row per site-warehouse combination. Part's TypeCode (stock, non-stock, or service) is inferred from Orion's item type field or default to Stock.

Orion Manufacturing Cloud BOM records (not present in Distribution or Financial editions) decompose into Epicor BOMHeader and BOMDetail. Each Orion BOM defines a parent part, revision, and a set of component parts with quantities and operations. We map the parent to BOMHeader.MtlPartNum and BOMHeader.RevisionNum, and each component line to BOMDetail with PartNum, QtyPer, and RelatedOperation. If Orion BOMs have multiple levels (sub-assemblies), we flatten or nest them per the customer's Epicor BOM replication preference. This object is skipped for non-Manufacturing Cloud migrations.

Orion purchase order headers and lines map to Epicor POHeader and PODetail respectively. The Orion PO number becomes POHeader.PONum, vendor reference resolves to SupplierNum, and PO date becomes PODate. Each line maps with part number or MfgDetail, ordered quantity, unit cost, and due date. Open POs (status not closed) are imported as open PO records in Epicor; closed POs are logged with final received quantities for audit. POLine received and invoiced quantities are reconciled against Orion's received and invoiced totals to prevent duplicate receipt posting.

Orion sales order headers map to Epicor OrderHed with order number as OrderNum, customer reference resolves to Customer and ShipToNum, and order date becomes OrderDate. Line items map to OrderDtl with part number, quantity ordered, unit price, and discount. We distinguish fulfilled versus pending lines from Orion's order status to set Epicor OrderDtl.Status appropriately: open lines remain open, partially shipped lines are set to partial, and completed lines are closed. Pricing from Orion transfers to OrderDtl.UnitPrice with discount codes mapped to Epicor's discount rules.

Orion employee records map to Epicor Employee with employee ID, first name, last name, department, job title, and employment dates. Orion's compensation effective dates are preserved in Epicor's EmpBasic with the most recent salary or hourly rate stored as the primary rate. If Orion stores HR data beyond basic employee records (benefits, PTO, tax withholding), those objects require extended scoping because Epicor's HR module (if present) may use a different schema structure than Orion's HR module. We flag HR data beyond basic employee records as a separate scope item during discovery.

Orion custom fields on master and transaction records (Customers, Vendors, Parts, Orders, POs) are detected during the scoping export and mapped to Epicor User Defined fields (UD Fields) or UD Codes where applicable. Epicor's UD table structure (UD01-UD12) accommodates free-form custom data, but typed fields like date, number, and checkbox require us to define the corresponding UD field type before import. Custom field existence and data types vary by Orion edition and customer configuration, so we generate a custom field manifest during discovery and deploy Epicor UD fields to match before any data load begins.