Migrate from MONITOR ERP to Epicor Prophet 21

MONITOR Customer records map to Epicor Kinetic Customer (CustCnt/CustForm records). We extract address, contact, currency, payment terms, and credit limits from the MONITOR export and map to Epicor Customer with CustID as the dedupe key. Ship-to and Bill-to addresses become separate ShipTo records under the same CustNum. Currency codes map from MONITOR's currency table to Epicor's CashCurrency table.

MONITOR Supplier records map to Epicor Kinetic Supplier (Supplier table). The supplier address, contact, currency, and payment terms structure mirrors the Customer mapping. Purchase Order history from MONITOR Supplier records maps to Epicor PurAgent and PODetail with status resolved against open/closed flags in MONITOR.

MONITOR Items map to Epicor Kinetic Part records. The Item number becomes PartNum; description, unit of measure, and cost fields migrate directly. MONITOR's BOM links (parent item to component items with quantities and operations) map to Epicor PartMtl records where the parent Part is the assembly and the component PartMtl records represent the BOM lines. We preserve BOM revision versions as RevDescription and effective date fields on the PartRev table.

MONITOR BOMs with multiple levels require recursive explosion before import into Epicor. Each BOM level becomes a separate PartMtl record where MtlSeq and QtyPer migrate from MONITOR's BOM line data. We flag any MONITOR BOMs with phantom assemblies and replicate those as PartMtl records with material type set to Phantom. The PartRev table holds revision information; we map MONITOR BOM revision effective dates to RevDate on PartRev.

MONITOR routing data attached to Production Orders maps to Epicor JobOper (operation lines) under a parent JobMtl record. Each MONITOR operation with work-centre, labor hours, and setup time becomes a JobOper entry with OpCode reference, ProdStandard, and LaborEntryFlag. Work-centre assignments from MONITOR map to Epicor ResourceGroup and Resource records. We decompose MONITOR's sequential operations into JobOper rows with the correct OpSeq sequence values.

MONITOR Production Orders with embedded routing, material picks, and work-centre assignments decompose into Epicor Kinetic JobMtl and JobOper records under a parent JobMtl header. The production order number becomes the JobMtl.JobNum; material picks become JobMtl records with PartNum, MtlSeq, RequiredQty, and IssuedQty; operations become JobOper records with OpCode, Workstation, and labor standards. Lot traceability from MONITOR production orders migrates to PartLot records linked via PartTran entries on the Job.

MONITOR Customer Orders map to Epicor Kinetic Sales Order (OrderHed header and OrderDtl lines). Order number, customer reference, order date, and status migrate to OrderHed; order lines with part number, quantity, unit price, and delivery date migrate to OrderDtl. Open orders in MONITOR with status Pending or Invoiced are flagged to prevent duplicate creation post-cutover. We preserve MONITOR's order total and discount structure in OrderHed.DocDiscountAmt.

MONITOR Purchase Orders map to Epicor Kinetic POHeader and PODetail. Supplier reference, order date, and status migrate to POHeader; line items with part number, quantity, unit cost, and expected delivery migrate to PODetail. Open POs are flagged for reconciliation against Epicor's open PO view. Closed POs are imported with status Close or Canceled based on MONITOR status.

MONITOR AR invoices map to Epicor Kinetic InvcHead and InvcDtl. AP invoices map to APInvHed and APInvDtl. Invoice headers and lines use field-level mapping because MONITOR invoice structures (header with line items, tax, and discount fields) differ from Epicor's split InvcDtl table. We extract open and historical invoices from MONITOR file exports, perform field-level transformation, and map payment terms, currency, and tax codes to Epicor equivalents. Historical invoices are flagged as posted.

MONITOR journal entries export in batches via file system. We map account codes to Epicor GLJrnDtl with debit and credit amounts preserved, posting dates migrated to Ledger Date on GLJrnHed. MONITOR's account-numbering conventions may conflict with Epicor's segment-structured COA; we flag any unmapped account codes during discovery and ask the customer to define the COA segment mapping before journal entry import. Fiscal period validation runs against Epicor's FiscalPeriod table.

MONITOR inventory positions (quantity by Item, Warehouse, Lot/Serial) export as stock reports. We map to Epicor PartBin records where PartNum, WarehouseCode, and BinNum form the composite key. Lot and serial numbers from MONITOR map to PartLot records with LotNum, PartNum, LotDescription, andExpirationDate, linked to PartBin via the lot tracking fields. Warehouse codes from MONITOR map to Epicor Warehse records, which must be configured in Epicor before PartBin import.

MONITOR account codes and descriptions export via file. We map these to Epicor Kinetic GLAccount records with AccountDesc. MONITOR uses numeric account codes; Epicor supports segmented COA where account code may include company, division, department, and natural account segments. We define the segment structure during discovery based on the customer's MONITOR account format and Epicor's chart configuration. Natural account type from MONITOR maps to GLAccount.Type.

MONITOR bank and cash accounts export via file paths. We map these to Epicor Kinetic BankAcct records with BankAcctID, BankName, and opening balance reconciled against the latest trial balance from MONITOR. Cash account types map to BankAcct.Type (checking, savings, petty cash). Reconcile flags and bank statement formats are preserved for the customer's Epicor administrator to configure post-migration.

MONITOR User records with login, name, and role assignments map to Epicor Kinetic UserComp and Labor records. Role-based access from MONITOR maps to Epicor Security Manager groups. Employees with labor hour entries in MONITOR map to Epicor Labor records with LaborType and ClockInDate. We resolve the MONITOR user-to-employee relationship during scoping because MONITOR users and employees may be separate record types.