JD Edwards to Oracle Fusion Mapping — Field by Field

Jd edwards to oracle fusion mapping is the field-level translation layer between JDE's table-oriented data model (F-series tables with 4-letter prefix conventions, BU+Object+Subsidiary GL structure, 30 category codes on F0006 Business Units) and Fusion's object-oriented data model (Legal Entities, 6-segment COA, Item Master with catalog hierarchies, TCA party model for Suppliers, HZ schema for Customers, SLA sub-ledger accounting). The mapping covers GL (F0011 Company Constants and F0901 Account Master → Fusion ledger and natural-account segment), AP (F0411 voucher → Fusion AP Invoice with payment, tax and aging context), AR (F03B11 invoice → Fusion AR Transaction with cash-receipt context), Item (F4101 + F4102 + F4105 → Fusion Item Master + Branch/Plant + Item Cost layers), and Address Book (F0101 → Fusion Supplier TCA / Customer HZ / Worker split by AT code). Every field has an explicit source-to-target rule that the controllership and SCM ops sign off before FBDI generation runs.

JDE F0011 (Company Constants — note: some JDE generations also expose this as F0010) holds each company's fiscal-year-pattern, currency, financial-reporting calendar and ledger-rounding precision. Each JDE Company maps to a Fusion Legal Entity (LE), and the LE links to a Fusion Primary Ledger that carries the fiscal calendar, accounting currency and chart-of-accounts. Multi-company JDE estates running multiple base currencies require multiple Fusion Primary Ledgers (one per accounting currency), with Secondary Ledgers and Reporting Currencies layered for consolidation. The mapping rules surface explicitly: which JDE company → which Fusion LE; which LE → which Primary Ledger; which Secondary Ledger covers translation. The fiscal-year-pattern in F0011 is reconciled against the Fusion accounting calendar period-by-period before any F0911 history loads.

F0901 (Account Master) defines the JDE chart of accounts at the Business Unit + Object + Subsidiary grain. The jd edwards to oracle fusion mapping treats Object as the natural-account segment in Fusion (the primary accounting categorisation), Subsidiary as a sub-account or product segment depending on usage, and Business Unit as the cost-center segment with hierarchy derived from F0006 BU master parent relationships. The 30 category codes on F0006 route to additional Fusion segments (commonly Product, Project, Intercompany, Future) or to descriptive flexfields (DFFs) where they carry attribute context rather than accounting context. Every F0901 row is walked, classified, and surfaced as either mapped (the rule produces a deterministic Fusion COA combination) or unmapped (the controller must decide). Nothing silently defaults.

F0411 carries the AP voucher header and one-or-more lines per voucher (RPDOC + RPDCT key with RPPCT line type for distribution lines and tax lines). The mapping translates each voucher to a Fusion AP Invoice (invoice header in AP_INVOICES_ALL, distribution lines in AP_INVOICE_DISTRIBUTIONS_ALL, payment schedules in AP_PAYMENT_SCHEDULES_ALL). The supplier reference on F0411 (RPAN8 → Address Book number) maps to the Fusion Supplier loaded from the F0101 split. The accounting distribution on F0911 (which carries the GL impact of the voucher posting via DOC=PV typically) maps to the Fusion AP invoice distribution at the post-crosswalk 6-segment COA. Tax lines on F0411 (where Vertex O Series / Sovos / Avalara integrated) map to Fusion Tax via the tax-recovery and tax-distribution rules. Payment status carries forward — open, on hold, paid, voided — via the F0413/F0414 payment header/detail join.

F4111 (Item Ledger) is the JDE inventory transaction log — every receipt, issue, transfer, adjustment, work-order completion and consumption keyed by Item × Branch/Plant × Document Type (DCT) × Document Number. The mapping translates each F4111 transaction to a Fusion Inventory Material Transaction at the equivalent Item × Inventory Org × Transaction Type. For value, the mapping respects JDE's item-cost-method differences per branch (F4105 stores frozen, current, last cost layers per Item × Branch; the cost-method per Branch determines which layer values the transaction). Manufacturing work-order transactions on F4111 (DCT = IM for work-order issue, IC for completion) preserve the work-order genealogy via F4801 → F3111 → F3112 → F31122 chain, so a finished-good completion in Fusion traces back through routing operations, time transactions and parts consumption.

F0101 is JDE's single Address Book master — suppliers, customers, employees, ship-to addresses, sites and intercompany entities all live in the same table, classified by Search Type (AT, e.g. V for vendor, C for customer, E for employee, X for ship-to). The mapping engine walks F0101 by AT code and routes each address-book entry to the appropriate Fusion target: AT=V → Fusion Supplier (TCA party + Supplier + Supplier Site), AT=C → Fusion Customer (HZ_PARTIES + HZ_CUST_ACCOUNTS + HZ_CUST_SITE_USES_ALL), AT=E → Fusion Worker via HCM Data Loader (worker, employment, assignment). Multi-role address-book entries (an entity that is both a supplier and a customer — common in intercompany or in distributor networks) are split into both Fusion targets with a cross-reference attribute preserved. Duplicate detection and golden-record harmonisation runs across the split before load — critical for multi-instance JDE consolidation where the same supplier may exist under different RPAN8 numbers in different instances.

Yes — and the mapping handles category codes deliberately because they are where JDE customers built their reporting language over the years. F0006 (Business Unit Master) carries 30 alphanumeric category codes (RP01 through RP30). F0901 (Account Master) carries its own set. F4101 (Item Master) carries item category codes. F0101 (Address Book) carries address-book category codes. Each category code is profiled during the assessment, classified by usage (accounting routing vs reporting attribute vs ad-hoc), and mapped to either an additional Fusion COA segment (where it drives accounting), a Descriptive Flexfield (DFF) on the corresponding Fusion entity (where it drives reporting or attribute), or retired (where it became obsolete or duplicates a standard Fusion attribute). The mapping is reviewed and signed off by controllership and the BU finance leads before FBDI generation — no silent loss of reporting categorisation.

JDE work-order data lives across F4801 (Work Order Master — the order header), F3111 (Work Order Parts List — the components consumed), F3112 (Work Order Routing — the operations performed), F31122 (Work Order Time Transactions — the labor and machine time recorded against operations) and F31114 (Work Order Inventory Issues). The mapping translates the chain to Fusion Manufacturing: F4801 → Fusion Work Definition + Work Order; F3111 → Work Order Operation Material; F3112 → Work Order Operation; F31122 → Work Order Operation Resource Transaction; F31114 → Work Order Material Transaction. The work-order genealogy is preserved: a Fusion Work Order ties back to the originating JDE work-order number via a cross-reference attribute, and the full labor variance, material variance and overhead absorption is reproducible. For customers archiving (rather than loading) closed work orders, the same chain Parquet-archives with hash-signed lineage.