Migrate from Kladana ERP to Epicor Prophet 21

Kladana Items with variants, bundles, serial numbers, batches, expiry dates, and barcode associations map to Epicor Part records. We map all standard item attributes including cost price (Part.standardCost), sell price (Part.ListPrice), reorder points, and unit of measure. Kladana variants (size, color, dimension) map to Epicor Part Revision and PartPlant records with the variant treated as a Revision rather than a separate Part record. Batch and serial number traceability data migrates to Epicor's Lot and SN tables with the original Kladana lot number and expiry date preserved.

Kladana Counterparties are unified objects representing both customers and suppliers with linked transaction history, contacts, and addresses. We split them into Epicor Customer (for Kladana Counterparties with outgoing sales history) and Supplier (for incoming purchase history) records. Each Counterparty's linked contacts migrate to Epicor Person records with the primary contact flag preserved. Address data maps to Epicor's address table with the same country, state, city, postal code, and street-level fields. Tax identification numbers migrate to the Tax Region or Tax ID fields on the Customer or Supplier record.

Kladana Sales Orders capture the full lifecycle from draft through invoiced. We map the order header (customer reference, order date, delivery date, currency) to Epicor SalesOrderHed and the line items (part number, quantity, unit price, discount) to SalesOrderDtl. Open Sales Orders migrate as active records with OrderRel (fulfillment release) lines created for each line. Fulfilled or invoiced Sales Orders migrate as readonly historical records with their final status preserved. We flag any Sales Order with a Kladana status of 'draft' for the customer to review and confirm before reactivating in Epicor.

Kladana Purchase Orders map to Epicor POHeader and PODetail. The supplier reference, expected delivery date, and receipt status transfer to Epicor POHeader and PORel (release) records. Line items migrate with part number, ordered quantity, unit cost, and due date. Any partially received Purchase Order in Kladana has its receipt history mapped to Epicor PORecpt records so that open receipt lines can be fulfilled in Epicor without re-entering data.

Kladana multi-warehouse configurations map to Epicor Warehouse records with bin storage supported through PartBin entries. We extract per-warehouse stock-on-hand quantities, reserved quantities, and pending inbound and outbound movements. Each warehouse in Kladana becomes a Warehouse in Epicor with the same code and name. In-transit movements in Kladana (transfer orders in progress) migrate as Epicor TransferOrders with the source and destination warehouse references resolved. Stocktakes migrate as Epicor CountTag records linked to the relevant Part and Warehouse.

Kladana BOMs define component relationships for manufactured items with multi-level nesting and version tracking. Epicor represents BOMs as PartBill (header linking to the manufactured Part) with PartMtl lines (component, quantity per, operation number, scrap factor). We map Kladana's component-quantity and scrap-factors directly. Kladana BOM version logic does not map 1:1 to Epicor because Epicor manages BOM revisions through a PartRev revision control model rather than explicit version numbers. We export the full BOM version history from Kladana and flag records where multiple versions exist so the customer can select the canonical version to treat as the active BOM in Epicor. Subassembly nesting depth of 3+ levels requires careful PartRev and PartMtl sequencing that we validate in the sandbox migration before production.

Kladana Production Orders reference a BOM, a routing, and planned quantities with actual output, material consumption, labour hours, and variance tracked. We map production order headers to Epicor JobHead (job number, part number, start date, quantity to build), material components to JobMtl (part number, required quantity, issued quantity, scrap), and operations to JobOper (work centre, labour hours estimated, labour hours actual, machine hours). Planned-versus-actual variance data from Kladana migrates as JobProd records capturing the job scheduling and WIP cost tracking context. We preserve the production order status (scheduled, in-progress, completed) and flag any order with open material allocations for the customer to confirm before Epicor go-live.

Kladana invoices (Sales and Purchase) linked to orders and counterparties map to Epicor ARInvoice (customer invoices) and APInvoice (supplier invoices). Invoice headers, line items, tax codes, payment status, and outstanding balances transfer to Epicor's invoice records. Fully paid invoices migrate as historical readonly records; open invoices migrate with their outstanding balance and due date so that Epicor's collections and payment matching workflows can continue from the moment of cutover. We reconcile the total invoice value and tax amounts between Kladana and Epicor before marking the invoice phase complete.

Kladana custom fields on Items, Counterparties, Orders, and other objects migrate as Epicor User-Defined (UD) fields. We use Epicor's UD Column Map configuration to define the field type (string, integer, decimal, date, checkbox) and attach it to the relevant business object table. Epicor users require manual configuration of UD columns in Kinetic Administrator or the EDMS approach before our migration can write to them. We provide a field-level inventory listing every custom field, its Kladana type, its Epicor UD equivalent type, and the target business object so the customer's Epicor partner or admin can provision UD fields before we begin the data load phase.

Kladana's CRM module stores contact records linked to counterparties with interaction notes, sales history links, and custom offer data. We map these to Epicor Person records (with Name, Phone, Email, Title) and link them to the corresponding Customer record via the CustCnt (contact) relationship. CRM notes linked to counterparties migrate as Epicor Extended texts (Character01-05 UD fields or separate Note tables) attached to the Customer or Person record. Sales history references that point to closed Sales Orders are linked via the OrderNum reference preserved on the migrated records.

Kladana internal transfers between warehouses with in-transit status map to Epicor TransferOrder records. The source warehouse, destination warehouse, part number, quantity in transit, and expected arrival date transfer to Epicor's transfer order structure. Completed transfers migrate as readonly history; open transfers migrate with their current in-transit quantity so that Epicor's warehouse management can receive the transferred stock against the open TransferOrder.

Kladana stocktake sessions with counted quantities, variance calculations, and adjustment records map to Epicor CountTag and CountDtl records linked to the relevant Part and Warehouse. We preserve the stocktake date, the counted quantity, and the variance from the expected quantity so that Epicor's inventory adjustment and cycle counting workflows can be triggered from the migrated count data. The most recent stocktake snapshot becomes the authoritative opening stock position in Epicor at cutover.