Migrate from BizeeBuy to Epicor Prophet 21

BizeeBuy Suppliers map to Epicor Vendor records. We extract Supplier headers (name, contact details, sourcing category, performance metadata) and load them into Epicor's Vendor table. Epicor supports multi-site vendor records via VendorPP (payment and bank details) and VendorContact records, which we populate from BizeeBuy's contact objects. If the customer uses BizeeBuy's vendor rating or performance score fields, we preserve those as UD fields on the Vendor record. Vendor is a prerequisite object — it must exist in Epicor before any PO or AP invoice records that reference it.

BizeeBuy POs map to Epicor Purchase Order records (PurAgent/PoHeader + PODetail). PO header fields (PO number, status, approval state, cost-centre assignment) map to PoHeader and its UD fields. Line items map to PODetail with PartNum resolved to Epicor Part, UnitCost carried from BizeeBuy's PO line cost, and VendorNum resolved from the Supplier mapping. BizeeBuy's multi-level approval workflow status migrates as a UD field on PoHeader; Epicor's approval is handled separately through its own approval engine and is not migrated as code.

BizeeBuy GRNs are the three-way match anchor in the payable workflow. We map GRN headers to Epicor Receipt records, linking to the matched PO via PONum. Line-level GRN data maps to ReceiptDtl with PartNum, ReceivedQty, and UOM resolved. The GRN's match state (matched to PO and invoice, partially matched, or unmatched) migrates as a UD field since Epicor's three-way matching logic is a payable configuration rather than a record field. If BizeeBuy stores receipt dates and inspector references, those land in ReceiptDtl CommentText and the UD field on Receipt.

BizeeBuy Items (SKU, unit of measure, cost, category, variant or bundle structure) map to Epicor Part records. We flatten BizeeBuy bundle or kit structures into Epicor Part and its PartCmdb (if the bundle is configurable) or into a flat structure with BOM relationships created separately. The BizeeBuy unit of measure maps to Epicor UOM. If BizeeBuy stores cost as a purchase cost, that value goes into Part.PurchasingFactor or a UD field for the customer's sourcing team. Part must be loaded before any PO lines, BOMs, or Jobs that reference it.

BizeeBuy Warehouses map to Epicor Plant and Warehouse records. We export warehouse definitions, addresses, and assigned roles (receiving, storage, shipping) from BizeeBuy's warehouse list endpoint. Each BizeeBuy warehouse becomes an Epicor Plant (the operational site) with a corresponding Warehouse record. If the customer uses BizeeBuy's warehouse-level approval or role assignments, those map to Epicor Plant security groups. Multi-warehouse accounts in BizeeBuy map to multiple Plant records in Epicor, and PartBin records are created per Part-Warehouse combination.

BizeeBuy stock levels (quantities, status classifications, FIFO-based pricing per item per warehouse) map to Epicor PartBin records. We export the latest stock snapshot and any movement logs available through the BizeeBuy API and write them as PartBin rows linked to the corresponding Part and Warehouse. FIFO-based pricing from BizeeBuy is stored in a UD field on PartBin because Epicor's standard inventory valuation runs through the costing engine (PartLot, PartTran) rather than a stored unit cost on the bin record. Open PartBin records are a prerequisite for any Job that consumes materials from stock.

BizeeBuy Production Batch records map to Epicor Job records (JobHead for the work order, JobMtl for material consumption, JobOper for operations). Each batch maps to one JobHead with JobNum generated during migration. The batch's linked BOM reference becomes the JobMtl rows with the BOM-level component quantities. Finished-goods output from the batch maps to the JobHead's primary part number and target quantity. Production-linked inventory adjustments (raw material consumption and FG receipt) migrate as PartTran records linked to the JobNum. If BizeeBuy stores batch-specific metadata (batch number, inspector, shift), those land in JobHead UD fields.

BizeeBuy BOMs define multi-level component structures for production. We export the BOM hierarchy, component quantities, and scrap rates from BizeeBuy and translate them into Epicor PartBOM records linked to the finished-goods Part. Nested BizeeBuy BOM levels are flattened into a single PartBOM with multiple PartMtl rows; Epicor's PartBOM structure natively supports one level of materials per assembly, so multi-level BizeeBuy BOMs are decomposed into a set of PartBOM records with the top-level assembly at the top. Scrap rates from BizeeBuy migrate to PartBOM.ShrinkFactor.

BizeeBuy AP records (supplier invoices, payment status, two-way or three-way match results) map to Epicor APInvoiceHed (header) and APInvoiceDtl (lines). Invoice headers carry VendorNum (resolved from Supplier mapping), invoice number, date, total, and match state as a UD field. Lines carry PartNum or description, quantity, unit cost, and extension. The BizeeBuy three-way match outcome (matched, partially matched, unmatched) is preserved in a UD field on APInvoiceHed since Epicor's matching logic is a payable configuration rather than a record attribute. We do not migrate payment history or closed invoices unless required for reporting continuity.

BizeeBuy Cost Centers and budget allocations drive procurement approval routing. We export the cost-center hierarchy and active budget balances from BizeeBuy. These map to Epicor Department (financial reporting dimension) and Company (org-level) structures, or to a custom UD field on PoHeader if the customer uses BizeeBuy's cost-centre approval routing to control purchasing limits. The mapping is customer-specific because Epicor does not have a native cost-centre object at the level of granularity BizeeBuy uses for procurement controls. We document the cost-centre structure and recommend whether to use Epicor's native Department or a custom UD-based approach.

If BizeeBuy holds Sales Order records, they map to Epicor OrderHed (order header) and OrderDtl (order lines). OrderHed fields (order number, customer reference, date, status) map directly. OrderDtl carries PartNum (resolved from the Part mapping), OrderQty, UnitPrice, and extension. BizeeBuy orders linked to Production Batches map their linked batch number to a UD field on OrderDtl for traceability. If BizeeBuy tracks sales order approvals, those migrate as UD fields rather than Epicor native workflow rules.

BizeeBuy supports custom fields on core entities but does not expose a dedicated custom-field schema endpoint. We infer custom field presence from record payloads during discovery and map them to Epicor UD fields on the corresponding table (e.g., PartUD for Part-level custom fields, JobHead_c for Job-level custom fields). Epicor UD fields are free-form columns added to the base table. The customer defines the field names and data types in Epicor during schema design, and we map BizeeBuy's inferred custom values into those columns. If BizeeBuy custom fields use picklist or enumeration values, we create Epicor combo-box or list-type UD fields and map the values explicitly.

BizeeBuy does not expose a public user management API. User accounts, role-based permissions, and approval-chain assignments cannot be extracted programmatically and must be recreated manually in Epicor Kinetic or Prophet 21 using Epicor Identity Manager. We deliver a written role matrix template that maps BizeeBuy user roles and permission levels to Epicor security groups, Plant access scopes, and module-level permissions so the customer's admin has a checklist for provisioning.