Issue

In the classic SAP EHS system, Expert Rules (developed using Expert Rule Editor in CG02) are widely used to automate processes as part determination of secondary data like classification, property value calculation, and data inheritance.

In S/4HANA Product Compliance New Functionality, there is no direct support for Expert Rules. 
However, the logic to determine secondary data is build into compliance requirements.
- e.g. for marketability by integrated “Substance list check” pattern
• Compliance requirements are processed
– Directly within S/4HANA system à logic is programmed in ABAP
– As a service à logic is hidden behind service interface, executed remotely, results are 
stored in S/4HANA
• Customers can define their own compliance requirements (based on existing patterns)

Recommendation

Replace Classic Expert Rules with a combination of:

• Compliance Requirements (via Embedded Content)
• Business Rule Framework plus (BRF+)

01. Compliance Requirements (via Embedded Content):
• Compliance requirements are processed
– Directly within S/4HANA system à logic is programmed in ABAP
– As a service à logic is hidden behind service interface, executed remotely, results are 
stored in S/4HANA
• Customers can define their own compliance requirements (based on existing patterns)

02. Business Rule Framework plus (BRF+):

Background & Context

• In legacy SAP EHS (CG02-based), Expert Rules were used to:

  • Auto-derive property values.

  • Copy composition data.

  • Apply regional compliance logic.

• Expert Rule functionality is not carried forward in the new Fiori-based Product Compliance apps.

• SAP now promotes rule-based checks via integrated services, supported by BRF+, predefined compliance patterns, and marketability rules.

• Logic for data consistency checks is build into the data management apps

• Logic to determine secondary data is build into compliance requirements

          - e.g. for marketability by integrated “Substance list check” pattern

          - e.g. for SDS content via partner solution “Intelligent SDS authoring” by 3E1

Logic to check marketability status or dangerous goods transport allowance of a 
product is either

– Part of the compliance requirements, or
– Part of the process integration

 Compliance requirements are processed

– Directly within S/4HANA system à logic is programmed in ABAP
– As a service à logic is hidden behind service interface, executed remotely, results are 
stored in S/4HANA

 Customers can define their own compliance requirements (based on existing patterns)

Assumptions

• Customer is migrating to or already using S/4HANA Product Compliance (New).

• Composition data, DG, SVT, and Marketability checks are managed in the new compliance framework.

• Business rules used in classic Expert Rules are still relevant and required post-migration if Product Classification and SDS Authoring is in S4 Classic.

Constraints

• BRF+ and new rule mechanisms may not cover 100% of legacy Expert Rule logic.

• Regulatory rule subscriptions (like SAP Content) may be required to replicate certain automated checks.

• Custom logic via BAdIs might increase implementation effort and complexity.

• There’s no UI-based Rule Editor as intuitive as the CG02 Expert Rule Editor.

Impacts

Business Rules

Examples of business rules to be rebuilt:

• Copy composition from reference material

• If DG classification = X, then apply specific packaging group

• If substance is SVHC, then block marketability in EU

• Calculate concentration sum for a regulatory group

These can be re-implemented using:

• Compliance Rule Patterns

• Marketability Templates

• BRF+ functions

• Regulatory content from SAP

Options considered

List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.

Option A: Compliance Requirements

Description: Directly within S/4HANA system à logic is programmed in ABAP
                   As a service à logic is hidden behind service interface, executed remotely, results are 
                   stored in S/4HANA

Pros: Flexible, standard, no code

Cons: Compliance Requirements do not derive values (e.g., hazard class, phrases) — unlike Expert Rules which could auto-populate the property tree.

Option B: BRFplus-based Rules

Description: Implement business logic in BRFplus for decision-making

Pros: Flexible, standard, no code

Cons: Limited in handling highly complex logic

Option C: Hybrid Model

Description: Use BRFplus for simple rules and BAdIs for complex ones

Pros: Best of both worlds

Cons: Needs more governance to avoid fragmentation

Option D: Manual Processes

Description: Defer automation; maintain values manually

Pros: Quick initial deployment

Cons: Prone to human error, not scalable

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

	Option A	Option B	Option C	Option D
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log