Issue

Currently Syensqo is using 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 the classic SAP EHS system.

As part of Strategic Shift to Next-Generation Product Compliance SAP is modernizing its Product Compliance offering in S/4HANA to align with the latest industry needs, global regulations, and digital transformation trends. Compliance Requirements represent the future-proof solution as part of SAP’s roadmap, while Expert Rules stem from the older SAP EHS architecture, primarily built for ECC. Compliance Requirements allow businesses to use SAP-delivered Regulatory Content, reducing reliance on custom-coded rules. This ensures faster adaptation to regulatory updates (e.g., REACH, RoHS, PCN, SCIP) without heavy manual intervention. Expert Rules require specialized knowledge (ABAP, EHS scripting) for creation and maintenance, making them IT-dependent. Compliance Requirements are configuration-driven, enabling business users or compliance teams to own and maintain the rules directly without programming.

Recommendation

Recommendation: To Adapt Option B

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)

Pros:

• Instead of using separate tool like EHS Expert, everything is now integrated, smarter, and more flexible, right inside S4 HANA - or through connected services when needed.
• Content-Driven Compliance via SAP Regulatory Content
• Ease of Maintenance and Scalability

Cons:

• Loss of Flexibility and Custom Logic

Best For:

• Ensures long-term alignment with SAP's strategic direction, reducing risks of obsolescence.

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 predefined compliance requirements.

• 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, SVT are managed in S4 Classic and DG, SDS 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

• Functional Gaps and Feature Limitations

• Migration Complexity and Data Consistency

• 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

• Compliance Relevance Rule: A material or product must be marked as Compliance Relevant in the Product Master for compliance checks to be triggered via Compliance Requirements.
• Regulatory Scope Rule: Compliance Requirements must be defined and maintained for the specific regulatory areas relevant to the business (e.g., Marketability, Dangerous Goods, SDS, SVT, PCN).
• Process Trigger Rule: Compliance Requirements must be integrated into key processes such as: Sales Order Creation/Change, Outbound Deliveries, FU/FB/FB Creation
• Compliance Decision Rule: The outcome of Compliance Requirements must drive decision-making (e.g., Block Order, Allow Order, Generate Compliance Report, Trigger Notification).

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: Continue AS-IS

Description: ABAP logic, and executed through the Expert Server
                   Automated logic-based rules used to derive, validate, or calculate values in specifications, substances, properties, or other EHS master data.

Pros: Flexible, standard, no code

Cons: Technical Complexity - Requires ABAP development knowledge; not accessible to business users for direct maintenance.

          Hard to Maintain - Changes in regulatory content or business logic require rule updates, which can be time-consuming and error-prone.

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.

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.

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