Migrate from JTL-Wawi to Odoo ERP

JTL Artikels (with Stammartikel as base and Variationskombinationen as variants) map to Odoo Product Templates with optional Product Attributes and Attribute Values. We extract Artikelmerkmale (item characteristics) and map them to Odoo product attributes. The JTLArtikel.nArtNr becomes the product's default_code; JTLArtikel.cArtNr maps to barcodes if present. Cross-references between base items and variants are preserved through Odoo's product variant resolution. Tier and edition constraints do not apply in Odoo Community or Enterprise for product variants.

JTL Kunden map to Odoo Contacts (res.partner with customer_rank = 1). Address records (Rechnungsadresse, Lieferadresse) merge into Odoo's address fields (street, street2, zip, city, country) using address_type flags where multiple addresses exist per partner. Payment status and customer tier flags from JTL map to custom fields on the res.partner. We preserve JTL's customer-specific Rabattgruppen (discount groups) as a custom field for pricing rule reconstruction.

JTL Aufträge map to Odoo Sale Orders. The Auftrag workflow state (erstellt, bezahlt, ausgeliefert, storniert) maps to Odoo states (draft, sent, sale, done, cancel) with a custom field jtl_workflow_state__c preserving the original German status for audit. JTL order modifications (Auftragsaenderungen) and partial shipments are preserved as order lines with backorder flags. Kunden reference resolves to res.partner lookup; Artikel references resolve to product.product lookup at migration time.

JTL Rechnungen map to Odoo Account Moves with type = out_invoice or out_refund. Tax calculations from JTL (MwSt codes for German 19%, 7%, and reduced rates) map to Odoo tax records via fiscal position configuration. We preserve the Rechnung number sequence as the Odoo move name for audit continuity. Line items map to account.move.line with tax mapping applied per line. Due date and payment terms from JTL become Odoo invoice payment terms.

JTL Lagerbestände per Lager map to Odoo stock.quant records per warehouse location. Aktuelle Bestände (current stock levels) and pending reservations migrate as separate quant records (quantity and reserved_quantity). JTL's Lager (warehouse) entity maps to Odoo's stock.warehouse with its associated stock.location tree (view, internal, partner, inventory loss). Stock valuation amounts from JTL require a value mapping to Odoo's stock.valuation.layer records if FIFO or average cost is tracked.

JTL Lieferanten map to Odoo Contacts with supplier_rank set to 1 (and optionally customer_rank if the vendor is also a customer). Lieferanten address and contact details migrate as res.partner address fields. Einkaufspreise (purchase prices) per Lieferant map to Odoo vendor Pricelist entries linked to the supplier partner. Rahmenbestellungen (blanket purchase orders) map to Odoo purchaseBlanketOrders if the purchase module is active.

JTL Zusatzkosten (transport, customs, duties, and other named cost types per Lieferantenbestellung) require configuration in Odoo. We map each unique Zusatzkosten type to an Odoo product (with type = service) that can be added as an extra cost line on purchase orders or linked via Odoo's landed costs module if the Enterprise edition is deployed. Cost allocation methods (by quantity, by weight, by volume) are preserved in custom fields for admin configuration. This is a configuration step; direct import of historical Zusatzkosten onto existing purchase orders requires a manual mapping review.

JTL shipping data (DPD, Hermes, iloxx tracking IDs and shipping method assignments) maps to Odoo stock.picking records with carrier_id resolved to the matching Odoo delivery carrier. Tracking URLs are preserved in the picking notes. We export the JTL shipping method assignment template (Versandvorlage) as a separate CSV for admin to configure Odoo delivery methods post-migration. Historical shipment records with completed pickings migrate as stock.move.line records with origin referencing the original Auftrag.

JTL-Connector links between JTL-Wawi and Shopware, PrestaShop, or other storefronts do not have a direct Odoo equivalent because Odoo uses its own set of connector apps (Odoo Amazon, Odoo eBay, Odoo Shopify, Odoo WooCommerce Connector, or third-party modules). We deliver a connector audit document listing each active JTL-Connector with its current configuration, credentials scope, and synchronization scope (Articles only, Orders only, Full). The customer's admin or an Odoo partner re-establishes each storefront connection in Odoo after migration.

JTL-Workflows define event-condition-action chains that are specific to JTL's internal engine and do not export to Odoo. We deliver a written workflow audit report listing every active JTL-Workflow with its trigger event (e.g., order created, payment received, shipment confirmed), conditions, and actions. The customer's admin or an Odoo partner maps each to Odoo Server Actions, Automated Actions (ir.actions.server and ir.cron), or Odoo Workflow Builder (available in Odoo Studio or Enterprise) post-migration.

JTL-WMS extends JTL-Wawi with pick-and-pack workflows, Arbeitsstationen (workstations), and Packtisch-Konfiguration (packing table settings). These are not exposed via JTL's REST API or JTL-Ameise. We document the WMS configuration during scoping (warehouse layout, picking strategy, packing station assignments) as a written handoff for the customer's admin to reconfigure in Odoo's inventory app using routes, warehouse types, and operation types.