Migrate from Decision Builder to Epicor Prophet 21

Decision Builder Customer records map to Epicor Kinetic's party-based architecture where the same Party record can hold both Customer and Vendor roles. We split the flat Decision Builder Customer into a Company record (Party), an Address record (address fields), and a Contact record (contact details). The Company Number from Decision Builder becomes Epicor's CustNum; the customer's pricing tier becomes a UD field or Epicor price group. Account hierarchies in Decision Builder map to Epicor's Parent Customer relationship.

Decision Builder Vendor records map to Epicor Kinetic Party records with the Vendor role. Tax IDs, payment terms, and remittance addresses extract from Decision Builder and load into Epicor's Vendor table via DMT. The Vendor ID from Decision Builder becomes Epicor's VendorNum as the dedupe key. Where Decision Builder stores a vendor's primary contact separately, we create a matching Contact record linked to the same Party.

Decision Builder Items (inventory, non-inventory, and service types) map to Epicor Kinetic Part records. Item Type in Decision Builder determines Part.TypeCode in Epicor (stocked, non-stock, or service). The Decision Builder part number maps to Epicor Part.Number; the Description and UOM map to Part.Description and Part.IUM. Multi-level Bill of Materials in Decision Builder require BOM and JobAsmbl setup in Epicor before Jobs can be created — we flag this as a prerequisite during scoping.

Open invoices, credit memos, and payment records migrate to Epicor APInvoice, ARCInvoice, and CashHead tables. Document numbers, invoice dates, due dates, amounts, and aging buckets preserve from Decision Builder. Vendor and customer references resolve to the Epicor Party and Company records created in the earlier import phase. Post-import reconciliation in Epicor's AP and AR modules closes the migration loop and verifies that open balances match the Decision Builder source report.

Invoice history, payment records, and adjustment logs migrate with full audit trails to Epicor InvcHead and InvcDtl. Decision Builder journal entries require mapping to Epicor's chart of accounts, which may use a different segment structure and account numbering scheme. We flag the account mapping session as a required pre-migration step. Epicor's fiscal period validation may reject transactions with dates outside the open accounting period, requiring a post-open-period adjustment journal setup in Epicor before historical transactions can post.

Account structures including segment definitions, account types, and rollup hierarchies migrate to Epicor GLAccount. Decision Builder's account numbering convention maps to Epicor's GLAccount.Account field, and account types (Asset, Liability, Equity, Revenue, Expense) map to Epicor GLAccount.Type. Multi-segment account structures in Decision Builder require mapping to Epicor's account segments or subaccount concatenation. We run pre-migration account mapping sessions with the customer's finance team to align the frameworks before any transactional data moves.

Decision Builder Projects bundle related Data Structures, rule flows, and workflows. We export Projects via .dec.obj and deliver the full export as a structured configuration inventory: a written catalog of every Project, its constituent Data Structures, the rule flow logic it contains, and the workflow dependencies. Epicor Kinetic does not have a Project equivalent; rule flows map to BPMs and workflows map to Kinetic Business Rules, but these must be manually rebuilt by the customer's Epicor administrator. We do not convert rule flow logic to BPM code.

Decision Builder Data Structures store business-specific data with custom fields. Complex Data Structures require Project-level .dec.obj export to preserve relationships. Epicor Kinetic does not have a Data Structure equivalent; instead, Epicor uses User-Defined (UD) columns within standard tables. We document each Decision Builder Data Structure as a configuration item: the fields it contains, the data types, and the recommended Epicor UD column mapping. UD columns must be pre-created in Epicor before data import. We deliver the UD column schema as part of the Epicor configuration documentation.

Decision Builder User accounts and role assignments map to Epicor Kinetic User records. We match by email address as the dedupe key. Role and permission mappings from Decision Builder become Epicor User security groups and row-level access rules. Active versus inactive status preserves; login credentials do not transfer for security reasons. Any Decision Builder user without a matching Epicor User record goes to a reconciliation queue for the customer's admin to provision.

Documents and file attachments in Decision Builder migrate alongside their parent records (Customer, Vendor, Item, or Project). We verify file integrity after transfer using checksums. Documents referencing orphaned parent records — objects not included in the migration scope — are flagged in the reconciliation report for the customer to address manually. Epicor's DocumentVault accepts files via REST API or DMT, preserving the original filename and MIME type.

Decision Builder production job records map to Epicor Kinetic JobProd records with associated LaborDtl (labor detail) entries. BOM and routing must exist in Epicor before JobProd records can be created; we flag BOM and routing migration as a prerequisite step during scoping. WIP (work-in-process) quantities migrate to Epicor's JobProd as open quantities. Production history (completed jobs, scrap, and yield) migrates to Epicor LaborDtl and JobHead records.

Open and history Purchase Orders from Decision Builder map to Epicor Kinetic POPOHeader and POPOLine records. PO number, vendor reference, line items, quantities, prices, and terms migrate. POLines resolve to Epicor Part records (for stocked items) or to Expense categories (for non-stock items). Closed and cancelled POs migrate to Epicor's PO history tables with status preserved. Epicor's DMT includes a POPORecvImport template for receiving records linked to open POs.

Decision Builder sales orders and quotes map to Epicor Kinetic OrderHed/OrderDtl and QuoteHed/QuoteDtl records. Open orders migrate with status preserved; cancelled and completed orders migrate to history. Order and quote lines resolve to Epicor Part records for pricing. Customer and ship-to addresses resolve to the Epicor Party and Address records created during the master data phase. Epicor Configure-to-Order (CTO) quotes require prior setup of the product configurator in Epicor before migrated CTO quotes can be edited.