Reference Data Sets in Oracle Fusion Cloud Financials

Introduction

In the earlier topics, we covered the enterprise, legal entities, legal reporting units, and business units. Once these structures exist, the next question is how to manage the large volume of configuration data that those units depend on, such as payment terms, transaction types, tax codes, and payment methods. Defining this data separately for every business unit would be repetitive and error-prone. Oracle Fusion solves this with Reference Data Sets, a mechanism that lets organizations share setup data across business units while still keeping the flexibility to separate it when needed.

1. What Is a Reference Data Set?

A Reference Data Set (RDS), often just called a Set, is a logical grouping of setup data that can be shared across multiple business units or other organizational entities. Instead of storing configuration records against a single business unit, Fusion stores them against a set, and business units then point to the set.

In simple terms:

A set is a container for configuration records.
A business unit is assigned to one or more sets, depending on the type of data.
Any business unit assigned to a set can use the records in that set.

This approach avoids duplicate entry. If ten business units use identical payment terms, you define the terms once in one set and assign all ten units to that set.

2. Why Reference Data Sets Exist

Large organizations often have dozens or hundreds of business units. Many of their setups are identical, while some differ by country, line of business, or process. Reference data sets address three needs:

Reduce duplication: Define common data once and share it.
Allow controlled variation: Where data must differ, create separate sets and assign them to the appropriate units.
Simplify maintenance: Changing a record in a shared set updates it for every business unit using that set.

Without sets, administrators would have to maintain identical records in every business unit, and inconsistencies would creep in over time.

3. Key Concepts

Set Types and Reference Data Objects

Fusion does not apply sets uniformly to all data. Instead, each type of shareable data is called a reference data object (or reference data group), and each object is configured to be shared in a particular way. Examples relevant to Financials include:

Payment terms
Transaction types in Receivables
Transaction sources
Memo lines
Receipt methods and remittance banks
Tax-related setups in some cases
Jobs, grades, and locations in HCM
Project-related reference data

For each object, the determinant type controls how the system decides which set applies to a particular transaction.

Determinant Types

A determinant is the attribute used to select which set is relevant when a user works with a record. The common determinant types are:

Business Unit: The set is chosen based on the business unit of the transaction. This is the most common in Financials. For example, when a user creates a payables invoice in a particular business unit, only payment terms from the set assigned to that BU are available.
Asset Book: Used in Fixed Assets for data tied to an asset book.
Cost Organization: Used in cost management and inventory.
Project Unit: Used in Project Portfolio Management.
Reference Data Set: Used when records are not tied to an organization but to a set directly.

Knowing the determinant for each object is critical, because it tells you which organizational entity you must assign a set to.

4. The Common Set and Standard Sets

Common Set

Fusion provides a predefined set called the Common Set. Data placed in the Common Set is available to every business unit, regardless of its own set assignments. It acts as a universal pool.

Typical uses:

Payment terms that apply across the entire enterprise.
Standard transaction types used by all business units.

When a user in any business unit looks up a list of values, the results typically include records from the business unit’s assigned set plus records from the Common Set, depending on how the object is configured.

Business-Unit-Specific Sets

Organizations also create their own sets, for example:

A US set for payment terms specific to US customers and suppliers.
A UK set for local conventions.
A set for a particular line of business.

Each business unit is then assigned to the relevant set for each reference data object.

Default Set

When a business unit is created, you assign it a default set. This default is used for any reference data object that does not have a specific assignment. Many implementations rely on one default set per business unit, then override it only for objects needing different treatment.

5. Set Assignments

The link between a business unit and a set is called a set assignment. It is defined for each reference data object and determinant combination.

For example:

Business Unit	Reference Data Object	Assigned Set
US Sales BU	Payment Terms	US Set
US Sales BU	Receivables Transaction Types	US Set
UK Sales BU	Payment Terms	UK Set
UK Sales BU	Receivables Transaction Types	Common Set

Assignments are maintained through the Manage Set Assignments task. This task is found in Setup and Maintenance under the Define Reference Data Sharing functional area.

When a business unit is created through the Enterprise Structure Configurator or the Manage Business Units task, you can specify its default set, and the system creates the basic assignments automatically.

6. Setup Tasks

Several tasks relate to reference data sharing:

Manage Reference Data Sets: Create, edit, and end-date sets. Each set has a code, name, and description.
Manage Reference Data Set Assignments: Assign sets to business units (or other determinants) for each reference data object.
Assign Business Units to Sets: Typically done as part of business unit creation.
Manage Reference Data Sharing Configuration: Available in certain contexts to review how each object is shared.

These tasks live under the Define Reference Data Sharing area and are often part of the broader Define Enterprise Structures and Define Business Units flows.

7. How Sharing Works at Runtime

Consider a Receivables user creating a transaction:

The user selects a business unit, say “US Sales BU.”
The application checks the set assignment for that business unit and the object, here Receivables transaction types.
It finds that “US Sales BU” is assigned to the “US Set” for this object.
The list of values shows transaction types belonging to the US Set plus those in the Common Set (where applicable).
The user selects a transaction type, and the transaction proceeds.

The same logic applies to payment terms, memo lines, and other shared objects. Because the filtering is automatic, users only see data relevant to their business unit, which reduces errors.

8. Sharing Across Different Organizations

Reference data sets are not limited to business units. Depending on the object, the determinant may be:

Asset Book for Fixed Assets setups.
Cost Organization for costing.
Project Unit for project data.

This means the same set concept works across Financials, Supply Chain, and Project modules, giving a consistent method of sharing configuration across the whole application suite.

9. Practical Example

Consider “Global Foods Group” with four business units:

US Sales BU
Canada Sales BU
UK Sales BU
Germany Sales BU

The finance team plans the sets as follows:

Common Set: Payment terms such as “Net 30” and “Net 60,” which are used everywhere.
North America Set: Transaction types and memo lines used by the US and Canada.
Europe Set: Transaction types and receipt methods used by the UK and Germany, including SEPA-related methods.

Assignments:

US Sales BU and Canada Sales BU are assigned to the North America Set for transaction types and memo lines.
UK Sales BU and Germany Sales BU are assigned to the Europe Set for the same objects.
All four rely on the Common Set for payment terms.

When a clerk in the Germany Sales BU creates an invoice, they see Europe Set transaction types and Common Set payment terms. A clerk in the US Sales BU sees North America Set transaction types, and the same common payment terms. A new BU for the Netherlands could simply be assigned to the Europe Set without recreating any data.

10. Reference Data Sets in HCM and Other Pillars

Reference data sets are not exclusive to Financials. In HCM, sets are used for objects such as jobs, grades, departments, and locations, with business units often used as determinants. Because the enterprise structure is shared across Fusion pillars, a set defined for one pillar may also be assigned to a business unit used by another. This is why the design of sets should involve stakeholders from Finance, HR, and Supply Chain together.

11. Best Practices

Plan the set strategy early. Decide which data will be shared enterprise-wide, which will be regional, and which will be unit-specific before creating records.
Use the Common Set for truly global data. Items such as standard payment terms are good candidates. Avoid overloading it with data that should be restricted.
Keep the number of sets manageable. Too many sets increase assignment effort and the risk of mistakes.
Name sets meaningfully. Use names reflecting scope, such as “US_SET” or “EMEA_SET,” for easy identification.
Assign a sensible default set to each business unit and override only where needed.
Understand each object’s determinant type before creating assignments.
Review set assignments when adding new business units. A new BU without proper assignments may see empty lists of values.
Document the design, including which objects use which sets and why.
Test with representative users to confirm that each business unit sees the expected data.

12. Common Mistakes to Avoid

Creating records in the wrong set, so users in a business unit cannot see them.
Forgetting to assign a business unit to a set after creating it, leading to empty lists of values.
Using the Common Set for everything, which removes control over regional differences.
Creating a separate set for every business unit, which defeats the purpose of sharing.
Ignoring determinant types, resulting in confusion about where to assign sets.
Changing set assignments after transactions exist without understanding the impact on existing data and validations.
Not coordinating with HCM or Supply Chain teams, who may share the same business units and sets.

13. Troubleshooting Tips

If a user reports that a setup value, such as a payment term, is missing from a list:

Confirm the business unit being used on the transaction.
Check the set assignment for that business unit and the relevant reference data object.
Verify the record exists in the assigned set or the Common Set.
Confirm the record is active and its effective dates cover the transaction date.
Check the user’s data access to ensure they can access the business unit.

These steps resolve most issues related to missing reference data.

Conclusion

Reference Data Sets are Oracle Fusion’s mechanism for sharing configuration data across business units and other organizations. By grouping records into sets and assigning those sets through determinants such as business unit, asset book, or cost organization, Fusion removes redundant setup while preserving the flexibility to vary data where required. The Common Set offers a universal layer, while custom sets support regional or functional differences.

A thoughtful set design reduces maintenance, improves consistency, and gives each business unit exactly the data it needs. Combined with the enterprise, legal entity, legal reporting unit, and business unit structures, reference data sets complete the foundation for an Oracle Fusion Financials implementation that is scalable, consistent, and easy to maintain.

O SUPPORT

Search This Blog