Migrate from Opto to Epicor Prophet 21

Opto Items (SKU, name, description, unit cost, reorder point, lead time) map directly to Epicor Part. The Opto Item code becomes PartNum, description maps to Part.Description, and unit cost maps to the primary PartCost record. Where Opto stores a barcode, we map it to Part.AltMethod or a custom UD field. If the destination Epicor uses a specific company-level costing method (Average, Standard, FIFO), we align the PartCost records accordingly during import. Standard UOMs from Opto become PartUOM records with UOMCode and ConversionFactor.

Opto Customer records (contact name, email, phone, billing address) map to Epicor Customer. The Opto customer name becomes Customer.Name, email maps to a UD field or Contact record email, and billing address maps to Customer.BTAddress fields. Customer-specific pricing tiers from Opto migrate to Epicor PartPlant records or PriceLbr records if the destination has customer-specific price lists configured.

Opto Vendors (supplier name, contact, payment terms, lead time) map directly to Epicor Vendor. Vendor.Name maps from Opto supplier name, Vendor.PaymentTerms maps from payment terms, and Vendor.LeadTime maps from Opto's per-Item lead-time data when the Item-Vendor link is present. We extract the full vendor contact record (phone, email, address) and map to VendorPP (VendorPP) or the primary VendorContact record in Epicor.

Opto multi-location inventory with named bins or warehouses splits into Epicor PartBin records. Each unique Opto Stock Location becomes a PartBin with WarehouseCode and BinNum resolved from the Opto location name hierarchy. If Opto stores a nested location (e.g., Warehouse-A / Zone-B / Bin-03), we preserve the full path as BinNum and set a default WarehouseCode. Part quantity per location maps to PartBin.OnHandQty. This is a 1:N split because one Opto Item at one location produces one PartBin row; the same Item at five locations produces five PartBin rows.

Opto Purchase Orders (Vendor, Items, quantities, expected delivery dates) map to Epicor POHeader and POLine records. The Opto PO number becomes POHeader.PONum, VendorID resolves via the Vendor mapping, and each line maps as a separate POLine with PartNum, OrderQty, DueDate, and UnitCost. Open Purchase Orders (status not closed) are candidates for migration; closed POs are documented as historical reference. Epicor's approval workflow on POHeader must be configured or bypassed during migration to allow imported records to enter at the correct status.

Opto Reorder Rules define per-Item minimum thresholds and reorder quantities — these are account-level configuration, not transactional records. We export them as a structured CSV with Item number, minimum quantity, reorder quantity, and reorder method. This CSV is delivered as a reference table in the mapping worksheet. The customer manually re-enters these as Part.Planning_alert or Epicor's MRP/ATP settings, or configures a BPM to trigger PO generation from the threshold. We do not migrate configuration as code.

Open and historical Opto invoices map to Epicor InvcHead and InvcDtl. Open invoices (status open, partially paid) are candidates for re-creation at Epicor with the correct customer, line items, amounts, and payment status. Closed invoices are migrated as historical records for reporting continuity but flagged with a closed status and posting date. We separate open from closed invoices at the start of migration so that open items receive the full Epicor AR treatment (aging, dunning, payment application) while historical records are read-only.

Opto accounts payable invoices map to Epicor APInvoice and APInvoiceDtl. Open AP invoices (not yet paid) are re-created with VendorID, invoice number, invoice date, due date, and line amounts. Historical paid AP invoices migrate for GL continuity. We reconcile vendor payment terms against Epicor's TermsCode table during mapping so that DueDate and DiscountDueDate on APInvoice are correctly populated from the original Opto vendor terms.

Opto Items frequently carry custom fields unique to the account. We extract the full custom-field schema during discovery, identify the Epicor Part UD table that matches (UD05, UD06, etc.), and map each custom field to a typed UD column (character, number, date, checkbox). Epicor's ZDataTable adapter manages UD field definitions; we configure UD01-UD08 labels and data types via Epicor REST before Part import begins. Fields with no Epicor equivalent are flagged in the mapping worksheet for the customer's admin to evaluate post-migration.

Opto Customer custom fields (e.g., customer-specific flags, internal references, custom pricing tiers) map to Epicor Customer UD fields via the Customer UD table. We extract the custom field definition, map to the matching UD column type in Epicor, and load during Customer import. Fields without an Epicor equivalent are documented for manual evaluation.

Opto's barcode-to-Item associations are extracted as a separate mapping table. Epicor stores barcode data in the Part table (via AltMethod or a UD field), or uses a separate BarcodeSym record linked to Part. We resolve the correct destination field based on the Epicor edition and configuration. If the customer uses Epicor's barcode scanning module, we create BarcodeSym records during Part import. Otherwise, we preserve the barcode association in a Part UD field.

Opto's accounts receivable and accounts payable references link to a chart-of-accounts structure. Where Opto uses a simplified account schema, Epicor maintains a full GL chart with AccountType, Segment values, and Natural Account. We map Opto account codes to Epicor GL Account segments during discovery and build a pre-migration GL mapping worksheet. This ensures that AR and AP invoices land in the correct natural account so that AR/AP reconciliation in Epicor matches the pre-migration trial balance.