Migrate from Masterplan to Epicor Prophet 21

Masterplan Customer records map to Epicor Customer with full billing/shipping addresses, payment terms, credit limits, and currency settings preserved. The Masterplan customer number becomes Epicor CustomerID; the customer name becomes CustName. We flag any Masterplan customers marked inactive so they import as Customer records with the Inactive flag set in Epicor rather than being excluded. Customer ERP codes and region assignments map to Epicor's territory and sales rep assignment fields.

Masterplan Vendor records map to Epicor Vendor with address, payment terms, W-9 data, and 1099 eligibility flags. The Masterplan vendor number becomes Epicor VendorID. We preserve the 1099 eligibility flag in a custom field if Epicor's standard vendor form does not expose it directly, and we flag any vendors without active purchase orders for the customer to review before reactivation in Epicor.

Masterplan Items—Finished Goods, Raw Materials, Components, and Services—map to Epicor Part records with the item type preserved as PartType (M=Stocked, K=Kit, S=Service, P=Non-stock). Masterplan costing methods map to Epicor CostingMethod (A=Average, S=Standard, L=Last, 1=FIFO). We extract the unit of measure from Masterplan and create matching UOM records in Epicor before Part import so that the UOMClass relationship is satisfied at insert time.

Masterplan GL Account records (account number, name, type, department rollups, cost center associations) map to Epicor GL Account with natural account segment mapping to the account segment in Epicor's chart of accounts structure. We preserve the full account hierarchy including any inactive accounts so that historical journal entry references remain valid in Epicor. Department and cost center rollups from Masterplan map to Epicor reporting dimensions if the customer has reporting dimensional analysis enabled.

Outstanding Masterplan payables and receivables—invoice number, amount, due date, aging bucket—map to Epicor APInvoiceHed and ARInvoiceHed records. We normalize Masterplan aging buckets to standard 30/60/90/120-day buckets at extraction time because aging configurations vary by Masterplan customer. Invoice status (Open, Partial, Paid) maps to Epicor's invoice hold and approval workflow flags. We flag invoices with mismatched vendor or customer IDs for manual resolution before posting.

Masterplan Sales Order headers map to Epicor OrderHed with order number, customer reference, terms, and ship date. Line items map to OrderDtl with part number, quantity, unit price, and warehouse assignment. Partially shipped orders from Masterplan are flagged explicitly so that Epicor's order fulfillment logic handles the remaining quantity correctly post-cutover. We extract the order history cutoff in coordination with the Masterplan vendor to exclude fully invoiced and closed orders unless the customer requests historical order records.

Masterplan Purchase Order headers map to Epicor POHeader with vendor reference, terms, and expected receipt date. Line items map to PODetail with part number, quantity ordered, unit cost, and warehouse assignment. Partially received orders are flagged so that Epicor's receiving workflow handles the open quantity correctly. We extract PO history cutoff in coordination with the Masterplan vendor to exclude fully received and closed purchase orders unless historical record preservation is requested.

Masterplan on-hand quantities by warehouse and bin map to Epicor PartBin records. We extract stock levels per location and map to the destination Epicor warehouse structure, which often differs from Masterplan's warehouse configuration. Quantity on hand, allocated quantity, and available quantity migrate separately so that Epicor's allocation logic does not miscalculate during the initial inventory verification cycle. Bin-level precision requires Epicor warehouse configuration to be completed before PartBin import.

Masterplan multi-level BOMs with component quantities, scrap factors, and phantom assemblies require explicit handling. We extract the full BOM tree and assess whether Epicor requires flattening (for phantom assemblies) or preservation (for nested BOMs with revision control). Epicor's PartRev records control revision branching and approval status. We create BOMHead and BOMDetail records for each Masterplan BOM, and we flag any BOM with scrap factors so that Epicor's job material estimation handles the scrap percentage correctly. BOMs must import after Parts because PartRev references Part records.

Masterplan Work Order status (Released, In Process, Complete, Closed), routing steps, labor hours, and material allocations map to Epicor JobHead (job header), JobMtl (job material), and JobOper (job operation) records. We preserve the full status history and associate backflush transactions with the correct job. Open jobs (Released, In Process) are imported as active Epicor jobs; completed and closed jobs are imported as historical records if the customer's Epicor configuration supports job history retention. JobOper references PartRev for BOM revision, so BOM import must precede or accompany Work Order import.

Masterplan journal entries map to Epicor GLJrnHed and GLJrnLine records for financial history preservation. We scope the journal entry lookback window explicitly with the customer before extraction because Masterplan may archive entries older than a configurable cutoff. Locked fiscal periods in Epicor require the GL journal import to respect period close boundaries; entries for closed periods are excluded or held for manual posting after Epicor admin review.

Masterplan custom fields on standard objects are not publicly documented, so we enumerate any discovered custom fields during discovery sessions with the customer and vendor. Epicor supports user-defined fields on standard tables (OrderHed, JobHead, Part, etc.) via UD Column Map in Epicor Data Tools. We map each confirmed Masterplan custom field to a corresponding Epicor UD field, pre-creating the UD column definitions before data import. Any Masterplan custom fields without vendor-confirmed definitions are flagged as excluded from migration scope in the data map.