Migrate from VIENNA Advantage to Epicor Prophet 21

VIENNA Advantage Business Partners are a unified entity covering customers, vendors, and employees with a BP Type classification field (CUSTOMER, VENDOR, EMPLOYEE). We split during transform: CUSTOMER-type BPs create Epicor Customer records; VENDOR-type BPs create Epicor Vendor records; EMPLOYEE-type BPs create Epicor Employee records. Address, contact, payment term, and credit limit fields map to the corresponding Epicor customer or vendor detail tables. Multi-address BPs with distinct ship-to and bill-to roles create separate Customer records with the ShipTo or BillTo role flag. The original VIENNA BP ID is preserved in a custom field va_bp_id__c for audit and reconciliation.

VIENNA Products map to Epicor Part records with PartNum, Description, UnitOfMeasure, ProductCode (SKU), and the IsMake, IsBuy, and TypeCode flags. The BOM linkage for manufactured items migrates as Epicor JobMtl and PartMtl records with the parent PartNum reference. VIENNA's UOM conversion table maps to Epicor's UOMClass and UOM definitions. PartPlant records are created per warehouse to carry on-hand quantities, reorder points, and safety stock levels at the plant-warehouse level.

VIENNA Sales Orders map to Epicor SalesOrder records with OrderNum, OrderDate, CustomerNum, and OrderRel records for each release. Order line items from VIENNA map to OrderDtl with PartNum, SellingQuantity, UnitPrice, and Tax amounts. The VIENNA order status (Draft, Approved, Completed, Cancelled) maps to Epicor OrderHed.OpenOrder and OrderRel.OpenRelease flags. VIENNA's pricing conditions and discount rules require manual mapping to Epicor price lists or must be entered as a post-migration data clean-up step if the conditions are non-standard.

VIENNA Purchase Orders map to Epicor POHeader and PODetail records with VendorNum, PODate, and OrderNum. Line items carry PartNum, POLine.UnitCost, and the PromisedDate from VIENNA's PO lines. VIENNA's goods receipt and invoice matching records do not have a direct Epicor equivalent; we migrate the PO and receipt data separately and flag the purchase accrual reconciliation as a post-migration accounting task.

VIENNA GL Journal Entries map to Epicor GLJrnGrp (batch) and GLJrnLine records with FiscalYear, FiscalPeriod, AccountNum, DebitAmount, and CreditAmount. We chunk migration by fiscal period to avoid API payload limits. Dimension tagging from VIENNA (cost centre, project, department) maps to Epicor's Dimension code structure. Historical closed periods are migrated as read-only archived journal lines; only the current open fiscal period is migrated as live, writable records to maintain Epicor's period controls.

VIENNA Accounts Receivable invoices migrate to Epicor InvcHead and InvcDtl with CustomerNum, InvoiceNum, InvoiceDate, DueDate, and the line-level amounts. Payment records linked to VIENNA invoices migrate as CashHead and CashDtl records that Epicor applies against the corresponding InvcHead. Partial payment matching (overpayment or underpayment) requires explicit mapping of the VIENNA payment identifier to Epicor's payment grouping logic to avoid breaking the AR aging report.

VIENNA Accounts Payable invoices migrate to Epicor InvcHead (AP type) with VendorNum, InvoiceNum, InvoiceDate, and the vendor invoice number. VIENNA's vendor invoice and goods receipt matching pairs map to Epicor's voucher matching workflow as pre-entered InvoiceHed records. Tax amounts from VIENNA's multi-tax configuration migrate to Epicor's TaxDtl records by TaxCode and RateCode lookup.

VIENNA warehouse-level inventory records map to Epicor Warehse (warehouse definition) and PartWhse (plant-warehouse inventory) with OnHandQty, ReorderPoint, SafetyStock, and LotNum where applicable. Expiration dates on lot-controlled items migrate to Epicor's PartLot table. VIENNA's stock movement history migrates as Epicor PartTran records for audit trail completeness, limited to the last 24 months of active movements unless the customer specifies a longer archive window.

VIENNA Projects with phases, assigned resources, billing rules, and time entries map to Epicor Project, ProjectPhase, and ProjectTask records. Billable versus non-billable flags from VIENNA's WBS structure map to Epicor's Billing method and Billing hold fields. Time entries and labour bookings migrate as LabourDtl records linked to the corresponding Project and Phase. Revenue recognition milestones migrate to Epicor's Billing tables for project billing control.

VIENNA DMS documents are stored with internal storage paths encoding module context (Business Partner, Order, Project) and version history. We extract binary files and metadata separately, reconstruct the folder structure, and re-associate documents to Epicor records via the DocType and ForeignKey linkage. Documents exceeding Epicor's attachment size limits or requiring long-term audit retention are migrated to a linked external document archive with a reference pointer stored in Epicor. Failure to re-associate results in orphaned documents with no contextual link, which we actively prevent by maintaining a parent-record lookup table during extraction.

VIENNA custom fields added via the Canvas framework are stored per-module with type, required, and default-value metadata. We extract the full custom field schema alongside the data and map each to the corresponding Epicor UD column definition (UD01-UD20 or extended UD tables). The field type mapping (string, integer, date, boolean, dropdown) is preserved. Custom fields on non-standard VIENNA modules that have no Epicor equivalent are held in a custom staging object with the original VIENNA field name and value for the customer's admin to allocate post-migration.

VIENNA HRM data (employee records, pay structures, time and attendance) migrates to Epicor EmpBasic and related payroll tables where the customer's Epicor deployment includes the HR module. If Epicor HR is not in scope, we extract employee records as a separate CSV deliverable with fields mapped for the customer's HR team to load into their chosen HRMS. Active employment status, department assignment, and supervisor relationships migrate; historical salary review records are archived as read-only data.

VIENNA workflow definitions are stored as declarative rule configurations tied to the specific module context and have no documented export format. We capture screenshots and configuration notes of every active workflow during discovery and deliver a Workflow Reconstruction Handbook to the destination implementation consultant. The customer's Epicor partner rebuilds approval routing and document automation as BPM rules post-migration. Workflow rebuild is outside standard migration scope.

VIENNA Advantage cloud deployments use a shared multi-tenant database with tenant separation at the schema or client-ID level. When exporting data, we apply strict tenant-ID filtering on every table join to prevent records from other tenants entering the migration. Epicor uses org-level isolation per deployment, so migrated data lands cleanly within a single Epicor company or plant without additional tenant scoping.