The field-level dynamics ax to oracle fusion mapping. LedgerTable to Fusion ledger, MainAccount to COA, CustTable / VendTable to TCA parties, InventTable + InventDim to Fusion Items, Financial Dimensions to COA + DFFs, Number Sequences to Document Sequencing, AIF to REST/SOAP, X++ Workflow to AMX.
Get the mapping right and the rest is mechanical. Get it wrong and every load downstream surfaces the gap — usually at 3am during cutover weekend.
Dynamics AX 2012 carries more than fifteen hundred standard tables before any customer customization. CustTable, VendTable and InventTable each have over a hundred fields. LedgerJournalTrans alone has over fifty fields with intricate referential relationships into CustTable, VendTable, InventTable, MainAccount and DimensionAttributeValueCombination. Financial Dimensions add a many-to-many analytical overlay. EDTs (Extended Data Types) provide inheritance-based typing where a custom EDT extending CustGroup is silently used across hundreds of tables. Custom X++ overlays in CUS/USR layers can add, modify or override any of it.
The dynamics ax to oracle fusion mapping is the document that says — for every one of those AX constructs that actually matters in your tenant — where it lands in Fusion. It is not a generic mapping someone wrote about AX in general. It is your mapping, derived from walking your AOT, profiling your transactional volumes, identifying the EDTs and customizations that actually exist in your CUS/USR layers, and resolving every active MainAccount and Financial Dimension combination from your LedgerJournalTrans.
Syntra ETL ships the dynamics ax to oracle fusion mapping starter spreadsheet covering the AX 2012 / AX 2009 standard model — over twelve hundred pre-mapped objects with default Fusion targets and transformation rules. The first three weeks of the project specialise that to your tenant: customizations resolved, Financial Dimensions routed, Number Sequences classified, AIF services catalogued. The signed-off mapping then drives every downstream activity: ETL configuration, Fusion FSM setup, FBDI generation, AMX workflow build, reporting rebuild.
And how Syntra ETL's pre-built starter mapping accelerates each.
AX 4-digit natural account commonly re-blocked to Fusion 6-digit during the move. Re-block table generated, validated against historical LedgerJournalTrans volume, signed off by finance and group reporting.
Active dimension combinations from DimensionAttributeValueCombination walked, reporting materiality scored, routed to COA segments, GL DFFs or analytical-only OTBI. No silent posting failures.
Statutory reporting variants (HGB local books, IFRS books, US-GAAP elimination books) preserved as Fusion Secondary Ledgers rather than collapsed. Each gets explicit accounting method assignment.
Cross-DataAreaId duplicate detection, tax-ID and bank normalisation, party-and-site explosion. One AX customer in three companies becomes one TCA Party with three Customer Accounts.
AX's monolithic dimension table separated into Fusion Item attributes versus Inventory Item Location versus Lot / Serial Master. Custom item attributes route to Item DFFs / EFFs.
Every sequence classified for statutory significance. Continue / restart / freeze-and-replace decision made per sequence. Continuity preserved for HGB and PCG statutory invoice numbers.
From kick-off to signed mapping in four working weeks. Then four months of execution that doesn't surface mapping surprises.
AOT crawler runs over the AOS; every standard and custom table, EDT, Number Sequence, Workflow and AIF service enumerated. Transactional profiling pass over LedgerJournalTrans, SalesTable, PurchTable, CustTrans, VendTrans, InventTrans extracts active volumes and dimension combinations per legal entity per fiscal period.
Syntra ETL's standard dynamics ax to oracle fusion mapping starter (1,200+ pre-mapped objects) loaded; replaced/extended for your specific EDT overrides, custom Tables and custom fields. Customer-specific Financial Dimension routing and MainAccount re-blocking proposed.
Finance, supply chain, procurement, manufacturing and HR review their respective mapping sections. Edge cases surfaced (intercompany, statutory variants, M&A-induced data quality issues, country-specific legal requirements). Iteration with functional sign-off owners. Internal audit reviews data-conversion controls section.
Final mapping reviewed end-to-end, signed by each functional sign-off owner, locked under change control. Mapping spreadsheet becomes the controlled-document baseline. ETL configuration generated from the signed mapping. Fusion FSM setup tasks generated from the signed mapping. FBDI templates configured from the signed mapping.
Every subsequent project artefact (extraction config, transformation rules, FBDI payloads, AMX setup, reporting rebuild plan) traces back to the signed mapping. Any change goes through the same review-and-sign-off cycle. No silent drift between what finance signed and what runs in production.
Post-cutover, the signed mapping becomes the architecture reference for the Fusion tenant — used by IT, finance, audit and consulting to answer 'where did this AX object end up' for years after go-live.
Two artefacts, both controlled documents, both executable.
Every AX source object × Fusion target object × transformation rule × edge case × retire/replace decision × sign-off owner. Filterable by domain (GL, AP, AR, Inv, SCM), by AX module, by Fusion product area.
Same spreadsheet rules translated into Syntra ETL pipeline transformation steps so what finance signs off in week 4 is exactly what runs through extraction, validation and FBDI generation.
Generated from the signed mapping — Fusion Functional Setup Manager tasks per module with the parameters required to align Fusion target with AX source (segments, value sets, document sequences, calendars).
Every non-standard mapping decision (intercompany consolidation rules, IFRS-to-local-GAAP variance treatment, country statutory reporting variants) catalogued with rationale and sign-off owner.
Every X++ customization across all 16 AX layers classified: native Fusion equivalent (retire), DFF/EFF route (preserve as Fusion extension), AMX route (preserve as workflow), or rebuild as new Fusion extension.
Statutory retention, SOX 404 evidence path, sensitive-data masking decisions, country-specific personal-data routing — controlled-document content for internal and statutory audit.
A dynamics ax to oracle fusion mapping is the field-by-field, table-by-table, business-rule-by-business-rule specification that says: where does every AX construct land in Oracle Fusion. It covers LedgerTable (AX ledger definitions) to Fusion Ledger and Primary Ledger Currency, MainAccount (AX chart of accounts) to Fusion COA natural-account segment, CustTable to Fusion TCA Party plus Customer Account, VendTable to Fusion Supplier plus Supplier Site, InventTable plus InventDim to Fusion Item plus Item Org plus Lot/Serial control, AX Financial Dimensions (DimensionAttribute / DimensionAttributeValueCombination) to Fusion COA segments and DFFs, Number Sequences to Fusion Document Sequencing, AX Workflow definitions to Fusion AMX, AIF inbound/outbound services to Fusion REST/SOAP — and dozens more. The dynamics ax to oracle fusion mapping is the contract that drives ETL configuration and Fusion target setup.
LedgerTable in AX defines per-legal-entity ledger configuration (currency, fiscal calendar, chart of accounts reference, account structures, number-sequence linkage). The dynamics ax to oracle fusion mapping translates each LedgerTable row into one Fusion Primary Ledger record with corresponding Legal Entity, Business Unit and Reporting Currency setup. Where AX customers run multiple LedgerTable instances under one company for statutory reporting variants (German HGB local books, IFRS reporting books, US-GAAP elimination books), the mapping translates each to a separate Fusion Secondary Ledger with the appropriate accounting method. Fiscal calendars carry across as Fusion GL Calendar setup. Account structure validation rules in AX become Fusion GL Cross-Validation Rules. The result is a Fusion ledger topology that matches the AX statutory reporting structure rather than collapsing it into one ledger.
MainAccount in AX 2012 is the natural account in the AX COA — typically 4 to 6 digits. Financial Dimensions (BusinessUnit, CostCenter, Department, ItemGroup and customer-defined) supply the analytical axis. The dynamics ax to oracle fusion mapping designs the Fusion 6-segment COA to absorb both: natural account from MainAccount maps to the Fusion COA Account segment (often re-blocked from AX's typical 4-digit to Fusion's typical 6-digit per group COA design), and material Financial Dimensions absorb into the remaining COA segments (Company, Cost Center, Department, Intercompany, Project). Lower-volume analytical-only dimensions route to Fusion GL DFFs. Default Account rules in AX translate to Fusion Subledger Accounting setup. Every active MainAccount + Financial Dimension combination from LedgerJournalTrans is enumerated and resolved during the mapping exercise — no silent posting failures at load time.
AX CustTable and VendTable are flat customer and vendor records — one row per customer or vendor per company (DataAreaId). Fusion uses Trading Community Architecture: a Party represents the legal entity, Party Sites represent locations, Customer Accounts represent the commercial relationship within a Business Unit, Supplier records represent the supplier with Supplier Sites per BU. The dynamics ax to oracle fusion mapping does cross-DataAreaId duplicate detection (one customer present in three AX companies becomes one TCA Party with three Customer Accounts), tax-ID and bank-account normalisation, address-line cleansing through Fusion's address validation, and explicit per-AX-customer routing to Fusion Customer Account. Same pattern for VendTable to Supplier. Customer-defined extension fields on CustTable/VendTable route to Fusion party/account DFFs.
AX inventory is anchored on InventTable (item master), InventDim (storage/tracking dimensions — Site, Warehouse, Location, Batch, Serial), and InventTrans (item movements). Fusion Inventory uses Items in Product Hub, Item Organization Assignment to assign items to inventory orgs, Inventory Item Locations for sub-inventory and locator, and Lot/Serial Control configured at item level. The dynamics ax to oracle fusion mapping disaggregates InventDim — AX's all-in-one dimension table — into the Fusion separation of Item attributes (Lot/Serial control flags, costing method) versus Inventory Item Location (sub-inventory, locator) versus Lot Master and Serial Master records for the actual lot/serial instances. Custom item attributes route to Fusion Item EFFs (Item Categories, Item DFFs).
AX Number Sequences become Fusion Document Sequencing (per-application-area sequences with format masks, restart rules, statutory-significance flags). Each sequence gets a disposition in the dynamics ax to oracle fusion mapping: continue (preserve statutory invoice continuity for German HGB, French PCG), restart (clean break for internal operational numbers), or freeze-and-replace (most common compromise — AX sequence frozen, new Fusion sequence assigned with offset). AIF inbound/outbound services rewire to Fusion REST APIs (for modern integrations) or SOAP web services (for legacy systems still needing SOAP). AIF document classes (AxdCustomer, AxdVendor, AxdSalesOrder, AxdPurchOrder) map to Fusion REST resource definitions per business-object. The integration rewiring plan is part of the assessment deliverable.
AX Workflow definitions (purchase requisition approvals, expense approvals, sales order approvals, journal approvals) defined in the AOT translate to Fusion Approvals Management Extensions (AMX) configuration. The dynamics ax to oracle fusion mapping inventories every active workflow definition, captures the approval hierarchy logic (organizational, positional, monetary thresholds, conditional branches), and reproduces it in AMX with the equivalent business rules. Where AX workflows reference custom X++ business logic in approval steps (custom validators, custom escalation rules), those translate to Fusion Approval Groups, Approval Rules and BPM rule conditions. The result is a Fusion approval topology that behaves the same as the AX one — without the X++ runtime dependency.
Two artefacts. First, the structured mapping spreadsheet: every AX source object (table, field, EDT, Number Sequence, Workflow, AIF service) with its Fusion target object, transformation rule, edge cases, retire/replace decision and sign-off owner. Second, the executable form of the same mapping as ETL configuration in Syntra ETL — the same spreadsheet rules translated into pipeline transformation steps so what finance signs off in week 4 is exactly what runs through extraction, validation and load. Reviewers (functional, technical, internal audit, statutory audit where required) sign the spreadsheet as a controlled document. Every subsequent change goes through the same review-and-sign-off cycle. The dynamics ax to oracle fusion mapping is the contract — it survives consultant turnover, scope changes and statutory audit.
Send us AOT export + LedgerJournalTrans profile + Number Sequence list + AIF integration map. We will return your specialised mapping starter spreadsheet within 5 working days — ready for functional review.