Microsoft Dynamics GP to Oracle Fusion Mapping Guide — GL, AP, AR, Items, Open Documents

A complete dynamics gp to oracle fusion mapping covers every persistent data domain that bridges the two ERPs. On the General Ledger side that means GL00100 account master segments translating to Fusion's 6-segment chart of accounts plus GL30000 posted journal history routed to Fusion GL via FBDI Journal Import. On the subledger side it covers PM00200 vendors to Fusion suppliers, RM00101 customers to Fusion customers/parties, IV00101 items to Fusion items, the open AP/AR documents in PM10500 and RM10301, the posted history in PM30200 and RM30201, and the open SOP/POP documents with their distribution lines. Beyond data, it also covers value sets (territories, payment terms, tax codes, currencies), security roles, Dexterity DFF candidates and SmartList Builder report inventory. Every mapping is reviewed and signed off by finance, AP, AR and ops before extract begins.

GP's account framework is configurable: segment count can be anywhere from 1 to 10, segment widths vary, and the segment order is not fixed. A real dynamics gp to oracle fusion mapping for GL00100 starts with a per-company audit of the framework — segment count, width, segment description from GL00102, and the live account combinations actually used in GL30000 over the retention window. The mapping then defines a target Fusion 6-segment COA (typically Company, Cost Center, Account, Product, Intercompany, Future) and a crosswalk for every active GP combination. Where multiple GP companies use slightly different frameworks, the mapping normalises them to the unified Fusion COA — surfacing inconsistencies (e.g. one company uses a department segment, another rolls department into the natural account) for finance to resolve before load.

PM00200 vendor master maps to Fusion supplier (HZ_PARTIES + POZ_SUPPLIERS_INT for FBDI Supplier Import). The dynamics gp to oracle fusion mapping handles the obvious fields directly — Vendor ID → Supplier Number, Vendor Name → Supplier Name, Tax ID (TIN) → tax registration, payment terms, 1099 status, primary address. The interesting work is de-duplication across company DBs: the same physical vendor often exists in 3–6 different company DBs with subtly different vendor IDs, names and payment-term codes. The mapping defines survivorship rules (most-recent activity wins, longest 1099 history wins, or canonical name list from AP master) signed off by AP ops before merge. Address book records map to Fusion supplier sites with the GP address ID becoming the site code.

RM00101 customer master maps to Fusion customer master (HZ_PARTIES + HZ_CUST_ACCOUNTS, loaded via FBDI Customer Import). The dynamics gp to oracle fusion mapping handles Customer ID → Customer Number, Customer Name → Customer Account Name, billing/shipping addresses → customer sites, payment terms, credit limits, salesperson assignments, tax exempt status. Customer-class hierarchies from RM00103 map to Fusion customer profile classes. Apply history from RM30201 — which cash receipt was applied to which invoice and when — is critical and maps via FBDI AR Invoice + Receipt Import so aging in Fusion reflects exact GP aging post-cutover. Multi-company customer master is de-duplicated using the same survivorship pattern as vendors.

IV00101 item master maps to Fusion items in Product Hub / Inventory (loaded via FBDI Item Import). The dynamics gp to oracle fusion mapping handles Item Number → Item, descriptions, UOM (GP UOM schedules from IV40201 map to Fusion UOM classes), item class assignments from IV00102, primary vendor relationships, costing method (FIFO/LIFO/Average map to Fusion cost methods), site assignments and site quantities from IV10200. Where GP installations have used Dexterity custom fields on the item master (extra columns added by ISV add-ons or partner customisations), the mapping classifies each by reporting materiality and routes to Fusion DFFs or value-sets — or retires fields that are redundant under Fusion's native capability.

Open documents are the operationally critical mapping. Open AP vouchers from PM10500 (with line distributions from PM10600) map to Fusion AP open invoices via FBDI AP Invoice Import — each voucher loaded with its current open balance, original invoice date, due date, vendor site and account distribution preserved. Open AR invoices from RM10301 map to Fusion AR open invoices via FBDI AR Invoice Import with the same fidelity. The dynamics gp to oracle fusion mapping also preserves the apply-history chain for partially-applied documents: an invoice with two partial cash applications in GP shows up in Fusion with the same applied amount, same outstanding balance and same aging bucket. Reconciliation confirms vendor aging and customer aging match GP-to-Fusion to the cent before cutover.

Yes. The historical posted tables (GL30000 posted GL, PM30200 posted vouchers, RM30201 posted apply history, SOP30200/SOP30300 sales history, POP30100/POP30110 PO history) are mapped either into Fusion's transactional store (if the customer wants live queryable history in Fusion) or into the long-term Syntra cloud archive (if Fusion is for go-forward only and history stays archived). Either way, the dynamics gp to oracle fusion mapping preserves the full SOX trace from GL journal line → subledger distribution → source document, with hash-signed audit evidence. IRS Pub 583 7-year retention and HMRC 6-year retention are satisfied; SOX trace remains intact; state sales-tax retention (3–7 years by jurisdiction) is covered.

For a 3–6 company GP installation with full module footprint (GL, AP, AR, IV, SOP, POP, FA, Bank Rec), the mapping document — including per-company COA crosswalks, vendor/customer cleanse and de-dup rules, item rationalisation, payment-term and tax-code crosswalks, Dexterity field classification and SmartList rebuild plan — takes 3–5 weeks with Syntra ETL's discovery engine doing the heavy lifting on inventory. A consultant-led equivalent typically takes 12–16 weeks because every domain is built from scratch. Once the mapping is signed off by finance, AP, AR, ops and IT, extract and load run against it without re-litigating the design — which is where most GP-to-Fusion projects lose months.