Pre-built field-level crosswalks for the ECC universe: BKPF/BSEG → Fusion GL, KNA1/KNB1/KNVV → TCA, LFA1/LFB1 → Supplier, MARA/MARC → Items, EKKO/EKPO → POs, VBAK/VBAP → Sales Orders. Z-* fields classified, audit-signed.
Mapping is not a slide deck or a spreadsheet — it's the executable specification that turns thirty years of ECC data into a clean Fusion tenant without losing audit trace.
Every ECC source column has to land somewhere in the Fusion target — or be deliberately and audit-defensibly retired. That includes the thirty-thousand-or-so standard SAP columns across FI, CO, MM, SD, PP, QM, PM and HR, plus the thousand-plus Z-* append fields and custom-table columns the customer added during three decades of implementation. On consultant-led programmes this mapping is a months-long PowerPoint and Excel exercise that ends in 'we'll sort that one in build'. Syntra ETL ships a pre-built sap ecc to oracle fusion data mapping engine: every standard ECC field has a published target, every Z-* field gets a classification recommendation, every mapping row is audit-signed.
The output is not a slide deck. It's a machine-readable mapping catalogue keyed to the FBDI and HDL schemas of the current Oracle Fusion 26x release — so the same artefact that finance leadership reviews is the artefact that generates the actual FBDI payloads. Change a mapping row, the next FBDI ZIP reflects it. No translation layer between business intent and technical execution.
And every mapping carries reverse traceability: the GL line you see in Fusion 18 months from now still resolves back to a specific BSEG row, BKPF document number, ECC company code, posting date and the Z-* field values it carried. That trace is what HGB §257, AO §147, SOX, IFRS, MiFID II, FDA 21 CFR Part 11 and BaFin all require — and what Syntra ETL preserves by default.
Every mapping pack is field-keyed, audit-signed and bound to the current Oracle Fusion 26x FBDI/HDL schema.
BKPF + BSEG + BKDF/BSAD/BSAK + ANLA/ANLC + parallel-currency tables → Fusion GL Journal Headers, GL Journal Lines, FA Mass Additions. Multi-ledger preserved, segment crosswalk applied.
KNA1 + KNB1 + KNVV + KNB5 dunning + KNBK bank → TCA Party + Party Site + Customer Account + Account Site + BU Assignment + Customer Banks. Partner functions preserved.
LFA1 + LFB1 + LFM1 + LFBK + LFBW withholding → Fusion Supplier + Supplier Site + BU Assignment + Procurement BU Assignment + Supplier Banks + Withholding categories.
MARA + MARC + MARD + MBEW + MARM UoM + MAKT descriptions → Fusion Item + Item-Org Assignment + Cost-Org material category + Item Catalog Category + UoM Class.
EKKO + EKPO + EKKN account-assignment + EKBE history + EINA/EINE info records → Fusion PO Header + Line + Distribution + Schedule + Approved Supplier List + Source Document.
VBAK + VBAP + VBEP schedules + VBKD partner-overrides + VBRK/VBRP billing + LIPS deliveries → Fusion OM Order Header + Line + Schedule + Distribution + Invoice.
A four-stage workflow that takes mapping from blank slate to FBDI/HDL-ready in weeks, not months.
ABAP Dictionary (DD02L/DD03L) crawl produces a full inventory of every standard SAP field in use, every Z-* append field and every custom Z-* table — typically 12,000–18,000 columns across a mature ECC tenant. Output: machine-readable column catalogue, volume profile, NULL/distinct profile.
Pre-built mapping packs (Finance, Customer, Vendor, Item, Purchasing, OM) applied automatically. Standard SAP fields get default Fusion targets. Field coverage rises from 0% to 75–85% in a single platform pass.
Each Z-* field reviewed by FI/MM/SD/CO/HR domain leads with the discovery engine's recommendations as the starting point. Decisions: collapse to COA segment, route to DFF/EFF, retire to archive. Decisions audit-signed and locked.
Mapping catalogue frozen. First FBDI/HDL payloads emitted from the same artefact. Row-level diagnostics surface validation errors locally — before the FBDI ZIP touches Fusion ESS.
Every mapping change is versioned. Two-person approval for production-impacting rows. Diff exports for external audit. Full reverse traceability — any Fusion record resolves to its source BSEG/KNA1/LFA1/MARA/EKKO/VBAK row plus the mapping version that produced it.
Final mapping catalogue locked, external audit and Wirtschaftsprüfer sign the audit-signed mapping pack. Mapping becomes part of the cutover evidence binder. Post-cutover changes require formal change-control.
Six structural advantages over the bespoke spreadsheet-and-PowerPoint approach.
Every Fusion-side target is bound to the current 26x FBDI/HDL schema. Schema drift between releases caught at platform-update time, not on the FBDI ESS submission that fails on row 91,000.
Every mapping row has forward (source → target) and reverse (target → source) trace. Reverse trace is how audit reconstructs a GL line 18 months later back to its BSEG origin.
Live dashboard shows mapping coverage by domain, by Z-* class, by company code. Pre-cutover sign-off only accepts 100% mapped-or-retired. No silent gaps.
Each Z-* classification decision is signed by named domain owner with date and rationale. The signed pack lands in the cutover evidence binder for external audit.
Italian SDI, Brazilian SPED, French Chorus Pro, Polish KSeF, Mexican CFDI overlay specific field requirements on top of base mappings. Country compliance preserved without re-mapping.
Pre-built packs collapse the 4–6 month bespoke mapping phase to 4–6 weeks. The platform handles 75–85% out of the box; the Z-* workshop covers the remaining customer-specific 15–25%.
Sap ecc to oracle fusion data mapping is the field-by-field, table-by-table specification of how each ECC source column lands in an Oracle Fusion target object. BKPF document headers map to Fusion GL Journal Headers (doc-type to journal source, posting-date to GL date, reference to journal name, header-text to description). BSEG line items map to Fusion GL Journal Lines (the source GL account routes via SKA1/SKB1 to the Fusion six-segment COA Account, the cost centre routes to the Cost Center segment, profit centre to Profit Center, etc.). KNA1/KNB1/KNVV customer master maps to Fusion TCA Parties plus Customer Account plus Site. LFA1/LFB1 vendor master maps to Fusion Supplier plus Supplier Site. MARA/MARC material master maps to Fusion Items in PIM with UoM, item-class and category-set conversion. EKKO/EKPO purchase docs map to Fusion Purchase Orders. VBAK/VBAP sales orders map to Fusion Sales Orders. Every mapping is a documented, audit-signed crosswalk row.
BSEG is the heart of every sap ecc to oracle fusion data mapping. Each BSEG row carries a posting key (40/50 for GL, 01/21 for customer, 31 for vendor, etc.), a debit/credit indicator (SHKZG), an amount in local currency (DMBTR), an amount in document currency (WRBTR), an amount in second/third local currency (DMBE2/DMBE3 for parallel-currency setups), a cost centre (KOSTL), a profit centre (PRCTR), a segment (SEGMENT), an internal-order (AUFNR) and dozens of dimensional fields. Syntra ETL's BSEG → Fusion GL Journal Line mapping preserves every one of those dimensions across the COA crosswalk, splits parallel-currency rows into Fusion's per-ledger journal lines (one per non-leading ledger), and routes Z-* append fields into Fusion DFFs or segment values per the discovery-classification decisions. The output is FBDI GL Journal Import format, validated against the current Fusion 26x release schema before the FBDI ZIP is even built.
Customer master in ECC is split across three tables: KNA1 (general data — name, address, country, industry), KNB1 (company-code-specific data — reconciliation account, payment terms, dunning) and KNVV (sales-area-specific data — sales org, distribution channel, division, currency, incoterms). Sap ecc to oracle fusion data mapping consolidates these into Fusion's TCA model: KNA1 becomes a Party (with Party Site for each operating address), KNB1 becomes a Customer Account at the Business Unit level (one Customer Account per ECC company code, with reconciliation-account routed to the matching Fusion liability account, payment terms remapped to Fusion Payment Terms, dunning attributes routed to Collections), and KNVV becomes Customer Account Sites with sales-org-specific assignments. Partner functions (sold-to, ship-to, bill-to, payer) carry across as TCA Party Relationships.
Vendor master is structurally analogous: LFA1 (general — name, address, country, withholding-tax category), LFB1 (company-code-specific — reconciliation account, payment terms, tolerance group, dunning) and LFM1 (purchasing-org-specific — order currency, GR-based invoice verification, partner schema). Sap ecc to oracle fusion data mapping translates these into Fusion's Supplier model: LFA1 becomes a Supplier with Supplier Sites per operating address; LFB1 becomes Supplier Site Assignments at each Business Unit (one per ECC company code, with reconciliation-account, payment terms, hold-flag mapped); LFM1 becomes Procurement Supplier Site Assignments per Procurement BU. 1099 / withholding-tax categories from LFA1-LFBW carry across into Fusion Tax. Bank accounts (LFBK) carry into Fusion Cash Management bank assignments.
MARA carries the material's general data; MARC carries plant-level data (procurement type, MRP type, valuation class); MARD carries storage-location stock; MBEW carries valuation data. Sap ecc to oracle fusion data mapping converts these into Fusion Items: MARA becomes an Item in Product Hub (PIM), with type, primary UoM and item-class mapped from ECC material type. MARC becomes Item-Organization Assignments (one per Inventory Org corresponding to the ECC plant). UoM conversions (MARM) translate to Fusion UoM Class assignments. Material type → Item Class. Material group (MATKL) → Item Catalog Category. Valuation class → Cost-Org material category. Batch/serial management flags carry across. Z-* append fields on MARA route to PIM EFFs or Fusion DFFs. The result is an Item master ready for receiving, costing, sales-order processing and demand planning on Fusion.
EKKO is the PO header (vendor, doc type, purchase-org, payment terms, currency); EKPO is the PO line (material, plant, quantity, net price, account assignment, tax code); EKKN is the account-assignment detail when not at line level. Sap ecc to oracle fusion data mapping converts ECC PO doc types (NB standard, FO framework, UB stock transfer, EC subcontracting, etc.) into Fusion PO Document Types (Standard PO, Blanket Agreement, Contract, Transfer Order, Subcontracting PO). Account assignments — cost-centre KOSTL, internal-order AUFNR, asset ANLN, project PS_PSP_PNR — route to the equivalent Fusion distributions (Charge Account, Project, Task, Award, Funding Source). Tax codes (MWSKZ) remap to Fusion Tax Lines. Header conditions (KONP) and pricing route to PO Price Element schedules.
VBAK is the sales-order header (customer, doc type, sales-org/distribution-channel/division, payment terms, incoterms); VBAP is the SO line (material, quantity, plant, schedule line, item category, billing block); VBEP carries schedule-line dates; VBKD partner-specific overrides. Sap ecc to oracle fusion data mapping converts ECC SO doc types (OR standard, RE returns, FD free-of-charge, CR credit memo request, etc.) into Fusion OM Order Types (Standard Order, RMA, Sample, Credit Memo). Item categories (TAN, TAP, TAB, TANN) translate to Fusion Order Line Types (Standard, BPO Release, etc.). Customer pickup → Fusion ship-from rules. Pricing condition records (KONV) translate to Fusion Pricing Strategy assignments. Schedule lines preserve commit dates and quantities — open orders cut over with full status.
Every Z-* append field on a standard SAP table (Z fields appended to BSEG, KNA1, LFA1, MARA, EKKO, VBAK, etc.) and every Z-* custom table is inventoried by the discovery engine and classified during the design phase. Sap ecc to oracle fusion data mapping then routes each according to its classification: required reporting dimensions collapse into Fusion COA segments (e.g. a Z_PROJECT field on BSEG often becomes a new COA segment in Fusion), required operational attributes route to Fusion core fields where a semantic equivalent exists (e.g. Z_CUSTOMER_TIER on KNA1 → TCA Party Classification), optional descriptive attributes route to Fusion DFFs (Descriptive Flexfields) or EFFs (Extensible Flexfields), and analytical-only Z fields land in the long-term ECC archive accessible via OTBI dimensions. Every routing decision is audit-signed so external audit and Wirtschaftsprüfer have explicit traceability.
30-minute discovery call. We'll connect to your ECC instance (read-only), run the discovery crawl, and produce a coverage scorecard for FI/CO/MM/SD/HR within the call — including a Z-* classification preview.