Migrate from JTL-Wawi to Epicor Prophet 21

JTL-Wawi Artikels (items with Variationskombinatione) translate to Epicor Part master records where the base Stammartikel maps to Part and each active Variationskombination maps to a separate PartRevision or PartPlant row depending on Epicor configuration. We export via JTL-Ameise CSV, transform Variationskombinatione SKUs into Part PartNum with a parent-child relationship preserved via PartBin or PartRev, and load into Epicor via DMT PartMaster templates. JTL's cBestellung (reorder point) and cLagerbestand (stock level) map to PartPlant MinimumOrderQty and MaxOrderQty.

JTL-Wawi Variationskombinatione (size/color variant combinations) do not have a direct Epicor equivalent at the variant level. We split each Variationskombination into its own Epicor Part record with the parent Stammartikel PartNum stored in a custom field jtl_parent_artikel__c. The variant attributes (Größe, Farbe) migrate as Part custom fields or as a PartAttr table entry. If the customer uses Epicor's configure-to-order module, we map the variant matrix into OptionSets instead of separate Part records during scoping.

JTL-Wawi Kunden map directly to Epicor Customer records. The JTL customer number (kKundenNr) becomes Customer-CustID; the email and billing address map to the Customer's default billing contact and address. We preserve the original JTL customer number in a custom field jtl_kundennr__c for reconciliation. Customer payment terms (Zahlungsziel) map to Epicor PaymentTerms.

JTL-Wawi Lieferanten map to Epicor Vendor records with the JTL supplier number preserved in jtl_lieferantennr__c. The Lieferanten address and Einkaufspreise (purchase prices) require transformation: JTL stores Einkaufspreise per Lieferantenartikel relationship, which we map to Epicor VendorPartNo records. Zusatzkosten (transport, customs, duties) on Lieferantenbestellungen map to Epicor POMisc records linked to POHeader with the appropriate MiscCode.

JTL-Wawi Aufträge map to Epicor OrderHed (header) and OrderDtl (line) records. The Auftrag number (tAuftrag) becomes OrderNum; the workflow state (erstellt, bezahlt, ausgeliefert) maps to OrderHed.OpenLine, OrderHed.BTAddress-val, and OrderDtl.OurShipMgr respectively. Auftrag line items (Artikels) map to OrderDtl with PartNum, SellingQuantity, and UnitPrice preserved. Marketplace assignment from JTL (eBay, Amazon, JTL-Shop) is stored as a custom field jtl_marktplatz__c on OrderHed.

JTL-Wawi Bestellungen an Lieferanten (purchase orders) map to Epicor POHeader and PODetail records. The JTL delivery date (Lieferdatum) and bestelltext become POHeader.RequireDate and PODetail.LineDesc. Zusatzkosten (transport, customs) on the Lieferantenbestellung become POMisc records with MiscCode entries that we pre-create during schema configuration. JTL's Rahmenbestellungen (blanket orders) map to Epicor POHeader with a blanked Release schedule in PODetail.

JTL-Wawi Rechnungen (invoices) reference Aufträge and contain line-item tax calculations. We export via the Rechnungen JTL-Ameise template and map to Epicor InvoiceHed and InvoiceDtl for open invoices, and to InvoiceHist and InvDtl for historical records. Regional VAT codes (19% MwSt, 7% reduced) map to Epicor TaxRegion and TaxCode assignments that we configure in Epicor before import. JTL invoices without a linked Auftrag require manual assignment during the migration preparation phase.

JTL-Wawi Lagerbestände (stock levels per Lager) map to Epicor PartBin records. We export aktuelle Bestände and pending reservations per Lager via JTL-Ameise CSV, and load into Epicor with Warehse code per JTL warehouse identifier. PartBin.OnHandQty carries the stock snapshot at migration cutover. If JTL-WMS is in use, pick-and-pack station configurations are documented separately and not migrated as WMS data; Epicor's own WMS module or a third-party WMS handles warehouse operations post-migration.

If the JTL-Wawi installation contains BOM data for assembled products (via JTL-WMS or a connected manufacturing module), we map Stücklisten to Epicor PartRev (revision) and PartBOM records. The JTL-Stückliste Kopf becomes PartRev.RevShortDesc; each BOM line becomes a PartBOMMtl row with the component PartNum, QtyPer, and BOMSequence. If no BOM data exists in JTL-Wawi (common for pure e-commerce installations), this object is marked not-in-scope and the customer's Epicor admin configures BOMs post-migration.

JTL-Workflows define event-condition-action chains that trigger on Auftrag creation, payment received, or shipment events. We document all active JTL-Workflows during scoping with their trigger, conditions, actions, and the JTL event that fires them. Epicor Kinetic uses a different automation model (Method Directives, Data Directives, and Kinetic BPM) with different trigger types. We do not migrate JTL-Workflows as code. The Workflow audit document serves as the basis for Epicor Kinetic BPM rebuild by the customer's admin or a Kinetic implementation partner.

JTL-Connector synchronization between JTL-Wawi and Shopware, PrestaShop, JTL-Shop, or JTL-eazyAuction is scoped out. We provide a connector audit document listing every active storefront connection, the article-sync scope, order-pull filter, and the API credentials in use. Epicor ERP has no native storefront connector; the customer's e-commerce team selects a new e-commerce platform post-migration and configures the connector independently. We migrate the product and customer data that feeds the new storefront.

JTL-Wawi Versand data (DPD, Hermes, iloxx tracking IDs and shipping method assignments) is exported per logistics partner CSV. We map tracking IDs to Epicor ShipHead records linked to the corresponding OrderRel. The shipping method (Versandart) migrates as a custom field jtl_versandart__c on OrderHed for reference. Epicor does not natively integrate with German carrier APIs (DPD, Hermes); the customer's logistics team configures carrier integration post-migration if real-time tracking is required.