Migrate from Foundry Bean to Epicor Prophet 21

Foundry Bean organizes accounts by Balance Sheet and Income Statement categories automatically; Epicor GL Account uses a structured account code segment with type, description, and posting restrictions. We map each Foundry Bean account code and account type to a corresponding Epicor GL Account with the same natural balance. If Foundry Bean's multi-subsidiary chart uses per-entity prefixes, we resolve them into Epicor's Company segment or account code convention during the mapping pass.

Foundry Bean customer records include addresses, contacts, payment terms, and linkage to invoices and receivables. Epicor Customer is the equivalent master record with ShipTo, BillTo, and Credit Limit fields. We map the customer number, name, payment terms, and currency from Foundry Bean and preserve the open AR balance as an initial invoice record in Epicor AR. Custom address fields require explicit value mapping to Epicor's address book structure (Country, State, PostalCode, Address1, Address2, Address3).

Foundry Bean vendor records contain addresses, banking details, purchase order terms, and contract linkage. Epicor Supplier is the equivalent master record. We map vendor number, name, payment terms, and currency, and preserve open AP balances as initial invoice records. Foundry Bean's expense report-to-vendor-invoice auto-conversion requires us to suppress the duplicate AP entry that would otherwise be created from the same source document upon import.

Foundry Bean Items track inventory across multiple warehouses with costing methods and pricing tiers. Epicor Part is the equivalent with PartNum, PartDescription, TypeCode (Stock, Non-Stock, Service), UOMClass, and costing method (Standard, Average, FIFO). We map item numbers and costing methods directly, and flag custom pricing tiers for review. For any item that serves as a BOM component in Foundry Bean, we map it to Epicor Part and flag it for BOM association during the Bill of Material import phase.

Epicor stores BOMs as PartRevision records with child PartMtl rows specifying the parent part, material part, quantity per, and operation sequence. Foundry Bean's BOM support (if applicable) maps directly here. Multi-level BOMs require parent-part lookup resolution in Epicor before child material rows are inserted; we sequence the import to ensure parent parts exist before material lines reference them. Phantom assemblies and substitute parts use Epicor PartMtl flags. We do not migrate BOM routing operations as code; we deliver the routing structure as a written map for the customer's Epicor admin to configure in Job Routing.

Foundry Bean sales invoices link to customers, items, and payment records. Epicor AR Invoice is the standard invoice record. We preserve invoice-to-payment linkages, invoice status, and aging data, mapping Foundry Bean's invoice lifecycle states to Epicor's status field (Open, Partially Paid, Closed). Historical invoices migrate as posted records; open invoices migrate with their remaining balance and aging bucket assignments intact.

Foundry Bean vendor invoices and approved expense report conversions migrate to Epicor AP Invoice. We import only the source expense report record with its settlement state before auto-conversion fires, and suppress the duplicate invoice record that Foundry Bean would otherwise generate. AP Invoice lines link to Supplier, Invoice Number, and GL Account for each line distribution.

Foundry Bean subscriptions with flat-fee and usage-based pricing map to Epicor's recurring invoice schedules or contract billing lines. Tiered pricing requires flattening: each tier range (start threshold, end threshold, per-unit rate) becomes an individual price break record in Epicor's quantity-based pricing table. We flag any subscription with tier stacking or consumption-based billing for manual configuration review in Epicor.

Foundry Bean contracts link to subscription billing and revenue recognition schedules. We map contract ID, terms, start and end dates, and recognition method. The ASC 606 recognition method (time-based or milestone-based) is configured in Epicor's revenue recognition module at the contract level after the underlying contract and billing data is loaded. Revenue schedules are recalculated in Epicor from contract terms rather than migrated as derived records.

Foundry Bean's revenue recognition schedules are generated by the platform from contract terms and subscription billing. Because these are derived records, we do not attempt direct migration. Instead, we export the underlying contract data and billing schedule from Foundry Bean, and use those to configure Epicor's ASC 606 revenue recognition module. We deliver a written ASC 606 configuration map that the customer's Epicor admin implements post-migration.

Foundry Bean purchase orders link vendors to items and drive invoice processing. Epicor PO Header and POLine are the equivalent records. We migrate open and closed PO history, preserving the PO-to-invoice relationship for the procure-to-pay audit trail. PO line release quantities and received amounts map to Epicor's POLine to maintain the receipt history.

Foundry Bean employee records include compensation history, benefits, and organizational assignments. Epicor HR Employee stores similar fields with effective-dated changes tracked per record. We sequence migration as current employee state first (name, department, job title, employment status, manager linkage), then apply historical compensation effective-dated records. Employee banking details map to Epicor's payroll setup if Epicor Payroll is in scope.

Foundry Bean bank and credit card accounts with real-time balance tracking and auto-reconciliation map to Epicor Cash Account or BankFee. We map account numbers, bank details, and opening balances to the destination cash management module. Bank reconciliation history migrates as GL Journal entries that reconstruct the original reconciliation timeline in Epicor.

Foundry Bean's full GL transaction history from bank reconciliation, invoice processing, and manual journal entries migrates to Epicor GL Journal Entry with full debit-credit preservation. Adjustment entries and closing entries migrate with their source reference. We set the JournalCode, FiscalYear, FiscalPeriod, and JournalLine debits and credits from the Foundry Bean source. Large GL histories (over 100,000 entries) use Epicor's batch import with batch headers per source module.