Migrate from Actindo Core1 to Epicor Prophet 21

Actindo Customer records map to Epicor Customer (Customer table with CustID as the primary key) and ShipTo addresses (ShipTo table linked by CustNum). Actindo's configurable address, contact, and segment fields translate to Epicor Customer fields with DataHub segment values mapped to UD fields or a custom segment table. We use Actindo CustomerID as CustID and resolve address records to the ShipTo table in the correct CustNum sequence.

Actindo Materials represent product catalog items with SKU, pricing, and attribute data. Materials map to Epicor Part records (Part table with PartNum as primary key). Actindo's DataHub custom fields on Material extend to Epicor UD fields (UD tables with Like columns pointing to Part). We export Material fields including variants and stock levels via DataHub and create matching Epicor Part records with PartDescription, UnitPrice, and any DataHub-driven attributes translated to UD field equivalents.

Actindo Articles extend Materials with channel-specific content, descriptions, and media managed via the PIM/Omnichannel module. Article and Material have a parent-child relationship but export as separate entities. We tag Article records with their parent Material SKU during extraction and reconstruct the relationship in Epicor Part by linking to a custom PartPIMContent table or by extending Part description and attribute fields with the Article content. The Material SKU becomes the Epicor PartNum foreign key. If the destination Epicor instance includes Epicor CPQ or product configuration modules, Article variants map to PartRev configurations.

Actindo Orders consolidate transactions from webshop, marketplace, POS, and B2B channels into a unified format. Orders map to Epicor SalesOrder records (OrderHed and OrderDtl tables). We preserve line items, fulfillment status, and totals, and map Actindo order channel attributes to Epicor UD fields on OrderHed (such as OrderSource__c for channel attribution). Order date and shipping info map to Epicor's OrderDate and ShipByDate fields. Any POS-derived orders retain the store location as a warehouse reference on the OrderDtl.

Actindo Warehouse entities define stock locations with bin-level structure. Warehouses map to Epicor Warehse (warehouse definition per Plant) and PartWhse (stock per warehouse per part). We migrate Actindo warehouse definitions to Epicor Warehse with WarehCode and Name preserved. Bin-level tracking migrates to PartBin if Epicor is configured for bin-level inventory. Multi-warehouse routing configurations become PartWhse records linking Part to Warehse with the appropriateQty records.

Actindo Purchase Orders track procurement from vendors, linked to Materials and inbound receipts. PO headers and line items map to Epicor POHeader and PODetail. Vendor-specific reference numbers and lead times migrate to Epicor PODetail fields, but we flag vendor-specific reference fields for UD field extension if no native Epicor equivalent exists. Vendors must be provisioned in Epicor (Supplier table) before PO import can reference them as suppliers.

Actindo Invoice records link to Orders and track financial postings across accounting integrations. Invoices map to Epicor InvcHead and InvcDetail. We extract invoice data including tax codes and payment status and normalize to Epicor's invoice structure. Tax codes from Actindo map to Epicor TaxRegion and TaxConnect usage, with any Actindo-specific tax configurations flagged for manual verification with the customer's finance team. Historical invoices with AR status require Customer and ShipTo linkage pre-resolved.

Actindo Vendor master records store supplier data, payment terms, and lead times. Vendors map to Epicor Supplier records (Supplier table with VendorID as primary key). We migrate Vendor contact information and purchasing defaults (terms, lead times) to Epicor Supplier fields. Vendor-specific PO history migrates as linked PODetail records. Vendor bank and payment information migrates to Epicor VendorPPP if the Payment Processing Platform module is in use.

Actindo POS data includes transaction records and store cash register states synced from Venduo POS. POS transactions export as Orders with a store-location attribute in the warehouse field. We migrate POS transactions as Epicor SalesOrder records with the store warehouse code set and POS transaction metadata (register ID, shift, tender type) in OrderHed UD fields. Register reconciliations require a separate reconciliation report handoff; they do not migrate as transactional records.

Actindo DataHub custom fields extend Material, Order, Customer, and other entities with user-defined attributes managed via ETL mappings. These translate to Epicor User Defined fields using the ZDataTable framework. We map each DataHub custom field to an Epicor UD field with matching data type (string, integer, decimal, date). Epicor UD field population often requires a BPM to set the field value at insert; we document the BPM logic as part of the migration handoff rather than building it inside the migration scope.

Actindo Process Orchestration encodes business process logic as low-code visual flows. These do not export in a standard schema and cannot migrate directly to Epicor Business Activity Manager (BAM) or BPM rules. We capture screenshots, rule descriptions, and trigger-condition matrices during extraction and build a rule-mapping matrix documenting each Actindo flow and its recommended Epicor BAM equivalent. The customer's Epicor admin or implementation partner rebuilds the BPM rules post-migration. We do not implement BPM rules inside the migration scope.

Actindo's accumulated order history, inventory transactions, and financial postings span multiple years. Epicor handles historical data differently from Actindo: PartTran records track inventory movements, LaborDtl tracks production labor, and InvcHead tracks financials. We migrate active and recent historical records (typically the last 2-3 years) as transactional data into Epicor's native tables. Older historical data (beyond 3 years) is archived per Epicor best practices to a separate data store, as Epicor implementations commonly face performance and compliance issues when decades of transaction history are loaded into the live ERP. We deliver a historical data archive inventory documenting record counts and date ranges by entity.