Migrate from ORCA Financial to Epicor Prophet 21

ORCA Financial stores a flat or hierarchical COA with account codes, account names, and account types (asset, liability, equity, revenue, expense). We extract the full COA during discovery and map each account code to a corresponding Epicor GLAccount record scoped to the target Company (company_code). Epicor supports segment-aware COA structures with up to 10 segments; if ORCA Financial uses a custom segment such as cost-center or department, we flag it during scoping and configure the Epicor COA segment structure before import. Account type mapping from ORCA to Epicor GLClass determines the debit/credit normal balance in Epicor.

ORCA Financial customer records (name, billing address, payment terms, contact info) map to Epicor Customer. The primary ShipTo address from ORCA Financial becomes the Epicor CustomerShipTo record linked to the Customer. We extract the customer's payment terms and map them to an Epicor Terms record (e.g., Net 30, Net 60). Remittance addresses and multi-site customer records are flagged as requiring manual review post-import because Epicor handles multi-site billing at the ShipTo level.

ORCA Financial vendor records map to Epicor Vendor. Vendor name, address, and AP terms transfer directly. Remittance addresses and multi-site vendor records are flagged for post-migration review because Epicor separates vendor address types (RemitTo, PurchasePoint) and these require manual configuration in the Epicor Vendor Master if ORCA Financial stores them as distinct address records. We extract vendor payment terms and map them to Epicor Terms records.

ORCA Financial item records (SKU, description, unit cost, warehouse location) map to Epicor Part records. If ORCA Financial stores stock quantities per warehouse, we create corresponding Epicor PartPlant records — one per ORCA Financial warehouse location — with stocking quantities and stocking locations assigned. PartClass and Commodity codes from ORCA map to Epicor PartClass for inventory reporting. We flag the inventory valuation method (FIFO, LIFO, average cost, standard) for reapplication in Epicor's Part costing configuration because Epicor stores valuation at the Part level, not the warehouse level.

Open AP records from ORCA Financial (vendor name, invoice number, amount, due date, invoice date) map to Epicor APInvoice and APTran. We create APInvoiceHeader records with VendorNum resolved to the migrated Vendor, InvoiceNum as the reference, and InvoiceAmt matched against the ORCA amount. Each APInvoice gets one APTran line with GLAccount resolved from the ORCA COA mapping. Open AP invoices carry a zero payment amount; closed historical invoices are migrated as locked records with a flag noting the original ORCA Financial payment status. We do not re-open paid invoices in Epicor.

Open AR records from ORCA Financial (customer name, invoice number, amount, due date) map to Epicor ARInvoice and ARTran. We create ARInvoiceHeader records with CustNum resolved to the migrated Customer, InvoiceNum as the reference, and InvoiceAmt matched against the ORCA amount. Unapplied payments and credit memos are migrated as linked ARAdjustment records tied to the customer. AR teams receive a reconciliation-ready export of migrated AR records alongside the Epicor AR Invoice report for manual verification post-import.

ORCA Financial warehouse location records (location code, address) map to Epicor Warehouse records scoped to the target Plant. Each ORCA warehouse location becomes an Epicor Warehouse with its address. Bin-level location assignments inside warehouses are flagged as a post-migration manual step because Epicor bin structures vary significantly by plant configuration and inventory replenishment logic. We create the warehouse hierarchy (Company > Plant > Warehouse > Bin) in Epicor before item and inventory data is imported so that PartPlant records reference valid warehouse codes.

ORCA Financial user accounts (name, email, role) map to Epicor UserAccount records. We extract the user roster and map ORCA role names to Epicor Security Role assignments. ORCA's flat role model typically maps to a subset of Epicor's permission groups (e.g., Accounting, Inventory, Purchasing). We flag any ORCA role that does not have a direct Epicor Security Role equivalent as requiring manual role assignment post-import. Active vs inactive status transfers directly.

ORCA Financial stores attachments against transactions and master records. Binary attachments do not migrate due to inconsistent storage formats and file-size constraints in both platforms. We export a manifest of all attachment filenames, record types, record IDs, and storage paths from ORCA Financial so the customer's admin team can manually relocate or reattach documents in Epicor after cutover. The manifest is delivered as a CSV alongside the migration runbook.

If ORCA Financial uses custom fields on any standard object (e.g., a customer-specific reference number or a vendor classification code), we identify each during discovery. Custom fields migrate as Epicor User-Defined (UD) table extensions (UD fields on the target business object). Epicor's UD field system is extensible from the UI, but we pre-define the schema in a sandbox migration run so that the migration script references the correct field names. UD field types must match (character vs numeric vs date) during import.

ORCA Financial stores open and closed accounting periods. We map these to Epicor Fiscal Year and Fiscal Period records scoped to the target Company. Closed periods in ORCA Financial are created as closed Fiscal Periods in Epicor with a period status flag preventing new postings. Open periods are created as open Fiscal Periods. We flag any non-standard period assignments (e.g., 13-period years, seasonal calendars) as requiring manual Epicor fiscal calendar configuration before AP/AR migration begins.

If ORCA Financial stores vendor-specific item costs or customer-specific pricing, we map these to Epicor PartPlantCost records (vendor unit cost per part) and Epicor SupplierPriceList records (contract pricing per vendor-part combination). Customer-specific pricing migrates to Epicor PriceLbr records and PricePerf records tied to the Part and Customer. We flag any volume-break or tiered pricing structures as requiring post-migration Epicor pricing rule configuration.