Migrate from Extensiv Order Manager to Epicor Prophet 21

Extensiv Orders map to Epicor SalesOrderHdr and SalesOrderDtl records. Order number from Extensiv becomes OrderNum in Epicor; channel source becomes an Order Held or Order Release flag based on Extensiv status. Order-level custom Order Info fields map to Epicor UD fields on SalesOrderHed (String01-30 or equivalent). Handling fees and shipping costs migrate as Miscellaneous charges on the Order with appropriate Freq Misc Charge codes. Warehouse assignment on each line item resolves to the corresponding Epicor Site and Warehouse code during import.

Extensiv Customer records map to Epicor Customer. The customer name, contact email, phone, and address fields map directly. We resolve multi-address records (billing vs shipping) to Epicor's ShipTo and BillTo structures. Extensiv customer-level custom fields migrate to Epicor Customer UD fields. Customer currency from Extensiv maps to Epicor's CurrencyCode if the customer operates in multiple currencies.

Extensiv Products map to Epicor Part. SKU becomes PartNum; product name becomes Description; description field becomes PartDescription. Unit of Measure from Extensiv maps to Epicor's UOMClass and UOMCode. Cost from Extensiv (including FIFO cost basis where exposed via API) migrates to Epicor's Standard Cost or Average Cost field depending on the destination company's cost method configuration. Price migrates to PartPlant Unit Price or the default Price List entry.

Extensiv stores inventory per warehouse as distinct quantity positions. Each Extensiv warehouse maps to an Epicor Site and Warehouse combination. We split the Extensiv inventory snapshot into separate PartBin records per Site, preserving on-hand quantity, allocated quantity, and available quantity. Customers must confirm which warehouse's Extensiv inventory levels are canonical for each Epicor Site before migration begins. Open purchase orders and stock transfers in Extensiv create separate inbound visibility records in Epicor.

Extensiv Shipment records preserve carrier, tracking number, shipment date, and shipping cost. We link shipments to the originating Extensiv Order number and map them into Epicor's Shipment or Order history depending on whether the destination Epicor product line uses Order Entry or Sales Order modules. Tracking URLs and carrier codes migrate to ShipmentHead UD fields or OrderDtl tracking notes.

Extensiv Warehouse records (in-house and 3PL) map to Epicor Site definitions with associated Warehouse records. In-house warehouses migrate as Epicor Sites with Warehouse codes. 3PL warehouses from Extensiv map to Epicor Warehouses or are documented as external Third-Party Logistics sites depending on whether Epicor's 3PL module is licensed. We validate that Site codes and Warehouse codes in the migration payload exactly match the Epicor configuration before import to avoid the Warehouse Name or Warehouse ID errors common in OMS-to-ERP migrations.

Extensiv Purchase Orders map to Epicor PurAgent and POPOHeader with POPORel line releases. PO status from Extensiv (Open, Closed, Cancelled) maps to Epicor OpenFlag and Approval status. Vendor reference and line items migrate with unit cost and delivery dates preserved. Inbound receipt records from Extensiv map to Epicor PORcpt records linked to the PO.

Extensiv Stock Transfers (cross-warehouse moves) map to Epicor TransferOrder records with source and destination Site/Warehouse assignments. Transfer status, line items, and quantities migrate directly. We preserve the transfer order number from Extensiv for audit trail purposes. If the destination Epicor does not use Transfer Orders, the transfers are documented as PartTran records for inventory movement history.

Extensiv bundle and kit products require BOM configuration in Epicor before migration begins. Each bundle product in Extensiv (with its parent SKU and component-level SKU relationships) maps to an Epicor PartBillMtl BOM structure. We preserve component quantities, pricing overrides, and the BOM revision level. Epicor BOMs support revision control, scrap rates, and alternate materials that Extensiv does not model; these are documented during discovery for the customer's Epicor admin to configure post-migration. The BOM revision must be marked Approved before Epicor will explode the kit on a sales order.

Extensiv Custom Order Info fields on orders require two pre-conditions before migration: the 'Enable custom fields' setting must be active in Extensiv Admin > Settings, and corresponding UD fields must be pre-created in Epicor SalesOrderHed with matching data types. We confirm the Extensiv setting is active during discovery and document any unmapped custom fields if it is not. Epicor UD fields are created during the schema design phase in the Sandbox environment before production migration begins.

Extensiv line-item-level custom fields migrate to Epicor SalesOrderDtl UD fields. Like order-level custom fields, these require the Extensiv admin opt-in and Epicor UD field pre-creation. We map the custom field name and value type to the nearest Epicor UD field data type (string, integer, decimal, checkbox) and flag any fields that require a picklist or validation rule in Epicor that did not exist in Extensiv.

Pre-configured custom fields under Extensiv Customers migrate to Epicor Customer UD fields. These require the same Extensiv admin opt-in and Epicor UD field pre-creation as order-level custom fields. Customer-level custom fields in Extensiv are often used for credit limits, tax exemptions, or account-specific pricing tiers; we document these during discovery and map them to equivalent Epicor Customer fields or UD fields based on the customer's Epicor configuration.