Migrate from ERP BOS to Epicor Prophet 21

ERP BOS Customer records (contact details, billing address, credit limit, account balance) map directly to Epicor Customer. The BOS customer code becomes Epicor's CustID; the customer name becomes CustBT. We preserve BOS credit limit in a custom field and resolve the BOS billing address to Epicor's ShipTo address structure. Inactive accounts are migrated with Inactive flag set; they do not inflate record counts in Epicor's open-order reporting.

ERP BOS Supplier records map to Epicor Vendor. The BOS supplier code becomes Epicor's VendorID; payment terms, tax registration, and banking details map to VendorPP (Vendor Payment Processing) and TaxRegion. We extract the full supplier address as a VendorBT record. Purchasing lead times from BOS supplier records become the PO suggestion parameters in Epicor's vendor master.

ERP BOS Items (both stock and non-stock products) map to Epicor Part records. BOS SKU becomes Part.PartNum; unit of measure from BOS Item UOM converts to Part.IUM and Part.DUM; cost price maps to Part.StdCost. The Part's ClassID is assigned during import based on BOS item category mapping. Non-stock items are imported as Part.TypeCode = NonInventory.

ERP BOS multi-level Bills of Materials require transformation into Epicor's PartMtl (materials per assembly), PartOpr (routing operations), and JobAsmbl (job assembly) structures. We flatten BOS BOM levels during transformation: each BOS BOM header becomes a parent Part in Epicor; each BOS BOM component becomes a PartMtl entry with MtlSeq, PartNum, and QtyPer; each BOS routing step becomes a PartOpr entry with OpSeq, Operation, and Resource Group. Multi-level sub-assemblies in BOS become separate parent Parts in Epicor with their own PartMtl entries. The customer must review and approve the flattened structure before Epicor import because BOM routing steps may require Epicor Resource Group assignment.

ERP BOS hierarchical COA (account codes, descriptions, classification) maps to Epicor GLAccount. BOS account codes become GLAccount.Account; BOS account descriptions become GLAccount.Description; classification (Asset, Liability, Income, Expense) maps to GLAccount.Type. We export the full COA as a structured record set and load it via Epicor's GLAccount entry or direct import. Account balances are loaded separately as GLJrnDtl entries against the opening period.

ERP BOS multi-entity ledgers (one ledger per branch or legal entity) map to Epicor Companies. Each BOS entity becomes a separate Epicor Company with its own Fiscal Year, Calendar, and Chart of Accounts assignment. Inter-company transactions between BOS entities require cross-reference mapping to Epicor Elimination Accounts (GLAccount with type = Elimination) that the customer configures as part of Epicor multi-company setup. We produce an elimination account map during scoping; the customer's finance team and Epicor implementation partner must configure inter-company posting rules before the multi-entity migration is validated.

Outstanding payables and receivables migrate to Epicor APInvoice and ARInvoice as open records. We extract BOS AP/AR sub-ledger balances and reconcile against COA control accounts before migration; discrepancies are flagged in a reconciliation report for the customer to resolve in BOS before we transfer balances. Open AR invoices land as ARInvoice with InvoiceType = Invoice; open AP invoices land as APInvoice with InvoiceType = Invoice. Aged trial balance data migrates as-is so that Epicor's collections and credit management features can operate on the transferred history.

ERP BOS tax codes and rates map to Epicor's TaxRegion (jurisdiction), TaxCode (rate name), and TaxRate (effective rate per jurisdiction). We extract the full BOS tax table during scoping and map it to Epicor's jurisdiction-based tax configuration. Tax groups are built during Epicor configuration by associating TaxCodes with TaxRegions. Customers operating across multiple countries must verify that Epicor's tax engine covers the relevant jurisdictions; Epicor Kinetic includes standard tax rates for major jurisdictions but may require custom tax code setup for South African VAT or specialized local taxes carried over from BOS.

ERP BOS bank accounts and cash ledgers map to Epicor BankAcct. The BOS bank account code becomes BankAcct.BankAcctID; account name becomes BankAcct.Description. Account balances are migrated as opening BankTran entries against the last BOS statement date. Bank reconciliation history from BOS migrates as BankTran records if the customer requires it for audit; Epicor's bank reconciliation module uses these entries to generate reconciliation reports.

Open and recently closed sales orders from ERP BOS migrate to Epicor OrderHed (header) and OrderDtl (lines). BOS order number becomes OrderHed.PONum or a custom reference field; customer code links to the Epicor Customer via OrderHed.CustNum. Order lines map part numbers to OrderDtl with quantity, unit price, and discount. We do not migrate voided or fully invoiced historical orders unless the customer requires them for audit, in which case they are loaded as closed records with the original dates preserved.

Open purchase orders from ERP BOS migrate to Epicor POHeader and PODetail. BOS PO number becomes POHeader.PONum; supplier code links to Epicor Vendor via POHeader.VendorNum. Order lines map part numbers to PODetail with quantity, unit cost, and due date. We do not migrate fully received or fully invoiced historical POs unless required for audit trail purposes. Drop-ship POs from BOS are flagged for Epicor configuration review because drop-ship logic requires separate vendor and customer ShipTo assignment in Epicor.

ERP BOS manufacturing work orders (if present in the source data) migrate to Epicor JobHead, JobMtl, and JobAsmbl. BOS work order number becomes JobHead.JobNum; the parent Part number links to the Part records created during Item/BOM migration. JobMtl entries carry component part numbers, quantities, and issue methods; JobAsmbl entries carry sub-assembly references. Job status from BOS (released, on hold, closed) maps directly to JobHead.JobReleased, JobHead.JobComplete, and JobHead.JobClosed flags. We flag any BOS work orders that reference BOM components not yet migrated as orphan dependencies in the job reconciliation report.

ERP BOS Service Manager records (enquiry tracking and opportunity management) map to Epicor Customer and Contact records for entity association, with open service tickets migrated as Epicor Task records linked to the Customer or Contact. Closed service records are migrated as historical Task records with ActivityDate preserved and TaskStatus set to Completed. We do not migrate BOS-specific service categories that have no Epicor equivalent; these are documented in the mapping notes for the customer's Epicor admin to reassign.

ERP BOS document management module binary blobs do not migrate via the standard export pipeline. We extract document metadata (filename, file type, linked transaction type, transaction ID, created date) and produce a file-index CSV referencing the source blob location. A separate file transfer process handles the binary blobs outside the main data migration to avoid timeout issues with large attachment volumes. The file-index CSV is delivered alongside the migration so that the customer's Epicor admin can link the transferred documents to the corresponding Epicor records (Part, OrderHed, JobHead) using Epicor's Document Management module after go-live.

ERP BOS custom fields on Items map to Epicor User-Defined (UD) fields on the Part table (Part UD01-UD30, or UD fields on PartCost, PartLot, PartWhse). We extract the full BOS item schema during scoping, identify each custom field's data type, and pre-create matching UD fields in Epicor before Part migration begins. UD field setup requires the customer's Epicor admin to configure field labels, data types, and validation rules in Epicor's UD Field Maintenance screen; we document the required UD field list in the migration handoff package.