Field-level sage 300 to oracle fusion data mapping: GLAMF → COA segments, per-company CUSTOMER → TCA parties, VENDOR → Suppliers, GLPOST → Journals, ITEM → Item Master. Governed, versioned, audit-signed.
The mapping is the spine of the migration. Get it right and every downstream load reconciles. Get it wrong and you discover the problem at parallel-run, six months and a million dollars in.
Sage 300 — descended from Sage Accpac, before that Computer Associates' Accpac, and originally Basic Software Group's Easy Business Systems from 1979 — carries the legacy of four decades of mid-market accounting practice. The data model reflects that: per-company SQL Server databases (one CUSTOMER table, one VENDOR table, one GLAMF, one GLPOST per company), segmented GL accounts whose segments vary by deployment, optional fields freely added by users, SDK-module custom tables wired into standard transactions, and Visual Basic scripts populating fields with site-local conventions.
Oracle Fusion's data model is fundamentally different. One TCA party model spans the enterprise. One Chart of Accounts spans every ledger. Suppliers, customers and items are master records shared across business units. Subledger Accounting (SLA) generates GL journals from subledger documents under governed accounting rules. The shape is centralised, modeled, and configurable through metadata rather than database extension.
Bridging the two requires explicit, field-level sage 300 to oracle fusion data mapping. Not a spreadsheet someone fills in once and forgets — a governed artifact, versioned in git, reviewed in working sessions by finance, ops, IT and audit, signed before any production-bound load executes, and replayable for every subsequent delta or correction load. That artifact is what Syntra ETL ships pre-built and refines for your specific Sage 300 deployment.
Where the rules live, what they do, and what gets reviewed at each working session.
Every active Sage 300 account across every company database profiled, segments analysed for material reporting splits, account-by-account crosswalk built. Custom segments routed to Fusion COA, DFFs or OTBI dimensions. Reviewed by finance leadership.
Per-company CUSTOMER deduplicated by name/tax-ID/address fingerprint. Unified TCA party + customer accounts per Fusion BU. Aging buckets reconcile against Sage 300 AR aged trial balance to the cent.
Per-company VENDOR deduplicated. Supplier sites for each Sage 300 remit-to/order-to address. Site assignments per business unit. 1099/T4A tax type, banking, payment method, hold history preserved.
Sage 300 postings grouped into journal headers (by company/period/source-doc or by batch), original Sage 300 source-document number preserved as Journal reference, routed to mapped Fusion COA combination. Trial balance reconciles to the cent.
Sage 300 ITEM master harmonised across companies, item categories mapped to Fusion Item Catalogs, costing history (standard/FIFO/LIFO/moving avg) routed, organisation-specific item assignments created. Inventory valuation reconciles per location.
Multicurrency rate history → Fusion Daily Rates with rate type preserved. Intercompany Transactions → Fusion Intercompany journals with original IC document numbers preserved. Period-end revaluation re-run in Fusion confirms unrealised gain/loss to the cent.
A repeatable working-session cadence that surfaces edge cases before they become production-bound problems. Typical end-to-end: 3–6 weeks.
Walk every Sage 300 company database. Profile GLAMF, CUSTOMER, VENDOR, ITEM, GLPOST. Inventory optional fields, custom SDK tables, Visual Basic-driven conventional codes. Output: source data dictionary with row counts, distinct-value distributions and customisation inventory.
Design Fusion COA segments with finance leadership. Design TCA party deduplication rules. Design supplier site structure. Design item catalog and item categories. Output: target structure design signed by finance and operations leadership.
Account-by-account GLAMF → COA crosswalk. CUSTOMER and VENDOR deduplication runs with manual review of close-match pairs. ITEM harmonisation. Reference-data mapping (source codes, posting profiles, tax authorities, item categories, payment terms, sales taxes).
Apply crosswalks to a representative slice (one company, three periods, full footprint). Load to Fusion test environment. Reconcile trial balance, AR aging, AP aging, inventory valuation against Sage 300. Iterate until the slice reconciles to the cent.
Apply crosswalks to the full Sage 300 estate. Validate at scale: row counts, sum totals per ledger per period per company, hash signatures. Surface any new edge cases (rare account/customer/item patterns not in the sample). Iterate mapping until full-scale runs reconcile.
Mapping artifact reviewed by internal audit. Versioned and frozen in git. Every subsequent production load (initial bulk, deltas, post-cutover corrections) references this version. Changes to the mapping post-freeze require formal change control.
Sage 300 customisations don't translate 1:1 to Fusion. Here's how each pattern is classified during sage 300 to oracle fusion data mapping.
Sage 300 user-defined fields on CUSTOMER, VENDOR, ITEM, GLAMF and transactions. Classified by usage in reporting/integration. Routed to Fusion DFFs on the corresponding entity, or preserved as cross-reference attributes.
Custom tables linked to standard tables via SDK. Inventoried by call signature. Routed to Fusion DFFs, integration attributes, or retired with sign-off if business purpose is covered by native Fusion functionality.
Visual Basic scripts writing site-local conventional values into existing fields (e.g. 'X-' prefix on customer ID meaning export customer). Decoded during mapping, routed to first-class Fusion attributes (classification codes, party usages, customer profile categories).
Sage 300 GL accounts with site-extended segments beyond the standard pattern. Profiled for material reporting splits. Routed to Fusion COA segments, DFFs or OTBI dimensions per reporting materiality and finance leadership decision.
Sage 300 posting profiles directing sub-ledger transactions to specific GL accounts. Mapped to Fusion Subledger Accounting (SLA) rules. SLA generates journals from sub-ledger documents per the new rules — eliminating the Sage 300 posting profile concept entirely.
Crystal Reports that read from custom tables or conventional codes. Inventoried during reporting migration assessment. Replacement OTBI/BI Publisher reports read from the corresponding Fusion DFFs or first-class attributes — preserving report continuity.
Sage 300 to oracle fusion data mapping is the discipline of translating Sage 300's per-company SQL Server data model into Oracle Fusion's enterprise data model — field by field, table by table, value by value. It covers GLAMF (account master) to Fusion Chart of Accounts segments, per-company CUSTOMER tables to Fusion TCA parties and customer accounts, VENDOR tables to Fusion Suppliers and supplier sites, GLPOST postings to Fusion Journal lines, AP/AR sub-ledger documents to Payables/Receivables transactions, ITEM master to Fusion Item Master, multicurrency rates to Daily Rates, and dozens of reference-data tables (source codes, posting profiles, tax authorities, item categories) to Fusion lookups, value sets and FlexFields. The mapping isn't a spreadsheet you fill in once — it's a governed artifact reviewed by finance, ops, IT and audit before any data is loaded.
Sage 300's GLAMF (GL Account Master File) stores accounts as a segmented string — typically 1–4 segments beyond the natural account, with common Sage 300 patterns being NaturalAccount-CostCentre or NaturalAccount-CostCentre-Department-Project. Oracle Fusion uses a flexible 6-segment Chart of Accounts (Ledger/Company-Cost Center-Account-Subaccount-Product-Intercompany is the typical shape but it's configurable). The sage 300 to oracle fusion data mapping for GL works in three steps: profile every active account across every Sage 300 company database to identify segment usage and material reporting splits, design the target Fusion COA with finance leadership review, and build the explicit account-by-account crosswalk file. Custom Sage 300 segments collapse into Fusion COA segments where reporting requires them, route to Fusion DFFs for analytical-only context, or feed OTBI dimensions for legacy reporting reproduction.
Sage 300's CUSTOMER table is per-company — each Sage 300 company database has its own CUSTOMER table with its own ID space, often with the same ID ('CUS0001') meaning entirely different customers in different databases. Oracle Fusion uses a unified TCA party model where one customer party can have multiple customer accounts across multiple business units. The sage 300 to oracle fusion data mapping for CUSTOMER walks every per-company CUSTOMER row, deduplicates by name/tax-ID/address fingerprint to produce unified TCA parties, then creates customer accounts under each party for each Fusion business unit where the customer trades. Original per-company CUSTOMER IDs are preserved as TCA account number cross-references for audit drill-back. Aging balances reconcile against Sage 300 AR aged trial balance to the cent.
Sage 300's VENDOR table is per-company with the same ID-collision issue as CUSTOMER. Oracle Fusion uses Suppliers with multiple supplier sites per supplier per business unit, plus a supplier party in TCA. The sage 300 to oracle fusion data mapping for VENDOR walks every per-company VENDOR row, deduplicates by name/tax-ID/banking-detail fingerprint, produces unified suppliers, creates supplier sites for each Sage 300 remit-to and order-to address, and creates supplier-site assignments per Fusion business unit. 1099 and T4A flags carry through (Sage 300's 1099 type code maps to Fusion's Income Tax Type), banking and payment-method preferences carry through, and hold/credit-limit history is preserved as a Fusion DFF for historical context.
Sage 300's GLPOST table is the transactional GL ledger — every journal entry from every sub-ledger and manual GL batch lands here as one row per debit/credit line, tagged with company, fiscal year, period, source code (AP/AR/IC/PM/GL etc), source document number and posting sequence. Oracle Fusion uses Journal Headers and Journal Lines under a Ledger, with Subledger Accounting (SLA) generating journals from Payables/Receivables/etc subledgers. The sage 300 to oracle fusion data mapping for GLPOST groups Sage 300 postings into Fusion journal headers (by company/period/source-document or by batch), preserves the original Sage 300 source-document number as a Fusion Journal reference, routes each posting to the mapped Fusion COA combination, and emits FBDI Journal Import payloads. Period-by-period trial balance reconciles Sage 300 vs Fusion to the cent.
Sage 300 customisations come in three flavors that affect data mapping: optional fields (Sage 300's user-defined field feature, attached to CUSTOMER/VENDOR/ITEM/GLAMF and to transactions), custom SDK-module fields stored in custom tables linked to standard tables, and Visual Basic-driven custom values written into existing fields with conventional codes. The sage 300 to oracle fusion data mapping process inventories every optional field, every custom table column, and every conventional-code pattern in production use. Each is classified: needed for reporting (route to Fusion DFF on the corresponding entity), needed for downstream integration (route to Fusion integration attribute), historical-only context (preserve as cross-reference attribute), or obsolete (drop with sign-off). The classification is reviewed by finance and ops before mapping is finalised.
Sage 300's Multicurrency module stores transactions in source currency, functional currency and (optionally) a reporting currency, with daily/spot/contract exchange rate history. The data mapping loads the Sage 300 rate history to Fusion's Daily Rates table preserving rate type (Spot/Corporate/User), source currency, target currency and effective date. Transactions are loaded with original source-currency amounts and Fusion re-derives the functional-currency conversion against the loaded rates — period-end revaluation re-runs in Fusion to confirm unrealised gain/loss matches Sage 300 to the cent. Sage 300 Intercompany Transactions map to Fusion Intercompany journals with original IC document numbers preserved as cross-reference. Consolidation eliminations re-modelled in Fusion ICA or EPM Consolidation as appropriate to the entity structure.
Typical sage 300 to oracle fusion data mapping is a 3–6 week stream inside the wider migration. It runs in parallel with the technical extract build (weeks 3–8 of the standard 14–22 week migration). Ownership is shared: Syntra ETL produces the mapping artifacts and runs the working sessions; finance owns COA segment design and account-by-account mapping sign-off; operations owns item-category, customer/supplier deduplication rules and reference-data mapping; IT owns DFF design and customisation classification; internal audit reviews and signs the final mapping artifact before any production-bound load runs. Mapping is versioned in git alongside the rest of the migration artifacts so every load run is traceable to a specific mapping version.
30-minute working session. Walk through your GL account structure, per-company customer/vendor estate, item master, customisation pattern and reporting requirements — leave with a concrete mapping plan, scope and timeline.