Migrate from Datacor ERP to Epicor Prophet 21

Datacor Items carry formula data, BOM versions, multi-level BOM structures with co-products and by-products, unit-of-measure conversions, and shelf-life metadata that require decomposition before Epicor import. We extract the full item hierarchy, decompose multi-level BOMs into Epicor Job and JobMtl records, and map shelf-life metadata to Part.ldm fields and PartWh.Re防腐 information. UOM conversions from Datacor's multi-UOM structure map to Epicor's PartUOM table. Formula data and hazard classifications do not map to standard Epicor fields and are stored in custom UD fields or as part notes for the customer's Epicor admin to review.

Datacor's cradle-to-grave lot tracking is a core strength we preserve. We extract the full lot genealogy chain including parent lots, co-products, by-products, and downstream consumption records. Dates, statuses, locations, and lot attributes migrate to Epicor PartLot with LotNum, LotDescription, BatchQty, MfgBatchQty, and expiration dates mapped to PartLot.LotExpirationDate. Lot traceability records from production consumption and shipment linking migrate to LotTracker or custom UD tables in Epicor for audit trail continuity.

Datacor Customers include customer-specific pricing (CUPS matrix), credit limits, discount schedules, and multi-address support. We extract the full CUPS pricing matrix and map it to Epicor Customer PriceLns and Quantity Price Breaks per customer-part combination. Multi-address customers in Datacor map to one Customer record with multiple ShipTo records. Credit limits and discount schedules migrate as Customer-level overrides or to the price list model.

Datacor Vendor records carry CUPS (Complex Unit Price Schedules), rebate logic, and multi-source purchasing flags. We map these to Epicor Supplier records with the purchasing multi-source flag preserved as a SupplierAttribute or UD field. Rebate logic does not have a native Epicor equivalent and is documented as a configuration task for the customer's Epicor administrator to implement via BPM or a pricing integration.

Open Purchase Orders must be mapped by header and line item with delivery schedules. We flag partially-received POs and either close them formally in Datacor before migration or hold them open as exceptions to be re-created manually in Epicor Kinetic after cutover. PO line statuses, quantities, and delivery dates migrate to Epicor POLine with LineNum and ReleaseNbr sequences preserved for partial receipt continuity.

Datacor Sales Order headers and lines carry customer-product pricing, freight terms, and shipping method logic tied to Datacor's truck routing module. We extract open orders by status, map OrderHed and OrderDtl records to Epicor Order Management, and preserve freight terms and shipping method flags as custom OrderHed fields. Orders with partial shipment history flag for the customer to decide whether to close or carry forward. Epicor DMT OrderHed and OrderDlt templates are sequenced so header records are created before line records.

Datacor batch production orders include formula versions, scheduled start/end times, and consumption/yield records. We run all in-process batches to completion or formal closure before migration day because mid-process batches cannot be safely cut over without creating orphaned lot records. Completed batches with yield and consumption data migrate to Epicor Job records with JobMtl (material consumption) and JobOper (operation steps). Formula version tracking maps to JobHead Mickup and PartRev revision control in Epicor.

QC inspection records in Datacor link to lots and items with disposition decisions and certificate-of-analysis data. We extract the full inspection history, disposition codes, and CoA records and map them to Epicor's QCD审 (inspections) and QCData (measurement results) tables. Lot-level inspection status from Datacor maps to Epicor PartLot.QCInProcess or rejection status flags. Non-conformance records migrate to Epicor's MES non-conformance module or custom UD tables.

Datacor's GL structure with accounts, departments, cost centers, and journal entry history migrates directly to Epicor GLAccount and GLBook. We map the account hierarchy, preserve posting dates and amounts for historical financial data, and handle multi-company or multi-entity consolidation accounts from Datacor as separate GLBook or Segment codes in Epicor. Account segments from Datacor's cost center structure map to Epicor's GL Account Segment fields.

Open AR records with payment terms, discount schedules, and outstanding credits migrate as open invoices in Epicor AR. We flag records with outstanding credits, holds, or disputed status as exceptions requiring manual resolution. Payment terms and discount schedules from Datacor map to Epicor PaymentTerms and ARAdjust records. Credit memos migrate separately to Epicor CreditMemo records.

Open AP records with payment terms and discount schedules migrate to Epicor APOpen. Vendor credits and holds are flagged as exceptions for manual resolution. Datacor's multi-vendor payment terms and discount schedules map to Epicor PaymentTerms and APTran records. Partially-invoiced POs with outstanding AP balances require coordinated resolution against the PO mapping in object 5.

Datacor equipment records with maintenance schedules, work orders, and asset specifications migrate as Asset records in Epicor with associated AssetMaint and AssetDowntime records. Equipment specifications, manufacturer, serial number, and location data from Datacor map to Epicor Asset fields. Maintenance schedules (preventive, corrective) migrate as AssetMaint records with next and last maintenance dates preserved. Work orders become Epicor Job records with a maintenance job type.

Datacor's SDS records are regulatory artifacts that do not migrate as documents. We extract the item-to-SDS linkage table (ItemNumber to SDSRecordID) and document it as a mapping reference. The customer's Epicor administrator re-links Items to SDS records in Epicor's document management system post-migration. This is a manual, documented step that must be budgeted for and is outside the automated migration scope.