ORACLE CLOUD ERP Common Set vs Custom Set

 

                                                                    ORACLE CLOUD ERP

Common Set vs Custom Set

 

1. Why This Topic Matters

When creating a Business Unit in Oracle Cloud ERP, the Default Set is easy to treat as a mandatory field and move on. But the set strategy can influence how set-enabled reference data is shared or separated across Business Units. The important design question is not “Which set should I select?” but “Which configuration should be common and which must be different?”

Simple rule: Use a Common Set when the business definition is genuinely common. Use a Custom Set when the definition must vary or be independently controlled for a Business Unit or group of Business Units.

2. Common Set vs Custom Set – In Simple Terms

Common Set	Custom Set
Shared definition across applicable Business Units.	Separate definition for a Business Unit or selected group of Business Units.
Best for enterprise standards.	Best for local or business-specific variations.
Less duplicate configuration.	More flexibility, but more configuration and governance.
Centralized maintenance.	More localized maintenance.
Useful when the business process is the same.	Useful when rules, rates, formats or policies differ.

3. The Key Design Question

·       Is the reference data the same across the Business Units?

·       Should it be centrally governed?

·       Does a country, BU, customer group or process require a different definition?

·       If it changes later, should all affected BUs change together?

Same + centrally governed → Common Set is usually appropriate. Different + independently governed → Custom Set is usually appropriate.

4. Real-Time Scenario – Accounts Payable

Imagine one enterprise has US, UK and Poland Business Units and suppliers are processed in all three countries.

AP Requirement	Common Set when…	Custom Set when…
Payment Terms	The same terms have the same meaning and policy everywhere.	Local payment terms or business policies differ.
Invoice-related reference data	The enterprise uses the same definitions.	Country-specific processing requires different definitions.
Procurement/Payables classifications	One standard taxonomy is required.	Local procurement practices require different values.
Tax-related reference configuration	The configuration is genuinely common and legally appropriate.	Country-specific tax rules require separate treatment.

Real-time impact: Separate sets for identical AP configuration create duplicate maintenance. A Common Set for genuinely different country requirements can force an inappropriate one-size-fits-all design.

5. Real-Time Scenario – Fixed Assets

FA Requirement	Common Set	Custom Set
Asset categories	Enterprise-standard categories.	Different category structures or classifications are genuinely required.
Asset reference values	Definitions and governance are common.	Local business rules require independent definitions.
Depreciation-related setup	Same policy/accounting requirement applies.	Local accounting or statutory requirements differ.
Corporate asset reporting	Common definitions improve consistent reporting.	Local definitions support country-specific reporting.

Important: A Set is not a substitute for the accounting design. Ledger, legal entity, asset book, depreciation method, tax/statutory requirements and security still need separate design.

6. Real-Time Scenario – Project Management

Projects makes the impact especially visible because project reference data can feed costing, billing, accounting and reporting.

Project Requirement	Common Set	Custom Set
Project Types	Enterprise types such as Implementation, Support and Internal are standardized.	Different BUs require materially different project definitions.
Project classifications	Common enterprise reporting classifications.	Local classification structure is required.
Project rates / rate schedules	Rates and governance are genuinely common.	Rates differ by country, BU, labor market or commercial policy.
Invoice formats	One invoice definition is valid.	Country/customer billing requirements differ.
Project accounting setup	Accounting behavior is intentionally common.	Business/accounting requirements differ and the object supports separate assignment.

7. One Project – One Invoice – One Asset: Why It Matters

Consider a project that receives costs through Payables, creates a project-based asset and is ultimately billed to a customer.

Flow	Common Set	Custom Set
AP invoice → Project Cost	Shared reference configuration supports the common process.	Local AP/project reference requirements are maintained separately.
Project Cost → Asset	Common project/asset classifications support standardized reporting.	Local asset requirements can be isolated where required.
Project → Billing	Common billing definitions reduce duplicate setup.	Local/customer billing rules can be maintained separately.
Reporting	Common definitions improve cross-BU comparison.	Custom definitions allow local reporting needs.

Key message: The Set decision is not only about the Business Unit screen. It can affect maintainability and consistency of the configuration supporting the end-to-end business process.

8. Cross-Module Comparison

Area	Common Set	Custom Set	Typical reason for Custom
AP	Standard supplier/payment/process reference data.	Local AP variation.	Country/business policy.
FA	Common asset definitions.	Local asset definitions.	Statutory/local requirements.
Projects	Common project definitions.	Local project/rate/billing definitions.	Commercial or operational variation.
Procurement	Enterprise purchasing standards.	Local purchasing requirements.	BU/category/process differences.
Reporting	Common taxonomy.	Local taxonomy.	Local reporting needs.

9. Practical Three-Country Scenario

Configuration	Example design	Why
Enterprise Project Types	COMMON_SET	Same project lifecycle and reporting terminology.
Corporate asset categories	COMMON_SET	Same enterprise asset classification.
Standard payment terms	COMMON_SET	Same centrally governed definitions where applicable.
Country-specific project rates	US_SET / UK_SET / PL_SET	Rates differ by country.
Country-specific invoice formats	Country/custom sets	Local/customer billing requirements.
Local asset/statutory requirements	Custom Set where supported/required	Local accounting/reporting needs.

10. Simple Decision Tree

1. Is the configuration identical across relevant Business Units? → Consider Common Set.

2. Should all affected BUs change together? → Common Set is generally appropriate.

3. Does one BU/country require different values or rules? → Consider Custom Set.

4. Do several BUs share the same variation? → Consider one Custom Set shared by those BUs.

5. Is the requirement about user/transaction access rather than reference-data sharing? → Design Data Security separately.

11. What a Set Does NOT Mean

·       A Common Set does not mean every user can access every transaction.

·       A Custom Set is not automatically a security boundary.

·       A Custom Set does not replace Business Unit data access.

·       A Set does not replace ledger, legal entity, asset book, project unit or accounting design.

·       The Default Set on the Business Unit page is not the complete security model.

12. Common Implementation Mistakes

Mistake	What happens
Create one Custom Set for every BU.	Duplicate configuration and higher maintenance.
Put everything in Common Set.	Local requirements become difficult or inappropriate to represent.
Use Set as security.	Users may still need separate data-access/security configuration.
Decide the Set only during configuration.	Downstream AP/FA/Projects design may need rework.
Ignore future changes.	A common definition may later need local variation; governance becomes difficult.

13. Solution Architect View

Layer	Purpose
COMMON_SET	Enterprise standards maintained once.
CUSTOM / SHARED SET	Controlled variation used by a subset of Business Units.
BU-SPECIFIC SET	Configuration genuinely belonging to one Business Unit.
DATA SECURITY	Controls which transactional records users can access.

The strongest architecture is usually a hybrid model. It avoids both excessive duplication and forced standardization.

14. Quick Design Checklist

Question	Decision
Is the definition identical?	Yes → Common candidate.
Must all BUs change together?	Yes → Common candidate.
Is there a country-specific rule?	Yes → Custom candidate.
Do multiple BUs share the same variation?	Yes → Shared Custom candidate.
Is the requirement about user access?	Use Data Security, not just Set.
Will configuration be reported across BUs?	Common definitions may simplify reporting.
Will local teams own maintenance?	Custom/shared custom may be appropriate.

15. Final Takeaway

Common Set = Standardize.  Custom Set = Differentiate.  Data Security = Control Access.

The right question is not “Which one is better?” It is “Where is the business definition truly common, and where does it need to be different?” For AP, Fixed Assets and Projects, make the decision at the reference-data-object level and validate it through the complete business flow. A well-designed set strategy reduces duplicate configuration, protects local requirements and makes the Oracle Cloud ERP solution easier to maintain.