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

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

	Option A: Continue AS-IS	Option B: Compliance Requirement	Option C	Option D
System Integration	Con: Complex Customization and Maintenance:-Even minor changes may require deep understanding of EHS data structures, rule sequences, and integration dependencies. Con: Limited Reusability:- Expert Rules are tightly coupled to specific EHS data models and not reusable across modules like Product Compliance, Dangerous Goods, or SVT without significant rework.	Pro Pro	Pro Con	Pro Con
Compliance Management	Con: Compliance Management:- Hard to adapt to complex or dynamic regulations	Con	Pro Pro	Con Con
Maintenance	Con: Requires technical effort for every update Con: Scalability:-Performance issues in large datasets Con: Reusability:- Rules are tightly scoped and hard to generalize across processes	Con	Con	Pro

See also

Change log