SAP Community - SAP S/4HANA Cloud Extensibility

SAP EHS Public Cloud: Extending Your Existing Landscape Side-by-Side - Guidebook (Part 5)

2025-12-08T08:01:00.504000+01:00

Integrating SAP EHS Public Cloud: Extending Your Existing Landscape Side-by-Side - Guidebook

Part 5: Extensibility Scenarios & Further Implementation

Table of Contents:

1. Introduction: Why Extensibility Matters in EHS Implementations

Implementing SAP Environment, Health & Safety (EHS) in the Public Cloud provides customers with a powerful set of standard capabilities across EHS functionality such as Incident Management, Risk Management, or Emissions Management. However, real-life EHS processes often include country-specific regulations, industry-dependent reporting obligations, and customer-individual workflows that cannot always be covered by the standard product alone. This is where extensibility becomes a critical success factor.

From our project experience, we see that nearly every EHS implementation requires selected adaptations – whether to incorporate local legal requirements, enrich analytics, adjust incident forms, or create custom validations. With SAP S/4HANA Public Cloud and SAP EHS, such enhancements must follow SAP’s clean-core principles, meaning they must be implemented using the officially supported extensibility technologies.

This blog post provides a clear, practical overview of the extensibility options available for SAP EHS in the Public Cloud and demonstrates how they can be applied to real-world scenarios.

1.1 What You Can Expect from This Blog Post

In this part, we outline the extensibility landscape for EHS Public Cloud and guide you through:

Which extensibility options exist in SAP S/4HANA Public Cloud
How they apply specifically to EHS use cases
Which BAdIs are available and when to use them
Concrete examples for extensibility
Best practices based on our project experience

The aim is to give implementation teams a practical understanding of how to adapt the system without breaking the clean core, ensuring long-term upgradeability and compliance.

1.2 Why Extensibility is Especially Important for EHS

From our project experience, EHS is one of the most extensibility-driven domains in SAP S/4HANA Public Cloud because:

Regulations differ significantly by country (e.g. OSHA, EU directives, etc.)
Incident reports must reflect local legal requirements
Customers require tailored analytics and KPIs
Integration with external safety systems is common
Forms and regulatory outputs often need custom structures

EHS processes must adapt to organizational legal, and operational needs. Extensibility in Public Cloud ensures this adaptability without compromising SAP’s clean-core principles.

2. Extensibility Options in SAP S/4HANA Public Cloud

SAP S/4HANA Public Cloud provides a comprehensive extensibility portfolio designed to support innovation without compromising the stability of the core system. These capabilities range from low-code configuration tools for business users to pro-code development environments for technical teams. Understanding these options is essential for designing scalable, future-proof EHS solutions – especially in Public Cloud environments where clean-core principles are mandatory.

Extensibility Portfolio for SAP S/4HANA Cloud Public Edition (Own illustration based on SAP source: https://www.sap.com/documents/2018/05/606d1ee8-037d-0010-87a3-c30de2ffd8ff.html)

2.1 Low-Code vs. Pro-Code Extensibility

The extensibility portfolio is structured along two axes:

Low-Code: Target at key user and functional experts who need to quickly adapt user interfaces, create fields, or adjust logic without deep technical development.
Pro-Code: Designed for professional developers who require advanced capabilities through the ABAP Cloud development model or SAP BTP services.

These options are distributed across two major extensibility categories: On-Stack Extensibility (In-App) & Side-by-Side Extensibility.

2.2 On-Stack Extensibility (In-App)

Executed directly inside SAP S/4HANA Public Cloud, following the clean-core principles enforced by SAP.

Key User & Developer Extensibility

2.2.1 Key User Extensibility (Low-Code)

Accessible directly via the SAP Fiori Launchpad, key user extensibility enables business focused adjustments such as:

UI adaptation mode: Modify screen layouts, hide/show fields, rearrange sections.
Custom fields: Create and publish custom fields that automatically extend UI, APIs, CDS views, and reports.
Custom logic (using BAdIs or BDEF extensions): Implement small logic enhancements using predefined extensions points.
Custom business objects: Model simple new business objects without coding.
Custom CDS views & OData services: Build analytical and integration-ready views with drag-and-drop tooling.
Analytical queries and applications: Extend reporting and KPIs in SAP Fiori or SAP Analytics Cloud.

Key User Extensibility is ideal for EHS teams that need to adapt processes quickly, e.g. adding a regulatory field in Incident Management or creating country-specific reporting structures.

2.2.2 Developer Extensibility (Pro-Code)

Developer Extensibility is performed using ABAP Cloud in Eclipse via ABAP Development Tools (ADT), enabling professional developers to build upgrade-safe extensions inside the SAP S/4HANA Cloud stack.

Typical capabilities include:

UI adaptation projects via SAP Business Application Studio
Extension fields built using professional ABAP development tools
Custom logic (BAdIs and BDEF extensions) with advanced editor capabilities
RAP Business Objects (full-fledge RESTful ABAP applications)
CDS views and OData services with full development tooling
Analytical queries and custom analytical content

This level of extensibility is used when EHS implementations require more complex data models, multi-step validations, or custom processes beyond the key user scope.

2.3 Side-by-Side Extensibility

When requirements cannot be fulfilled within the S/4HANA Cloud stack, SAP BTP provides a powerful platform for building complementary applications:

SAP Build Apps (no-code mobile and web apps)
SAP Build Process Automation (workflows and automations)
SAP Build Work Zone (custom dashboard and portals)
SAP Build Code / CAP (cloud-native pro-code development, Node.js/Java)
ABAP Environment on BTP (Steampunk) for ABAP Cloud side-by-side extensions

Side-by-side extensibility is particularly relevant for EHS when:

complex mobile solutions are required (e.g. hazard observations, audits)
workflow automation or robotic processing is desired
large-scale integration scenarios (e.g., IoT sensors, safety systems) are needed
custom employee or contractor portals must be built

Although side-by-side extensibility plays an important role in the overall SAP extensibility strategy, we will not dive deeper into BTP-based extensions in this blog post. Our objective is to demonstrate what can be achieved directly within the SAP S/4HANA Public Cloud, using standard in-app extensibility options that remain fully aligned with SAP’s clean-core principles. Based on our project experience, most EHS related enhancements such as custom fields, logic, reporting extensions, and form adaptations can be delivered efficiently using Key User or Developer Extensibility (on-stack). For this reason, the upcoming chapters focus exclusively on in-app, upgrade-safe extensibility scenarios that can be implemented without additional BTP architecture.

2.4 BAdIs in the Public Cloud (Key User vs. Developer Access)

Business Add-Ins (BAdIs) are predefined extension points provided by SAP that allow injecting custom logic while staying upgrade safe. You can explore the available BAdIs for the SAP S/4HANA Public Cloud here: Business Add-Ins | SAP S/4HANA Cloud Public Edition Business Add-Ins (BAdIs) | SAP Business Accelerator Hub

There are two categories in S/4HANA Public Cloud:

Key User BAdIs

Implemented through the Custom Logic SAP Fiori app
Available only for selected business contexts
Designed for simple enhancements such as: Validation rules, Derivation of field values, Basic calculations

Developer BAdIs

Implemented using ABAP Development Tools (ADT) in SAP BTP ABAP Environment or Embedded Steampunk
Allow more complex coding scenarios
Enable interaction with APIs, CDS views, RAP BOs and advanced data handling

In EHS specifically, SAP provides a growing set of BAdIs – particularly in Incident Management and Emissions Management – which are essential for country specific reporting, custom form generation, or regulatory compliance.

The following list provides an overview of the EHS-specific BAdIs that are currently available in the SAP S/4HANA Public Cloud.

Incident Management

BAdI: Change of Field Values in BG (Berufsgenossenschaft) Incident Report (Key User)
BAdI: Retrieval of Incident Basic Information (Key User)
BAdI: Retrieval of Custom Field Incident Data (Key User)
BAdI: Retrieval of Involved Person Data (Key User)
BAdI: Retrieval of Incident Root Data (Key User)

Risk Management

(No BAdIs available for Risk Management in Public Cloud yet)

Emissions Management

BAdI: Field Control for Extension of Amount Root (Key User)
BAdI: Check Amounts State and Perform Subsequent Actions (Key User & Developer)
BAdI: Generation of Export Files (Key User & Developer)
BAdI: Compliance Requirement Import from XLSX (Key User & Developer)
BAdI: Automatic Data Collection Import (Key User & Developer)
BAdI: Automatic Data Collection Import from XLSX BAdI (Key User & Developer)
BAdI: Automatic Data Collection XLSX Parser BAdI (Key User & Developer)
BAdI: Field Control for Extension of Data Collection Root (Key User)

As the overview shows, the currently available BAdIs for EHS in the SAP S/4HANA Public Cloud are primarily focused on Key User Extensibility, especially within Incident Management and Emissions Management. While Developer Extensibility via ABAP Cloud provides a more advanced pro-code extension model, the current EHS-specific enhancement points are mostly delivered as in-app, low-code BAdIs to ensure upgrade stability and full alignment with SAP’s clean core principles.

This corresponds closely with our experience from project implementations: Most EHS extension requirements can be delivered efficiently using in-app, Key User Extensibility tools such as Custom Fields, Custom Logic, UI Adaptation, and CDS View extensions without requiring developer access.

3. Practical Extensibility Scenarios in EHS

In chapter 2, we explored the extensibility options available in SAP S/4HANA Public Cloud and outlined which of these options are most relevant for EHS implementations. As highlighted, the majority of extensibility points currently exposed in the EHS area (especially within Incident Management and Emissions Management) are implemented using Key User Extensibility, including custom fields, UI adaptation, form template configuration, and Custom Logic BAdIs.

Because of this, this chapter focuses exclusively on Key User Extensibility in practice, demonstrating how customers can solve real-world EHS requirements entirely within the Public Cloud without requiring developer extensibility or SAP BTP side-by-side extensions.

Drawing from our project experience, we selected three scenarios that reflect common customer requirements:

Adding custom attributes to the Incident Management process
Generating a country-specific incident report, using custom form templates and multiple BAdIs
Adding custom attributes & making them mandatory in the “My Data Collections” Fiori app of the Environment Management process

All three scenarios illustrate how far customers can go using the extensibility tools embedded in SAP S/4HANA Public Cloud, while fully adhering to the clean-core principle.

3.1 Example 1 - Introducing a Custom Attribute for Incident Records

Extensibility Type:

Key User Extensibility

Tools & Apps Used:

Custom Fields App (SAP Fiori App)
UI Adaptation (SAP Fiori Settings)

3.1.1 Business Requirement

Many organizations require an additional field “Business Unit” to be captured as part of incident documentation to meet internal reporting needs, support organizational analysis, or fulfill local compliance requirements. Since this information is not available in the standard SAP EHS Public Cloud data model, customers often need to introduce it as a custom field.

Typically, the Business Unit may be required in multiple stages of the Incident Management process, such as:

Incident Creation
Incident Processing
Reporting and Analytics Dashboards

In our case, the Business Unit field was only added to the Incident Processing step, primarily for simplicity and to demonstrate the extensibility approach in clear and focused manner. However, this field can be added to additional UIs and process steps as needed, depending on the customer’s specific requirements, organizational structure, or compliance obligations.

3.1.2 Step-by-Step Implementation

Create New Custom Field

In this step a custom field for the Incident Management will be created using the “Custom Fields” Fiori App. You can follow the steps below to create a custom field:

1. Navigate to the “Custom Fields” app from the Fiori Launchpad.

2. Click “Create”.

3. Enter the following details:

Business Context: Select the relevant context (e.g. EHHSS_INC_BINFA).
Label: Provide a meaningful name (Business Unit). Identifier & Tooltip will be filled automatically.
Type: Choose from options like Text, Number, Date, etc.
Length: Define the size of the field if applicable.

Create New Field

After the required details have been filled, select Create and Edit.

4. Enable the fields for the relevant applications.

The fields of the tabs User Interfaces, Analytics and APIs will be enabled by default. These tabs are required to support user interactions, reporting as well as integrations for the recently added custom field (Business Unit).

Field Enablement

If the new field should appear in generated documents such as PDFs or reports, you need to enable the required Form Templates. In our scenario, two Form Templates were activated as shown below.

Enabled Form Templates

Note: The YY1_WHS_FORM10 Template is a custom Form Template. The creation of this Form Template will be shown in chapter 3.2.

5. Save and publish the custom field to make it available in the system.

Assign custom field to Fiori app

Custom fields created by using the “Custom Fields” Fiori app can be assigned to the relevant Fiori applications based on the selected business context. Follow these steps to add the field:

1. Open the “Manage Incident” Fiori app & click on any incident.

2. Click on your profile & choose “Adapt UI”

Navigate to "Adapt UI"

3. Once Adapt UI is activated, you can start customizing the page layout and add the recently created custom field to the relevant sections. By selecting “Customize” > “Show Customizable Areas” as shown below, you will be able to insert the new custom field “Business Unit” into the desired section of the Fiori App.

Navigate to "Show Customizable Areas"

4. Select the Customizable Area that should be changed.

Select Customizable Area

5. Select the element as shown below & click on “Customize UIBB”.

Select "Customize UIBB"

6. To add the new field, select “Element” > “Add Element”.

Add Element

7. Select the recently created field YY1_BUSINESSUNIT_IBN and select “OK”.

Select field YY1_BUSINESSUNIT_IBN

In the below shown illustration you can see an example, after the Business Unit was added to the UI.

Field Business Unit added to UI

8. Save the UI adaptation for this page.

3.2 Example 2 - Generating a Country-Specific Incident Report

Extensibility Type:

Key User Extensibility

Tools & Apps Used:

Adobe Lifecycle Designer (External Tool)
Maintain Form Template App (SAP Fiori App)
Custom Logic App (SAP Fiori App)
CBC Configuration (SAP Public Cloud) / or if no access exists Implementation Activities (SAP Fiori App)

3.2.1 Business Requirement

In many EHS implementations, customers need to generate country-specific incident reports that comply with national legal requirements. These reports often require a combination of standard fields, people related information, and custom fields that are not provided in the SAP EHS Public Cloud standard forms. For example, organizations operating in Australia may be required to submit the WHS Form 10, a mandatory workplace health and safety report documenting incidents, injuries, or hazards in accordance with the Australian Work Health and Safety (WHS) Regulations (made-up). To support this requirement, a custom Adobe form template must be created and populated with incident data, including custom fields. This requires implementing the relevant Business Add-Ins (BAdIs) to retrieve, map, and supply the correct incident information into the custom form.

The report must include:

Basic incident details
Person and involvement information
Custom fields required for the local legislative format

3.2.2 Step-by-Step Implementation

Develop a Custom Form in Adobe Lifecycle Designer

A custom form template needs to be created to meet the specific requirements of the report. The form should include all necessary fields. To showcase this example, we created the form template YY1_WHS_FORM10 in Adobe Lifecycle Designer and saved it as an xdp file.

Form Template Creation in Adobe Lifecycle Designer

Upload Custom Form in SAP S/4HANA Public Cloud

Once the custom form template is created in Adobe Lifecycle Designer, the next step is to upload it to SAP S/4HANA Public Cloud by using the “Maintain Form Template” app.

1. Open the “Maintain Form Template” app in your SAP S/4HANA Public Cloud system.

2. Navigate to the “Custom Template” tab.

3. Click “New” to create a new entry.

4. Enter a Form Template Name of your choice (for example “YY1_WHS_FORM10” including the prefix “YY1_” for custom forms).

5. Upload the form file that you created in Adobe Lifecycle Designer.

6. Select the Data Source Name as “EHSS_FDP_INCIDENT_SRV”.

The illustration below shows how the form setup was done in our scenario.

Form Setup (1)

Form Setup (2)

Assign Custom Fields & Custom Logic to the form

In this step we assign the created custom fields & logic to the form (shown in the previous step). This is achieved by using the “Custom Logic” app in SAP S/4HANA Public Cloud, where you can leverage the available Business Add-Ins (BAdIs) provided by the system. To retrieve the required information in the form, you can implement the following BAdIs:

BADI_EHHSS_INC_BASIC_INFO
BADI_EHHSS_INC_INVOLVED_PERS
BADI_EHHSS_INC_ROOT

1. Click “Create” to start a new implementation.

2. Select one of the mentioned BAdIs above and proceed to “Step 2” (if no filters are needed jump over to step 3 and enter an Implementation Description).

3. Create and publish the Implementation.

4. Navigate to the created Implementation.

Created Implementations

5. Select “Code Editor” and write ABAP logic using released APIs and CDS views.

Open Code Editor

The below shown BAdI implementation YY1_BADI_EHHSS_INC_BASIC_INFO retrieves incident basic information from the CDS View I_IncidentBasicInfo and populates the INCIDENTBASICINFO structure, so that key fields such as the Creation Date Time or Business Unit (which was previously created as a custom field in chapter 3.1) are available in the custom form.

YY1_BADI_EHHSS_INC_BASIC_INFO

Perform the same steps for the other required BadIs.

BAdI YY1_BADI_EHHSS_INC_INVOLVED_PE retrieves involved person details, such as Person’s Full Name, from the CDS View I_IncidentInvolvedPerson which makes it available in the custom form.

YY1_BADI_EHHSS_INC_INVOLVED_PE

BAdI YY1_BADI_EHHSS_INC_ROOT retrieves root-level incident data such as CreationDateTime from the CDS View I_Incident and makes these fields available for the custom form.

YY1_BADI_EHHSS_INC_ROOT

Note: BAdIs are essential because they supply data for custom and standard fields in the form. Without these implementations, the fields would remain empty, as the standard logic does not retrieve the required CDS view information.

6. Click “Publish” to implement.

Functional Configuration (Assign Form to regulation)

Uploading the Adobe form just makes the template available in the system. To actually use it in the EHS process, you need to specify the form and assign it to the correct form group and regulation. This ensures the form is linked to the appropriate compliance context and can be selected when generating reports.

This can be achieved by performing the mentioned steps below performed in the SAP Central Business Configuration (or ”Implementation Activities” app).

1. Specify form: Select one of the mentioned apps above and navigate to SAP Business Configuration > Compliance and Trade > Environment, Health, and Safety > Specify Forms

Each form entry shows key technical attributes:

Form Name & Form Title : Represents the form to be specified (In our scenario: WHS).
Form Type: Indicates the technology used for the form. In SAP S/4HANA Public Cloud, this is typically “SAP Interactive Form”, which refers to Adobe-based forms used for output and reporting.
Form Controller: Controls the rendering and behavior of the form in SAP (In our scenario: CL_EHFND_FW_ADS_OM_FORM_CTRL).
Data Provider: Supplies the data from the EHS process to the form (In our scenario: CL_EHHSS_AIF_INCIDENT_DPROV).
Form Object Name: Identifies the form template used for output. This should match the custom form you uploaded earlier in the “Maintain Form Template” app (In our scenario: YY1_WHS_FORM10).

Specify Form

2. Assign Form to the Form Group: Select one of the mentioned apps above and navigate to SAP Business Configuration > Compliance and Trade > Environment, Health, and Safety > Specify Form Groups and Assign Forms

Assign Form to Form Group (1)

After defining the form groups, the next step is to assign the relevant specified forms to these groups. This can be performed on the second level of the selected form group and ensures that the custom or standard forms are correctly linked to the appropriate reporting or regulatory context.

Assign Form to Form Group (2)

3. Specify Regulations & assign Regulation to Incidents: Select one of the mentioned apps above and navigate to SAP Business Configuration > Compliance and Trade > Environment, Health, and Safety > Specify Regulations.

Specify Regulations & Assign Regulation to Incidents (1)

After specifying the regulation (e.g., WHS), the next step is to assign it to the relevant incident categories. This ensures that when users select a regulation in the Incident process, the correct forms from the assigned form group become available for reporting.

Specify Regulations & Assign Regulation to Incidents (2)

4. Assign the Forms to Regulations: Finally, link the forms to the corresponding regulation. This step ensures that when a regulation (e.g., WHS) is selected in the Incident process, the correct form becomes available for reporting.

Therefore, open the SAP Central Business Configuration > Compliance and Trade > Environment, Health, and Safety > Assign Forms to Regulations.

Assign Forms to Regulations

Generating the Report

Once the configuration is complete, you can generate the report directly from the “Manage Incident” app.

1. Open the “Manage Incident” app

2. Select any Incident which has the status “In Process”.

3. Click on “Regulations”, choose “WHS”, then click “OK” and” Save”.

Generate Report (1)

After selecting the WHS regulation, the system makes the corresponding report option available under the “Reports” tab.

4. Navigate to the “Reports” tab.

5. Select the WHS Report from the list.

6. Click “Generate” to create the report.

Generate Report (2)

Once you click “Generate” for the selected Report Type, the WHS report is created and appears in the list as a downloadable PDF.

Generate Report (3)

The final output reflects all required incident details, including custom and standard fields, in the WHS Form 10 format.

Output

3.3 Example 3 - Introducing a Custom Attribute & Making it Mandatory for the “My Data Collection” App in Environment Management

Extensibility Type:

Key User Extensibility

Tools & Apps Used:

Custom Fields App (SAP Fiori App)
UI Adaptation (SAP Fiori Settings)
Custom Logic App (SAP Fiori App)

3.3.1 Business Requirement

In several Environment Management scenarios, organizations require additional quantitative attributes for internal reporting, monitoring, and compliance purposes. One common requirement is the ability to capture MTD (Month-to-Date / Total Month-to-Date) values as part of environmental data collection.

In the standard SAP EHS Public Cloud data model, this information is not available out of the box for the “My Data Collection” application. As a result, customers often need to extend the data model by introducing custom fields and ensure that these fields are consistently maintained by end users.

In our case, the MTD value was required as a mandatory field during data entry to ensure data completeness and to avoid follow-up corrections during reporting cycles. To achieve this, we implemented the requirement using Key User Extensibility, combining custom fields, UI adaptation, and custom logic.

3.3.2 Step-by-Step Implementation

Create a Custom Field

The first step is to create a custom field using the “Custom Fields” Fiori app.

1. Navigate to the “Custom Fields” app from the Fiori Launchpad.

2. Click “Create”.

3. Enter the following details:

Business Context: Select the relevant context (e.g. EHFND_AMOUNTS).
Label: Provide a meaningful name (MTD). Identifier & Tooltip will be filled automatically.
Type: Choose from options like Text, Number, Date, etc.
Length: Define the size of the field if applicable.

After the required details have been filled, select Create and Edit.

4. Enable the fields for the relevant applications.

The fields of the tabs General Information & User Interfaces will be enabled by default. These tabs are required to support user interactions for the recently added custom field. In “UI Texts” under “General Information” create a field component which needs to be added in the Fiori App as shown below.

5. Save and publish the custom field to make it available in the system.

Assign the Custom Field to the “My Data Collections” App

Custom fields which are created by using the “Custom Fields” Fiori app can be assigned to the relevant Fiori applications based on the selected business context. Follow these steps to add the field:

1. Open the “My Data Collection” Fiori app & click on any incident.

2. Click on your profile & choose “Adapt UI”.

3. Once Adapt UI is activated, you can start customizing the page layout and add the recently created custom field to the relevant sections. To add the custom field to the section, right click and choose “Add: field”.

4. Select the fields which you want to add in that Fiori App & click OK.

5. Click the save button to save the changes.

6. The fields have now been added to the Fiori app.

Implement a BAdI to make the Custom Field Mandatory

In this step we will make the custom fields, which were created & assigned to the Fiori app, mandatory. This is achieved by using the “Custom Logic” app in SAP S/4HANA Public Cloud, where you can leverage the available Business Add-Ins (BAdIs) provided by the system.

BADI_EHENV_MYDATA_AMT_FLD_CTRL

1. Click “Create” to start a new implementation.

2. Select the BAdI mentioned above and proceed to “Step 2” (if no filters are needed jump over to step 3 and enter an Implementation Description).

3. Create and publish the Implementation.

4. Navigate to the created Implementation.

5. Select “Code Editor” and write ABAP logic using released APIs and CDS views.

6. Click Sample Code & make necessary changes as show below to make the custom field mandatory.

7. Click Publish to implement the changes.

8. The fields are now mandatory in the “My Data Collection” Fiori app.

4. Summary & Lessons Learned

Extensibility plays a critical role in SAP S/4HANA Public Cloud implementations for Environment, Health, and Safety (EHS). As demonstrated throughout this blog post, even highly regulated processes such as incident reporting or country-specific compliance documentation can be effectively supported using SAP’s clean-core extensibility framework.

Drawing from our project experience and the three practical use cases presented, this chapter summarizes the key takeaways and highlights the most important lessons learned when implementing extensibility in EHS Public Cloud.

4.1 Key Takeaways

Clean-Core Extensibility Is Not a Limitation – It is a Design Principle

The SAP Public Cloud model enforces strict boundaries around what can be extended. Rather than restricting customers, these boundaries ensure:

Long-term upgrade protection
Predictable lifecycle behavior
Lower maintenance effort
Full SAP supportability

All enhancements must therefore rely on SAP-released extension points.

Most EHS Requirements Can Be Solved with Key User Extensibility

A major insight from our implementations is that the majority of EHS use cases do not require developer extensibility or side-by-side applications.

Key User tools already cover:

Custom data fields
UI adaptations
PDF report adjustments
BAdI logic

Both examples in this blog were fully implemented using Key User Extensibility only.

BAdIs Are the Backbone of EHS Extensibility

SAP delivers a growing catalogue of EHS specific BAdIs in the Public Cloud, particularly for:

Incident Management
Emissions Management

Key lessons:

Each BAdI is designed for a very specific business context.
You often need to use several BAdIs together to populate a report for a form.
They enable retrieving structured data via released CDS Views and APIs.
Clean and modular implementations significantly improve maintainability.

Custom Forms Require a Structured Approach

Regulatory reports require a combination of:

A form template (Adobe)
Custom fields
BAdI logic
CBC configuration

The lesson: Form extensibility is not only a technical activity – it is a cross-functional exercise involving business, logic, and configuration layers.

Configuration in SAP Central Business Configuration (CBC) / Implementation Activities is Essential

EHS reporting relies heavily on CBC / Implementation Activities, especially when assigning:

Forms > form groups
Form groups > regulations
Regulations > incident categories

A common project challenge: Without correct CBC (or Implementation Activities) configuration, even perfectly implemented forms and BAdIs will not appear in the UI.

End-to-End Testing Is Crucial

Because EHS extensions span UI, logic, reporting and configuration layers, testing must always validate the entire lifecycle:

Incident creation > processing > regulation selection > report generation

This avoids fragmented testing and ensures that all extension layers work together seamlessly.

4.2 Lessons Learned

Start With the Simplest Possible Extension Option

Always begin with Key User tools before considering Developer Extensibility or SAP BTP. Public Cloud projects succeed when complexity is added only where absolutely necessary.

Choose BAdIs Wisely – Don’t Over-Engineer

Each BAdI serves a narrow purpose. Trying to force a single BAdI to solve multiple needs often causes issues later. Modular, purpose-aligned implementations are easier to maintain and debug.

Document Custom Logic and Configuration Thoroughly

Because Public Cloud enforces strict structure, even small enhancements should be:

Named consistently (YY1_*)
Documented cleanly (purpose, input, output)
Readable for team members who join the project later.

Well-documented extensions also reduce future rework during audits or regulatory updates.

Maintain a Strong Governance Around Extensibility

Typical governance measures include:

Reviewing whether a need truly requires an extension
Maintaining a central register of custom fields and BAdIs
Ensuring no duplicate fields are created
Enforcing naming conventions

This prevents uncontrolled growth of extensions over time.

Engage Business Users Early in the Design Process

EHS professionals often know exactly how regulations should be represented. Early involvement helps:

Avoid unnecessary extensions
Validate report layouts
Confirm the accuracy of populated data
Ensure usability in real operational scenarios

Plan for Future Regulatory Requirements

EHS compliance evolves frequently. When building extensions, always think ahead:

Could this field or form be reused for another regulation?
Can we structure the logic to accommodate more categories in the future?
Are we using modular BAdI implementations that can scale?

This significantly reduces technical dept.

4.3 Best Practices

To close this chapter, here is a consolidated best-practice checklist:

Use SAP-released extension points only (clean core).
Prefer Key User Extensibility for EHS whenever possible.
Keep BAdI implementations modular and business-context specific.
Use functional naming conventions for fields, forms, and BAdIs.
Perform end-to-end lifecycle testing (UI > logic > form > CBC).
Document every extension early, including purpose and data sources.
Reuse released CDS Views and APIs – never rely on unreleased objects.
Involve business users early to ensure regulatory accuracy.
Build form templates in a future-proof, scalable structure.
Maintain strong governance to avoid unnecessary or duplicate extensions.

4.4 Final Remark

Extensibility in SAP S/4HANA Public Cloud is not about pushing technical boundaries. It is about using the right tools to deliver business value while protecting system integrity. With a structured approach, as illustrated in both examples, customers can achieve regulatory compliance, process optimization, and system flexibility without compromising the clean-core principles that define the Public Cloud.

5. Engage with Us

To follow the series, make sure to subscribe to the SAP EHS Public Cloud blog tag.

We welcome your thoughts and feedback in the comments!

Acknowledgements

This blog post series is the result of close collaboration within our EHS implementation team. I would like to express my sincere appreciation to my colleagues, whose expertise, insights, and project experience significantly contributed to the depth and quality of this guide.

A special thank you goes to:

Their contributions were instrumental in shaping the content of this blog post. I am truly grateful for their collaborations and support.

How to write Table function in stranded way like SAP

2025-12-09T12:36:55.534000+01:00

How to Write CDS Table Functions the Standard SAP Way

In SAP S/4HANA, we cannot always express complex business logic using pure CDS syntax. To manage scenarios like long text processing, procedural calculations, or important joins, SAP uses CDS Table Functions implemented through AMDP.

While many developers create table functions on the fly, SAP sticks to a strict and consistent design pattern across its standard content. This approach ensures good performance, readability, upgrade safety, and transportability.

A useful way to grasp this standard is to look at how SAP builds transactional CDS views, especially those that use CDS Table Functions. By examining SAP-delivered objects like I_SalesOrderTP, we can clearly see the structure, naming conventions, annotations, and implementation method that SAP expects developers to follow.

This guide explains how SAP writes table functions, how they implement them using AMDP, and how they use them in CDS views. This will help you design your own extensions in the same way SAP does.

Start with a Standard View: I_SALESORDERTP.

SAP provides many standard CDS views in S/4HANA.
To understand how SAP writes table functions, the easiest example is the view: I_SALESORDERTP
This is a Transactional Processing View, delivered by SAP.

2. Locate the Table Function Used Inside the View.

Inside the view, you will notice SAP has used: with parameters (...).

This indicates that the view is consuming a CDS Table Function.

3. You will find the CDS Table Function that SAP has written.

4. Open the AMDP Class to See SAP’s Logic.

Once you find the Table Function name, open the AMDP class: cl_sd_S4h_stxl_utils=>get_header_text
Inside this class, SAP has written the entire logic.

When crafting Table Functions ", in the manner SAP does " consistently adhere to this structure:

Create a CDS Table Function with parameters.

Implement it via an AMDP class/method using native SQLScript.

Consume it in your final CDS view using with parameters.

Follow the exact naming, annotation, and structure shown in standard objects such as I_SalesOrderTP, I_PurchaseOrderTP, I_BillingDocumentTP, etc.

Following this pattern guarantees:

Best performance (native HANA execution)

Transportability and upgrade-safety

Consistency with thousands of standard SAP-delivered objects

Conclusion

It is a tried-and-true architectural best practice to use SAP's standard pattern for CDS Table Functions. You can align your custom developments with the same design principles used in core SAP objects like *I_SalesOrderTP*, *I_PurchaseOrderTP*, and *I_BillingDocumentTP* by defining a CDS Table Function with parameters, implementing its logic in an AMDP method using native SQLScript, and consuming it through a final CDS view.

This method guarantees that sophisticated logic runs directly on SAP HANA for maximum efficiency, stays neatly isolated from the consumption layer, and is resilient to upgrades and transports. More significantly, because it adheres to a well-known and extensively used standard, it makes your solution instantly comprehensible to other SAP developers.

SAP EHS Public Cloud: Extending Your Existing Landscape Side-by-Side - Guidebook (Part 6)

2025-12-10T10:36:35.961000+01:00

Integrating SAP EHS Public Cloud: Extending Your Existing Landscape Side-by-Side - Guidebook

Part 6: Summary & Outlook

Table of Contents:

1. Summary

In this blog series, we shared our hands-on experience from multiple SAP EHS Public Cloud projects that were implemented in a hybrid, side-by-side landscape. Across Parts 1 to 5, we covered the integration of Employees, Business Partners, Materials, Functional Locations, and Equipment, as well as practical extensibility scenarios from real customer use cases.

What became very clear throughout these projects is that SAP EHS Public Cloud works best when three things come together:

Consistent master data,
Standardized integration content,
And a disciplined clean-core extensibility strategy.

In practice, we saw that missing or inconsistent master data was the most common root cause for broken end-to-end EHS processes (far more critical than any technical limitation). Once HR data, business partners, materials and assets were properly aligned across systems, incident reporting, emissions calculations, and follow-up processes became significantly more stable and transparent.

Another key learning was that standard communication scenarios and scope items save a tremendous amount of time and risk. Whenever we were able to rely on delivered content instead of custom interfaces, implementation effort, testing effort, and long-term maintenance were reduced noticeably.

Finally, extensibility played an important role in every single project. While most requirements could be solved using in-app Key User Extensibility, it was essential to define clear governance early on to avoid country-specific deviations and long-term technical debt.

This final part summarizes the key benefits and pitfalls we repeatedly encountered and shares our outlook on how SAP EHS in the Public Cloud will continue to evolve based on what we see today in real projects.

2. Benefits & Pitfalls

Integrating SAP EHS as part of a hybrid SAP S/4HANA Public Cloud landscape delivers strong business value but it also introduces architectural and organizational challenges that need to be managed carefully. In this chapter, we summarize the most important benefits and pitfalls we encountered across different customer projects.

2.1 Benefits

Fast Access to Innovation through Public Cloud Releases & AI

One of the strongest benefits we experienced in our projects was the direct access to new EHS functionality without classical upgrade projects. Unlike on-premise systems with long release cycles, customers benefit immediately from:

Regular Public Cloud releases and micro deliveries
Fast availability of new EHS features and regulatory content
Immediate access to SAP’s latest AI-driven innovations in EHS scenarios

This had a noticeable impact on time-to-value. Instead of waiting months for technical upgrades, functional improvements became available continuously. For several customers, this was also the first time AI-supported features in the EHS context could be evaluated productively.

Data Consistency and Compliance

A unified master data landscape turned out to be one of the biggest success factors across all projects. By integrating:

Employee data from SAP SuccessFactors
Business Partners & Materials from SAP MDG
Functional Locations and Equipment from SAP S/4HANA On-Premise

We ensured that EHS processes consistently relied on harmonized and validated master data. In practice, this was essential for:

Accurate incident reporting,
Reliable emissions calculations,
Correct assignment of responsibilities and workflows,
Audit-proof regulatory documentation.

Where master data was incomplete or inconsistent, downstream EHS processes were immediately affected.

Hybrid Architecture without Disruption

The side-by-side approach allowed customers to adopt EHS innovations in the Public Cloud without shutting down their existing on-premise environments. This enabled:

Gradual modernization instead of big-bang migrations,
Reduced transformation risk,
Protection of critical operational processes.

From a project perspective, this phased approach proved to be far more controllable than technical full-system replacements.

Standardized Interfaces and Scope Items

Whenever we could rely on standard SAP communication scenarios and scope items, the implantation became significantly faster and more stable. Examples include:

SAP_COM_0001, 0008, 0009, 0395
EHS scope items such as 3FP (Incident Management), 4XD (Emissions Management), and 54A (Health & Safety Management)

These accelerators reduced custom development effort, simplified testing, and aligned customer landscapes with SAP best practices.

Scalability and Future Readiness

The event-driven and API-first architecture of the Public Cloud supported scalable growth across all projects. Typical examples were:

Near real-time updated via SAP Integration Suite and Event Mesh,
Flexible replication cycles for HR and MDG data,
Cloud-native extensibility for future EHS enhancements.

This ensured that the technical foundation remained adaptable as regulatory and sustainability requirements continued to evolve.

Extensibility for Business and Regulatory Needs

Across all customers, extensibility was required mainly for country-specific regulations, additional validations, or customer-specific reporting. In most cases, these requirements could be fulfilled using Key User (In-App) Extensibility, without breaking the clean core. This allowed customers to remain upgrade-stable while still meeting local compliance needs.

2.2 Pitfalls

Despite the strong benefits, several recurring challenges also appeared in almost every project.

System Landscape Complexity

Hybrid landscapes naturally involve multiple systems: SAP S/4HANA Public Cloud, SAP S/4HANA On-Premise, SAP MDG, SAP SuccessFactors, and SAP BTP / Integration Suite. Without clear integration ownership, defined interface responsibilities, and coordinated technical design, landscapes quickly became difficult to operate and monitor.

Dependency on Master Data Quality

EHS processes are extremely sensitive to master data issues. We repeatedly saw how missing materials, outdated organizational requirements, or incorrect functional locations immediately blocked emissions calculations, risk assessments, and incident follow-ups. High master data quality is mandatory.

Custom Development Where Standard Content Is Missing

For some integration scenarios, especially Plant Maintenance integration for Functional Location and Equipment, custom iFlows were still required. This introduced additional development effort, higher testing effort, and long-term maintenance overhead.

Monitoring Challenges

End-to-end monitoring must cover:

SAP S/4HANA Public Cloud application logs
SAP S/4HANA On-Premise applications logs
SAP Master Data Governance application logs
SAP SuccessFactors message monitoring
SAP Integration Suite / iFlow monitoring

In several projects, missing monitoring initially led to delayed error detection and avoidable compliance risks.

Value Mapping and Harmonization

Incorrect or inconsistent value mappings between systems repeatedly caused replication failures. Early harmonization of organizational units, material types, equipment categories proved to be critical.

Validation of Services and Scope Items

Missing API activations or scope item assignments (e.g., API_EQUIPMENT or API_FUNCTIONALLOCATION) frequently caused delays late in the project. Early validation of all required services became a key project success factor.

Governance and Limitations of Extensibility

Extensibility offers flexibility but without governance it quickly leads to:

Diverging country solutions,
Misaligned business logic
And long-term technical debt.

Additionally, Developer Extensibility is still limited to released APIs and BAdIs, which means that not every requirement can be solved purely with custom logic.

2.3 Summary of Benefits & Pitfalls

A successful EHS Public Cloud implementation balances the strengths of standardized integration content and clean-core extensibility with disciplined data governance and architectural planning. Organizations that manage this balance effectively can unlock the full potential of SAP EHS – enabling safe, compliant, and scalable EHS operations across the enterprise.

3. Outlook

Based on what we observe across current customer projects and SAP’s latest roadmap updates, SAP EHS in the Public Cloud is clearly evolving from a standalone compliance solution toward a central digital backbone for safety, risk, and environmental governance.

Many customers are already productive with core EHS scenarios today. At the same time, the functional scope continues to expand with each Public Cloud release. We see a strong move toward more standardized business content, broader regulatory coverage, and deeper support for environmental and sustainability-driven processes. As a result, future implementations will increasingly rely on configuration rather than custom development which significantly reduces implementation and upgrade effort.

Extensibility will nevertheless remain a key success factor. From our project experience, SAP is steadily increasing both the number and the quality of released APIs and cloud-compliant BAdIs. This allows customers to address local regulatory requirements and compliant-specific validation logic in a clean-core compatible way. Especially Key User Extensibility is becoming more powerful, enabling business-driven adjustments without technical development.

In parallel, SAP BTP is gaining further importance for advanced EHS use cases. While this blog series focused on On-Stack Extensibility, we already see growing demand for advanced analytics and dashboards, cross-system workflow automation, and IoT-based hazard detection and emissions monitoring. These scenarios clearly go beyond standard transactional processing and position SAP BTP as a natural complement to SAP EHS in complex enterprise landscapes.

Another major trend we observe is the increasing convergence of EHS and sustainability. Environmental compliance, emissions management, and sustainability reporting are becoming tightly connected. From a solution perspective, this strengthens the integration between SAP EHS, SAP Sustainability Footprint Management, and SAP Sustainability Control Tower. Customers will benefit from more consistent emissions data, integrated compliance reporting, and harmonized master data across production, procurement, and asset management.

For customers, these developments reinforce one central message from our project work: Early architectural discipline pays off. Organizations that invest early in clean-core principles, standardized integration content, high master data quality, and clear extensibility governance are best positioned to benefit from future SAP innovations.

4. Engage with Us

To follow the series, make sure to subscribe to the SAP EHS Public Cloud blog tag.

We welcome your thoughts and feedback in the comments!

Acknowledgements

Their contributions were instrumental in shaping the content of this blog post. I am truly grateful for their collaborations and support.

Cloud BAdI to Update Sales Document Business Data

2025-12-26T12:57:10.931000+01:00

Cloud BAdIs to Update Sales Document Business Data

As I explained in blog Sales Document BAdI Overview, following Cloud BAdIs can be used to modify some business data (standard fields) of sales document:

Modification of Business Data in Sales Document Headers - SD_SLS_MODIFY_HEAD_BUSINESS
Modification of Business Data in Sales Document Items - SD_SLS_MODIFY_ITEM_BUSINESS

If you are familiar with the sales document data model, you will see these Cloud BAdIs mainly cover the sales document business data which are defined in the database table VBKD.

Since the modification of business data BAdIs are kind of transactional BAdI, which are triggered multiple times during the sales document processing, the fields modification result could be checked at runtime if you are using UI to process sales documents.

Of cause not all business data fields defined in the database table VBKD are modifiable via BAdI. The changeable fields in these BAdIs are normally independent from other business processes.

BAdI Parameters

There are following typical parameters in BAdI SD_SLS_MODIFY_HEAD_BUSINESS:

Parameter Name	Description	Parameter Type	Purpose
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data (including custom fields) that customer can use to write custom logic
SALESDOCUMENTPARTNERS	Sales document header partners	Importing	Contains sales document header partner information
SALESDOCUMENT_BUSINESSDATA	Sales document business data	Changing	Contains all changeable fields on sales document header level

There are following typical parameters in BAdI SD_SLS_MODIFY_ITEM_BUSINESS:

Parameter Name	Description	Parameter Type	Purpose
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data (including custom fields) that customer can use to write custom logic
SALESDOCUMENTITEM	Sales document item	Importing	Contains sales document item data (including custom fields) that customer can use to write custom logic
SALESDOCUMENTPARTNERS	Sales document header partners	Importing	Contains sales document header partner information
SALESDOCUMENTITEMPARTNERS	Sales document item partners	Importing	Contains sales document item partner information
SALESDOCUMENTITEM_BUSINESSDATA	Sales document item business data	Changing	Contains all changeable fields on sales document item level

In the latest SAP S/4HANA Public Cloud version CE2602, following fields on sales document header level are modifiable in the BAdI SD_SLS_MODIFY_HEAD_BUSINESS:

Pricing Date
Customer Purchase Order
Customer Purchase Order Date
Incoterms Version
Incoterms
Incoterms Location 1
Incoterms Location 2

Following fields on sales document item level are modifiable in the BAdI SD_SLS_MODIFY_ITEM_BUSINESS:

Pricing Date
Customer Purchase Order
Customer Purchase Order Date
Incoterms Version
Incoterms
Incoterms Location 1
Incoterms Location 2

Business Example

Due to fluctuation of raw material, the Supply company XYZ has special agreement with buyers to set the pricing date of sales orders based on different criteria. According to the business process of company XYZ, for different sales office, the pricing date offset is defined to make sure the pricing date is calculated with realistic time period. For example, when sales orders created from certain sales office, the pricing date is calculated 7 days after the requested delivery date. But there are exceptional case for some defined customer groups, the pricing date shall be calculated differently.

Solution via Extensibility and Process Flexibility

Business Rules to Proposal Pricing Date

According to the standard feature "Flexible Proposal of Pricing Dates" (see detail in SAP_HELP), customer can define business rules to control calculation of pricing date.

Therefore, I can define a business rule like below to influence pricing date calculation.

The "Baseline Date" in the CPF decision table defines the reference date of pricing date calculation. Below are possible options of baseline date:

null: Today
A: Requested delivery date (sales document header)
B: Valid-from date (sales document header)
C: Contract start date (sales document header/item)
😧Document creation date

In SSCUI 104275, this CPF formula is assigned to routine 3000003 for flexible pricing date proposal

Then open the SSCUI 103823 to assign the routine 3000003 to sales order type "OR"

Once this CPF formula is enabled in sales order, we can test the pricing date proposal of sales orders.

Create a new sales order via VA01, both requested delivery date and pricing date are defaulted as current date (26.12.2025)

Go to sales order header to change the sales office to "100".

Once the sales office is changed to "100", the pricing date is updated immediately based on CPF business rule: 3 days after current date.

If I change the sales office to 101 again, the pricing date is updated accordingly to 7 days after.

🙀Hold on......

This blog is for Cloud BAdI, but here only the CPF is used. Do I miss any thing? 🤔

If you also have similar concern, please continue with below chapter.

How Cloud BAdI Works

As I explained earlier, the pricing date is a changeable field in modify business data BAdI. The modify business data BAdI can also be used to modify pricing date on top of CPF proposed value.

In the CPF decision table, the sales office is defined as key differentiator to control pricing date calculation. If the CPF criteria is not sufficient to fulfill the business requirement to determine the pricing date, BAdI can be used with more specific custom logic. For example, in the BAdI logic, I can make certain customers as exceptional case to propose pricing date.

Open the tile "Custom Logic" to create a BAdI implementation for Cloud BAdI SD_SLS_MODIFY_HEAD_BUSINESS.

Implement the custom logic as below to always use "requested delivery date" as "pricing date" based on certain customer group.

*   This method can be used to set values to sales document header business data fields.
*   Example:
*
*   First, copy the values from the business data fields to the output parameter using a move-corresponding statement.
*   If you use developer extensibility and multiple implementations, embed the move-corresponding statement in an if statement.
*
    if salesdocument_businessdata is initial.
      move-corresponding salesdocument to salesdocument_businessdata.
    endif.

*   Update the pricing date
    if salesdocument-salesorganization = '1010' and salesdocument-salesdocumenttype = 'TA'.
        if salesdocument-customergroup = '02'.      "special customer
            salesdocument_businessdata-pricingdate = salesdocument-requesteddeliverydate.
        endif.
    endif.

Publish the BAdI implementation.

Now, let's test the sales order creation with customer 10100001 who has the customer group "01" maintained, and another sales order with customer 10100004 who has the customer group "02" maintained.

Create a sales order via Fiori v2 application.

The pricing date is determined by business rules in CPF decision table. Because the customer group for customer 10100001 is "01", the BAdI logic is not processed to set the pricing date.

Create another sales order with customer 10100004, that the customer group "02" is defined.

Even the sales office "100" is determined from customer master data, but because the customer group is "02" which fits to the custom logic in BAdI implementation, the pricing date is determined same as requested delivery date.

In conclusion, the BAdI logic will overrule the pricing date which is proposed by CPF business rules.

Moving Forward

The sales document business data BAdIs are well defined to influence sales document standard fields during document processing. Please always check if those BAdIs can fulfill your business requirements before introducing custom fields or checking other workarounds.

We will continue investing on sales document business data modification BAdIs to enable more changeable standard fields. On the other hand, we also expect customers can raise requirement if any field is missing in those BAdIs. Please feel free to submit your requirement through the Customer Influence Portal, see detail in SAP note 2963059. Stay tuned for new features planned in our roadmap.

Cloud BAdIs to Check Sales Document and Items

2025-12-31T11:08:18.730000+01:00

Cloud BAdIs to Check Sales Document and Items

As I explained in blog Sales Document BAdI Overview, there are Cloud BAdIs to perform validation checks for entities of sales document in different processing phases.

Check of Header Data in Sales Documents - SD_SLS_CHECK_HEAD
Check of Item Data in Sales Documents - SD_SLS_CHECK_ITEM
Check of Delivery Schedule Data in Sales Scheduling Agreements - SD_SLS_CHECK_DELIVSCHED
Check of Sales Document Items Before Deletion - SD_SLS_CHECK_DELETE_ITEM
Check of Sales Documents Before Saving - SD_SLS_CHECK_BEFORE_SAVE

Sales Document Entity Check BAdIs

Following Cloud BAdIs are used to check on certain sales document entities (business context), relevant messages can be raised from the BAdI implementation logic. These BAdIs are processed in transactional manner which means these BAdIs will be triggered multiple times during sales document processing.

BAdI Name	Description	Business Context	Purpose/Usage
SD_SLS_CHECK_HEAD	Check of Header Data in Sales Documents	Sales: Sales Document	You can implement custom logic to check sales document header data and raise messages
SD_SLS_CHECK_ITEM	Check of Item Data in Sales Documents	Sales: Sales Document Item	You can implement custom logic to check sales document item and raise messages
SD_SLS_CHECK_DELIVSCHED	Check of Delivery Schedule Data in Sales Scheduling Agreements	Sales: Sales Scheduling Agreement Delivery Schedule	You can implement custom logic to check sales scheduling agreement delivery schedule and raise messages

It is important to know that messages raised in above BAdI implementation will not prevent from saving the sales documents, even for the error messages.

Following message types are supported:

I - Information message
W - Warning message
E - Error message

Parameters of BAdI SD_SLS_CHECK_HEAD

There are following parameters defined in BAdI SD_SLS_CHECK_HEAD

Parameter Name	Description	Parameter Type	Purpose
DOCUMENTPROCESSINGMODE	Sales Document Processing Mode	Importing	Contains information on whether the document is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data currently being processed
SALESDOCUMENTPARTNERS	Sales Document Partners	Importing	Contains sales document header partners currently being processed
SALESDOCUMENT_EXTENSION	Sales Document Custom Fields	Importing	Contains the values of extension fields for the sales document header
MESSAGES	Messages	Changing	Customer can pass any message texts (free text) with allowed message types into this parameter

Parameters of BAdI SD_SLS_CHECK_ITEM

There are following parameters defined in BAdI SD_SLS_CHECK_ITEM

Parameter Name	Description	Parameter Type	Purpose
DOCUMENTPROCESSINGMODE	Sales Document Processing Mode	Importing	Contains information on whether the document is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
DOCUMENTITEMPROCESSINGMODE	Sales Document Item Processing Mode	Importing	Contains information on whether the document item is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data currently being processed
SALESDOCUMENTITEM	Sales document item	Importing	Contains sales document item data currently being processed
SALESDOCUMENTSCHEDULELINES	Sales Document Schedule Lines	Importing	Contains information about sales document schedule lines
SALESDOCUMENTPARTNERS	Sales Document Partners	Importing	Contains sales document header partners currently being processed
SALESDOCUMENTITEMPARTNERS	Sales Document Item Partners	Importing	Contains sales document item partners currently being processed
SALESDOCUMENT_EXTENSION	Sales Document Custom Fields	Importing	Contains the values of extension fields for the sales document header
SALESDOCUMENTITEM_EXTENSION	Sales Document Item Custom Field	Importing	Contains the values of extension fields for the sales document item
MESSAGES	Messages	Changing	Customer can pass any message texts (free text) with allowed message types into this parameter

Parameters of BAdI SD_SLS_CHECK_DELIVSCHED

There are following parameters defined in BAdI SD_SLS_CHECK_DELIVSCHED

Parameter Name	Description	Parameter Type	Purpose
DOCUMENTPROCESSINGMODE	Sales Document Processing Mode	Importing	Contains information on whether the document is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
DOCUMENTITEMPROCESSINGMODE	Sales Document Item Processing Mode	Importing	Contains information on whether the document item is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data currently being processed
SALESDOCUMENTITEM	Sales document item	Importing	Contains sales document item data currently being processed
DELIVERYSCHEDULE	Sales Scheduling Agreement Delivery Schedule	Importing	Contains information about the sales scheduling agreement delivery schedules currently being processed
SALESDOCUMENT_EXTENSION	Sales Document Custom Fields	Importing	Contains the values of extension fields for the sales document header
SALESDOCUMENTITEM_EXTENSION	Sales Document Item Custom Field	Importing	Contains the values of extension fields for the sales document item
DELIVERYSCHEDULE _EXTENSION	Sales Scheduling Agreement Delivery Schedule Custom Fields	Importing	Contains the values of extension fields for the sales scheduling agreement delivery schedules
MESSAGES	Messages	Changing	Customer can pass any message texts (free text) with allowed message types into this parameter

Check BAdI for Sales Document Item Deletion

This BAdI is defined to allow customers implement custom logic to control whether deletion of sales document item is possible or not. This BAdI is called as soon as the sales document item deletion occurs. The check results can be communicated via messages to be added to a message table.

There are following parameters defined in BAdI SD_SLS_CHECK_DELETE_ITEM

Parameter Name	Description	Parameter Type	Purpose
DOCUMENTPROCESSINGMODE	Sales Document Processing Mode	Importing	Contains information on whether the document is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
DOCUMENTITEMPROCESSINGMODE	Sales Document Item Processing Mode	Importing	Contains information on whether the document item is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data currently being processed
SALESDOCUMENTITEM	Sales document item	Importing	Contains sales document item data currently being processed
SALESDOCUMENTPARTNERS	Sales Document Partners	Importing	Contains sales document header partners currently being processed
SALESDOCUMENTITEMPARTNERS	Sales Document Item Partners	Importing	Contains sales document item partners currently being processed
SALESDOCUMENT_EXTENSION	Sales Document Custom Fields	Importing	Contains the values of extension fields for the sales document header
SALESDOCUMENTITEM_EXTENSION	Sales Document Item Custom Field	Importing	Contains the values of extension fields for the sales document item
OPERATIONCONTEXT	Sales document operation context	Importing	Contains information about the context of the current operation
NO_DELETION	No Deletion	Changing	an be filled with value X to disallow deletion of the item
MESSAGES	Messages	Changing	Customer can pass any message texts (free text) with allowed message types into this parameter

Following message types are supported:

I - Information message
W - Warning message
E - Error message

Sales Document Check Before Save BAdI

Different from above check BAdIs, the Cloud BAdI SD_SLS_CHECK_BEFORE_SAVE is called in sales document saving phase. Customer can implement custom logic to check sales document data before save and decide to abort the document saving. The check results can be communicated via messages to be added to a message table.

There are following parameters defined in BAdI SD_SLS_CHECK_DELETE_ITEM

Parameter Name	Description	Parameter Type	Purpose
DOCUMENTPROCESSINGMODE	Sales Document Processing Mode	Importing	Contains information on whether the document is currently in one of the following processing modes: CREATE, CHANGE, or DISPLAY
SALESDOCUMENT	Sales document header	Importing	Contains sales document header data currently being processed
SALESDOCUMENTITEMS	Sales document item	Importing	Contains sales document item data currently being processed
SALESDOCUMENTSCHEDULELINES	Sales document schedule line	Importing	Contains information about sales document schedule lines
SALESDOCUMENTPARTNERS	Sales Document Partners	Importing	Contains sales document header partners currently being processed
SALESDOCUMENTITEMPARTNERS	Sales Document Item Partners	Importing	Contains sales document item partners currently being processed
SALESDOCUMENT_EXTENSION	Sales Document Custom Fields	Importing	Contains the values of extension fields for the sales document header
SALESDOCUMENTITEM_EXTENSION	Sales Document Item Custom Field	Importing	Contains the values of extension fields for the sales document item
DELIVERYSCHEDULE	Sales Scheduling Agreement Delivery Schedule	Importing	Contains information about the sales scheduling agreement delivery schedules currently being processed
DELIVERYSCHEDULE _EXTENSION	Sales Scheduling Agreement Delivery Schedule Custom Fields	Importing	Contains the values of extension fields for the sales scheduling agreement delivery schedules
ELECTRONICPAYMENTDETAILS	Electronic Payment Details	Importing	Contains information about electronic payment details of the sales document currently being processed
MESSAGES	Messages	Changing	Customer can pass any message texts (free text) with allowed message types into this parameter

Following message types are supported:

I - Information message
W - Warning message
E - Error message

Only the error message will prevent from saving the sales document.

Key Benefit of Check Before Save BAdI

There are following key features of sales document check before save BAdI:

Based on validation check result, you can stop saving the sales document
You will get more reliable sales document data in check before save BAdI because the sales document data is relatively more stable in saving phase
You have full access of sales document entities in check before save BAdI
The check before save BAdI is more performant as it is only called once during document saving

Business Example

I'd like to use a business example to explain how to utilize check BAdIs to fulfill a business requirement.

Supplier company XYZ sells products to different customers. The customer order can be placed via Portal as self-service or placed manually by the sales representative.

Due to fluctuations in the prices of raw materials, company XYZ generally does not accept customer orders with long-term delivery requests. Company XYZ would like to implement custom logic to indicate the issue of long-term delivery and stop saving the sales order if it is requested to be delivered later than 1 month from the order creation date.

Solution via Extensibility

The BAdI SD_SLS_CHECK_HEAD and BAdI SD_SLS_CHECK_BEFORE_SAVE can work together to fulfill the requirement.

Implement Custom Logic in SD_SLS_CHECK_HEAD

As explained above, the BAdI SD_SLS_CHECK_HEAD can perform custom validation check during sales document processing, and this BAdI will not impact on the sales document save.

I can implement custom logic to indicate there is an issue when customer requested delivery date is too long.

Create a BAdI implementation for Cloud BAdI SD_SLS_CHECK_HEAD.

Implement below custom logic to raise an error message when customer requested delivery date is 30 days away.

* show error message if the customer requested delivery date is later than 30 days
  if documentprocessingmode = 'CREATE' or documentprocessingmode = 'CHANGE'.
    if salesdocument-salesdocumenttype = 'TA' or salesdocument-soldtoparty = '0010100080'.
    "check is customer requested delivery date is more than 30 days from today
      if salesdocument-requesteddeliverydate - salesdocument-creationdate > 30.
        append value #( messagetype = 'E' messagetext = 'Customer Requested Date has to be within 30 days.' ) to messages.
      endif.
    endif.
  endif.

Publish the BAdI and test the sales order creation from Fiori application.

Create a sales order for customer "10100080". When I set the requested delivery date to Feb 1st 2026, I get the error message notified in the sales order UI.

But I can continue with clicking the Create button to save the sales order.

A dialog box is popped up before continuing saving the sales order.

Press save button to continue. Eventually the sales order can be saved.

Implement Custom Logic in SD_SLS_CHECK_BEFORE_SAVE

In order to reduce the risk of creating sales orders with long customer requested delivery date, we can implement custom logic in BAdI SD_SLS_CHECK_BEFORE_SAVE to prevent from saving the sales order if the customer requested delivery date is 30 days away.

Create a BAdI implementation for SD_SLS_CHECK_BEFORE_SAVE.

Implement custom logic below to check requested delivery date and raise an error message if the customer requested delivery date is 30 days away from order creation date.

* Check if the customer requested delivery date is 30 days later from the order creation date
* The sales order shall not be saved if the customer requested delivery date is later than 30 days
  if documentprocessingmode = 'CREATE' or documentprocessingmode = 'CHANGE'.
    if salesdocument-salesdocumenttype = 'TA'.
      "get sold-to party
      read table salesdocumentpartners into data(ls_partner) with key partnerfunction = 'AG'.
      if ls_partner-customer = '0010100080'.
        "check is customer requested delivery date is more than 30 days from today
        if salesdocument-requesteddeliverydate - salesdocument-creationdate > 30.
          append value #( messagetype = 'E' messagetext = 'Customer Requested Date has to be within 30 days.' ) to messages.
        endif.
      endif.
    endif.
  endif.

Publish the BAdI implementation and test sales order behavior in Fiori UI.

Create a sales order with customer "10100080" and set the customer requested delivery date to Feb 1st 2026.

The error message is raised from the implementation of BAdI SD_SLS_CHECK_HEAD.

Click button "Save" to try to save the sales order.

The error message is raised and sales order save is failed. It is because the error message raised in BAdI SD_SLS_CHECK_BEFORE_SAVE prevent the document save.

Moving Forward

Now, I believe I have better understanding of different Cloud BAdIs to perform validation checks against sales document.

You can use transactional BAdIs to perform validation check at runtime, especially when you use sales document UI to create/update sales documents. The BAdI SD_SLS_CHECK_HEAD and SD_SLS_CHECK_ITEM are processed whenever the relevant entities are in processing.

The BAdI SD_SLS_CHECK_BEFORE_SAVE is triggered only once before save. You can access to all entities of sales document to perform validation check with more reliable value. It is possible to stop saving if the validation check is failed in custom logic.

In the future, according to customer requirements, the check BAdIs would be enhanced to support more import parameters and entities. Please feel free to submit your requirement through the Customer Influence Portal, see detail in SAP note 2963059. Stay tuned for new features planned in our roadmap.

Custom Form with Custom Data Source in SAP Public Cloud (Grow with SAP)

2026-01-15T14:42:13.195000+01:00

INTRODUCTION

In SAP S/4HANA Cloud Public Edition, there are scenarios where standard output forms and data sources do not fully meet business requirements.

This blog post explains how to create a custom output form using a custom data source in SAP S/4HANA Cloud (Grow with SAP).

Motivation Behind Writing This Blog Post

There have been significant changes in the approach to Form Development, especially in SAP S/4HANA Public Cloud systems. Gone are the days where the form were developed using SFP transactions and driver program is developed to call the form using Function Module. In the SAP Public Cloud, Form development follows a fundamentally different, cloud-compliant model aligned with clean-core principles

As a result of this shift, most available blog posts and tutorial videos focus on building or customizing forms using standard SAP-delivered data sources. However, there is limited information on how to create custom forms based on custom data sources within these new constraints. This blog post aims to close that gap by providing detailed implementation steps for building a custom form using a custom data source in SAP S/4HANA Public Cloud.

What is not about?

The form is developed directly in the S/4HANA Cloud tenant. Please note that this blog post does not cover “SAP Forms service by Adobe” on SAP Business Technology Platform. Instead, it focuses on form development within the public cloud system itself (Developer Extensibility)

When Should You Follow This Approach?

You should consider creating a custom form with a custom data source in the following scenarios:

SAP has not provided a standard data source for the required business object.
Examples include:
- Purchase Requisition Output
- Supplier Invoice Output
You have developed a custom application or custom business object, and an output form is required.
Since the development is custom, there will naturally be no standard form or data source available for output generation

In such cases, defining a custom data source and binding it to a custom form becomes the correct and often the only viable approach.

When Should You Not Follow This Approach?

You should avoid this approach when a standard solution already exists:

If SAP provides a standard data source and a standard form template, you should use them instead of creating custom ones,
Example: Purchase Order outputs already have standard data sources and form templates available.
When standard data sources are available, always prefer the “Form Template” Fiori app to customize the output.
Customization of Content Form Templates - SAP S/4HANA Finance

Prerequisites

Tools

Adobe LiveCycle Designer
Required for designing and modifying Adobe-based output forms. The tool is used to define the layout, structure, and binding of the form fields to the data source.
ABAP Development Toolkit (ADT)
Required for designing and modifying Adobe-based output forms. The tool is used to define the layout, structure, and binding of the form fields to the data source.

Skills

Knowledge on Adobe Form
Knowledge on RAP Development Framework

Code References

All example code referenced in this article is available in the Git repository linked below. To keep the blog post concise and focused, the source code is not reproduced here in full, as including it would unnecessarily lengthen the post.
GitHub - gourabdey-sap/form-development-in-s4hc: Custom Form Development with Custom Data Source in S4HC

TECHNICAL IMPLEMENTATION

As an example for custom form development using a custom data source, we will use the Purchase Requisition (PR) form. This example is chosen because the Purchase Requisition process is well known and familiar to most readers, making it easier to understand and relate to the concepts discussed.

Step 1 - Custom CDS View Creation

We will create a RAP BO for Purchase Requisition form output requirement. I usually prefer defining a Root CDS view to keep the design future-proof. This approach allows for easy functional enhancements later without requiring changes to the existing CDS hierarchy.

That said, if your objective is only to call the form, a standard CDS view is sufficient. In such cases, creating a Root CDS view (RAP Business Object) is not mandatory.

We will create two interface CDS views and two corresponding consumption CDS views:

One set for header data
One set for item data

The source code for the CDS can be found in GitHub Repo .

Step 2 - Marking the Header Consumption CDS as Form Data Provider

Add the following annotation to the header consumption CDS view. This annotation is required only for the header consumption view and must not be added to the item CDS view

@ObjectModel.supportedCapabilities: [ #OUTPUT_FORM_DATA_PROVIDER  ]

Step 3 - Creating Form Data Provider (Data Source)

Next, we need to create a Service Definition to act as the form data provider (data source). Both the header and item entities must be exposed in this service definition.

An important point to note is the leading entity annotation, defined using @ObjectModel.leadingEntity.name

@EndUserText.label: 'PR Form Data Provider'
@ObjectModel.leadingEntity.name: 'ZMM_C_PRHEADER'
define service ZMM_PR_FORM_DATA {
  expose ZMM_C_PrHeader as Header;
  expose ZMM_C_PrItem   as Item;
}

Key Point Consideration:

Only one CDS entity must be designated as the Form Data Provider. In this scenario, the header CDS view (ZMM_C_PrHeader) is the sole data provider and is annotated with @ObjectModel.supportedCapabilities: [ #OUTPUT_FORM_DATA_PROVIDER].
The item CDS view must not contain this annotation.
The Service Definition should have the leading entity defined in upper case. The Data Definition name of the header view is ZMM_C_PrHeader still, the leading entity has to be provided as ZMM_C_PRHEADER.

@ObjectModel.leadingEntity.name: 'ZMM_C_PRHEADER'

Service Binding creation is not required for rendering the form. Only Service Definition is enough,
But, still in this blog post Service Binding will be required for generation of RAP Application.

Step 4 - Form Creation

Create new Form using Path: Right Click on Package > New > Other ABAP Repository Object > Form. Provide the form name as required. I have given as ZMM_PR_OUTPUT.

Data Provider:

Select the data provider as the Service Definition been created in Step 3. In this example, this will be ZMM_PR_FORM_DATA.

Save the form (Ctrl/Cmd + S).

Please note: The form cannot be activated yet as the layout is still not developed.

Step 5 - Download XML Schema (XSD File)

To download the XSD file of form, click on "Download Schema" button.

Click on export and give the file name. I have given the file name as "PR Schema.xsd".

Step 6 - Create Form Layout

Open Adobe LiveCycle Designer (ALD) locally in the system. You can search for the application "Adobe LiveCycle Designer" in your system and should be able to open it, provided this is installed locally in your system.

Once the Adobe LiveCycle Designer is open, click on New Form. Or alternatively you can use the menu File > New Form (Ctrl/Cmd + N)

Select the orientation as required and click on Finish.

Use the menu File > New Data Connection to link to the XSD file.

Select the XSD file downloaded from Step 5. Click on finish.

The field details can be seen the Data View tab. If you don't have data view tab, then you can add it from the menu Windows > Data View

Rename the Page and bind it to the header Node.

Then save the form as XDP file (Ctrl/Cmd + S).

Step 7 - Designing the Form

As both form is created and the connection is established with XSD file, we can work on the layout development as required.

As an example, I will have a very basic layout where some of the fields from header will be bound and we will have a table which will have item details.

You would need the data in XML format. We will download it subsequent section. We will also see how to preview the form locally in the system.

Step 8 - Generate Sample Data

Right click on Preview PDF tab > Select Preview Tab

Click on Generate Preview Data > Click on the button below Data File Name

Provide the name of the file and Click Save.

Then click on Generate Button, which will generate some sample data. Click on Ok.

With this we have some example data been generated and we can Preview the form locally.

Step 9 - Preview the Form

Click on the Preview Tab to have a look at the form layout been developed.

This is how the form layout appears locally during preview. Some fields are displayed in light blue in the local preview; however, when the form is executed within S/4HANA Cloud (S/4HC), this blue coloring will not be visible.

The sample forms, example data and XSD scheme can be found in GitHub Repo

Step 10 - Upload the Form in S4

Open the form been created in Step 4 and upload the developed form using Upload Layout.

Now you should be able to activate the form.

So, we have successfully created the form and uploaded in S4HC.

Step 11 - Adding Attachment Related field in Header Consumption View

For showing the attachment using CDS, we would need below 3 fields

File Name - Name of the file
Mime Type - For PDF, this will be always
Attachment - The PR Output PDF

So, we will achieve this by using virtual element of CDS.

Important Annotation:

Virtual Field

@ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_MM_PR_FORM'

Attachment Field

@Semantics.largeObject:{
  mimeType: 'MimeType',
  fileName: 'FileName',
  contentDispositionPreference: #ATTACHMENT
}

Mime Type

@Semantics.mimeType: true

CDS Source Code

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Purchase Requisition Header'
@ObjectModel.supportedCapabilities: [ #OUTPUT_FORM_DATA_PROVIDER ]
@Metadata.allowExtensions: true
define root view entity ZMM_C_PrHeader
  provider contract transactional_query
  as projection on ZMM_I_PrHeader
{
  key     PurchaseRequisition,
          PurReqnDescription,
          PurchaseRequisitionType,
          LastChangeDateTime,
          @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_MM_PR_FORM'
  virtual FileName   : abap.char( 50 ),
          @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_MM_PR_FORM'
          @Semantics.mimeType: true
  virtual MimeType   : abap.char( 50 ),
          @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_MM_PR_FORM'
          @Semantics.largeObject:{
            mimeType: 'MimeType',
            fileName: 'FileName',
            contentDispositionPreference: #ATTACHMENT
          }
  virtual Attachment : abap.rawstring( 0 ),
          /* Associations */
          _Item : redirected to composition child ZMM_C_PrItem
}

Step 12 - Logic for Virtual Elements

The calculation class for virtual element should implement the interface if_sadl_exit_calc_element_read.

The interface has 2 methods.

get_calculation_info :
- The fields which are used in the logic required to be added to the field et_requested_orig_elements.
- For our case, only Purchase Requisition number is enough.
calculate:
- The actual logic for virtual fields will go here.
- The required fields have to be populated in internal table ct_calculated_data.

Complete code for the class is available here.

Step 13 - Calling the Adobe Form

Rending the Form (line no 23-31)

The form is rendered using the method cl_fp_ads_util=>render_pdf.
This requires the data and the layout.

Reading data in XML format (line 9-14)

The XML data are being read using the object of CL_FP_FDP_SERVICES.
It requires the key of the Root/Header CDS, which is defined as lead entity in the Service Definition in Step 3. In our case, only Purchase Requisition is the key. If multiple keys are there, value should be passed for all keys.
The Purchase requisition data is fetched in the line 13 in the variable LV_DATA in XSTRING format.

Reading data in Form Layout (line no 19)

We would also need the form layout (Adobe Form which was designed and uploaded in Step 10) to render the form.
The form layout is fetched and assigned to LV_XML in XSTRING format.

Getting reference to Form API

Passing the Service Definition created in Step 3 to get the reference.
This API will be used to get the data from the Form Data Provider in XML format.
The parameter iv_max_depth represents navigation level. In this example, we have Header and Item so, 1 level depth should be fine

  METHOD get_pdf.

    mc_duplicate_call = abap_true.

    DATA(lo_fdp_api) = cl_fp_fdp_services=>get_instance(
      iv_max_depth          = 1
      iv_service_definition = `ZMM_PR_FORM_DATA` ).

    DATA(lt_keys)    = lo_fdp_api->get_keys( ).

    lt_keys[ name = 'PURCHASEREQUISITION' ]-value = im_v_pr.

    DATA(lv_data) = lo_fdp_api->read_to_xml_v2(
      it_select = lt_keys
    ).

    DATA(lv_string) = cl_abap_conv_codepage=>create_in( )->convert( lv_data ).

    DATA(lv_xml) = lo_fdp_api->get_xsd_v2( ).

    DATA(lv_string2) = cl_abap_conv_codepage=>create_in( )->convert( lv_xml ).

    DATA(lo_reader) = cl_fp_form_reader=>create_form_reader( `ZMM_PR_OUTPUT` ).

    DATA(ls_layout) = lo_reader->get_layout( ).

    cl_fp_ads_util=>render_pdf( EXPORTING iv_xml_data   = lv_data
                                          iv_xdp_layout = ls_layout
                                          iv_locale     = 'en_US'
                                IMPORTING ev_pdf        = rt_v_pdf
                                         ).

    mc_duplicate_call = abap_false.

  ENDMETHOD.

Step 14 - Service Binding

Create a Service Binding for the RAP application. This should be OData v4, as attachment does not work in OData V2 using CDS Annotation.

Preview the Application.:

Step 15 - Download the Form

Click the link in the Attachment column of any row to download the PDF. Mission accomplished! 🚀

CONCLUSION

Below is the recap of the activities done so far

Created the necessary CDS views to fetch the required data, covering both header and item information.
Designated the header consumption CDS view as the Form Data Provider using the appropriate annotation.
Created the Adobe Form in SAP S/4HANA Cloud and exported the corresponding XSD schema.
Designed the form layout locally using Adobe LiveCycle Designer, with the XSD schema used for data binding.
Generated sample XML data locally and used it to preview and validate the form layout.
Uploaded the completed form layout back into S/4HANA Cloud and successfully activated the form.
Created the virtual elements in the consumption view for attachments. Logic has been added fill the Filename, Mime Type and PDF.
Service Binding has been created for the for the RAP application (OData V4) and able to download the PDF which is a custom form with custom data source.

One More Thing… 🧠 (For the Curious Minds)

If you’ve made it this far, here’s a small challenge for fellow SAP explorers: SAP standard output transactions allow you to download the form XML using the magical command #&&DOWNLOAD_FORM_DATA_XML&&#

Now the fun part:

👉Why not bring the same superpower to your custom form?

Try adding a provision to download the XML data using the very same command—not a workaround, not a shortcut, but exactly the SAP way.
Bonus points if your implementation is so seamless that it feels like it shipped straight from Walldorf 😉

Signing Off

Shared from experience. Use it, challenge it, and improve it—let’s grow together with SAP Grow.

SAP Cloud ERP (S/4HANA Cloud Public Edition) 2602亮点前瞻 — 可拓展性 (Extensibility)

2026-01-20T02:00:00.175000+01:00

大家好，我们即将迎来 SAP S/4HANA Cloud Public Edition 2602 大版本的更新。在本篇博客中，我将会重点展示在 SAP S/4HANA Cloud Public Edition 2602 当中可拓展性部分的亮点更新内容。

API 功能的增强与变更

API可以帮助我们实现系统间的集成。在2602版本，多个API都迎来了显著的变更：

业务伙伴API (API_BUSINESS_PARTNER)：新增了“重复检查 (Duplicate Check)”操作。现在，您可以在创建新的业务伙伴之前，通过GET操作来验证具有特定参数的业务伙伴是否已存在，有效避免了主数据的重复创建。
成本率API (Cost Rate API)：ODATA V2版本的成本率API已被标记为“弃用”，并将在2702版本中正式停用。取而代之的是功能更强的ODATA V4版本。建议用户尽快迁移到新的API。
客户退货、贷项/借项凭证请求API：这是一个需要立即关注的关键变更。为了提升数据完整性，系统对客户退货 (A2X) OData V4 API等相关API加强了数据校验。现在，API将限制在创建凭证时向某些字段传递初始值（空值），以避免后端逻辑覆盖可能导致的混淆和不一致。
商业项目API：为防止数据不一致，当资源供应存在未批准的时间记录时，系统将限制通过API删除该资源供应。

关键用户扩展性增强

对于业务专家和关键用户而言，2602版本在自定义字段方面带来了几点重要的提升：

销售开票凭证自定义字段容量翻倍：销售开票凭证（包括发票、预制发票和开票请求）的抬头和行项目级别自定义字段容量从约3400字节增加到约6800字节，让您能够创建更多或更长的自定义字段。
自定义字段数据流打通：
- 从产品主数据到销售凭证：现在可以通过简单的配置，实现自定义字段从产品主数据自动带到销售凭证行项目，并且允许在销售凭证中修改。
- 从SD开票到FI-CA总账：在将SD开票凭证传输到合同应收应付（FI-CA）时，添加到SD开票项目中的自定义字段及其值，现在可以自动继承到FI-CA凭证的总账行项目中。
- 零售站点维护：关键用户根据业务需求，对“维护零售站点”应用进行自定义字段拓展。相关字段包括：零售站点 (Retail Site - RFM_SITE)、站点商品类别 (Site Merchandise Category - RFM_SITEMERCHANDISECATEGORY)、零售供应站点 (Retail Supplying Site - RFM_SITESUPPLYINGSITE)、站点商品类别供应站点 (Site Merchandise Category Supplying Site - RFM_SITEMRCHDSCATSUPPLYINGSITE)。此外，您可以通过在 SAP Business Application Studio 中创建 SAPUI5 适配项目来扩展该应用程序的源代码，并将其部署到公有云系统上。

此外，也有一些新增业务增强点。例如，在2602中，新增了催款通知的BAdI，允许在运行时将客户特定的字段填充到FI-CA催款通知中，这些字段可以直接在打印表单中使用。

自定义业务对象APP更新

“自定义业务对象”应用发布了新版本。您可以使用此应用创建包含字段、节点和行为的自定义业务对象。基于此类自定义业务对象，您可以生成一个包含数据库表、CDS 视图、OData 服务和 Fiori Elements 用户界面（UI）的应用程序。该应用的旧版本基于 BOPF 框架生成应用程序，而新版本则使用 RAP 框架。这个新应用允许您根据 Clean Core 的原则开发云就绪的应用程序。

新版本的APP包含如下几点功能：

• 生成功能齐全且包含用户界面（UI）的 RAP 业务对象
• 使用实体操作语言（EML）为业务对象添加行为
• 在自定义业务对象之间创建关联以实现重用
• 使用变更凭证跟踪自定义业务对象中的更改

自定义CDS视图的重要更新

如果您的自定义CDS视图是基于 I_ProjectBillingElement 创建的，请注意本次有需要立即处理的关键更新。为提升性能，系统底层的 I_ProjectBillingElement 视图已将一个旧的关联 (_WBSElement) 替换为新的关联 (_EnterpriseProjectElement)。

需要执行的操作分为两种情况：

对于关键用户可拓展性：操作相对简单。只需进入 Custom CDS Views 应用，找到层级最顶端的那个自定义视图，然后重新发布即可。
对于3SL中利用了开发者可拓展性：操作更为复杂。需要手动修改自定义视图的代码，显式地添加新的 _EnterpriseProjectElement 关联以及 ProjectElementUUID 字段。

请注意，如果不进行更新，系统将无法正确应用数据权限控制，导致用户获得无限制的数据访问权限，这是一个严重的安全漏洞。

以上就是在2602版本中可拓展性的亮点更新。更多详细内容，请参考：What’s New Viewer

How to enable BC Set support for BC app

2026-01-23T11:06:48.347000+01:00

Introduction

In order to use the "import from transport" function in the BC Set editor, the data must be recorded in the context of a transport object (TOBJ) and the business configuration maintenance object (SMBC) must maintain the corresponding transport object attribute.

This blog explains the necessary steps to enable existing SMBC objects for the "import from transport" functionality. Newly generated SMBC objects are automatically enabled.

This blog is relevant for

Case 1: Transport object is already used in the BC app

As of release 2302, when you use the ADT wizard to generate a business configuration maintenance object (SMBC), a transport object (TOBJ) is generated by default and used in the behavior implementation. In this case you only need to maintain the new "Transport Object" attribute of the SMBC object.

You can do this manually in the ADT editor of the SMBC object or programmatically. First you need to find out the name of the transport object. In most cases the name is equal to the name of the SMBC object. You can open the behavior implementation class and check the first couple of rows to verify the name of the transport object ( depending on the release the object was created: CO_TRANSPORT_OBJECT or TDAT_NAME )

CLASS LHC_COMPANYCODEALL DEFINITION FINAL INHERITING FROM CL_ABAP_BEHAVIOR_HANDLER.
  PUBLIC SECTION.
    CONSTANTS:
      CO_ENTITY TYPE abp_entity_name VALUE `ZI_COMPANYCODE_S`,
      CO_TRANSPORT_OBJECT TYPE mbc_cp_api=>indiv_transaction_obj_name VALUE `ZCOMPANYCODE`,
      CO_AUTHORIZATION_ENTITY TYPE abp_entity_name VALUE `ZI_COMPANYCODE`.

CLASS LHC_RAP_TDAT_CTS DEFINITION FINAL.
  PUBLIC SECTION.
    CLASS-METHODS:
      GET
        RETURNING
          VALUE(RESULT) TYPE REF TO IF_MBC_CP_RAP_TDAT_CTS.

ENDCLASS.

CLASS LHC_RAP_TDAT_CTS IMPLEMENTATION.
  METHOD GET.
    result = mbc_cp_api=>rap_tdat_cts( tdat_name = 'ZTAB6'

You can maintain the attribute "Transport Object" in the "Service Configuration" section of the SMBC object in the ADT editor. Save and activate.

You can update this attribute also programmatically:

CLASS zset_tobj DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zset_tobj IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    DATA smbc_id TYPE TABLE OF if_mbc_cp_api_business_config=>ty_technical_id WITH EMPTY KEY.
    SELECT ABAPObject FROM I_CustABAPObjDirectoryEntry
      WHERE ABAPObjectType = 'SMBC' AND ABAPObject LIKE '<NAMESPACE>%'
      INTO TABLE @smbc_id .
    LOOP AT smbc_id ASSIGNING FIELD-SYMBOL(<smbc_id>).
      out->write( |SMBC object: { <smbc_id> }| ).
      TRY.
          DATA(tobj) = mbc_cp_api=>business_configuration_api( <smbc_id> )->read( )-transport_object.
          IF tobj IS NOT INITIAL.
            out->write( |TOBJ already set: { tobj }| ).
          ELSE.
            mbc_cp_api=>business_configuration_api( <smbc_id> )->update_transport_object(
              transport_object = <smbc_id> "if the table list of the transport object does not match the table list of the behavior definition an exception is raised
              transport        = '<Workbench Request>' ). "transport=space for local objects
            out->write( |TOBJ set: { mbc_cp_api=>business_configuration_api( <smbc_id> )->read( )-transport_object }| ).
          ENDIF.
        CATCH cx_root INTO DATA(exc).
          out->write( |Error: { exc->get_text( ) }| ).
      ENDTRY.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

Use Case 2: The BC app does not use a transport object

Delete the existing BC app and create it again using the ADT wizard.

If you cannot do that, you can also use the ADT wizard to generate a new BC app for the table(s) with different object names. Move the generated transport object to the package of the old BC app and maintain the transport object attribute of the old SMBC object.
If necessary, adjust the generated TOBJ by changing the table piece list.
Adjust the old behavior implementation class by by replacing the existing method implementation with the equivalent method implementation of the new behavior implementation class. Adjust the constants to match the old object names.
You can now delete the newly generated objects.

Transport object names

The last character of the technical name of a transport object is its type. In the SMBC and TOBJ ADT editor, the technical name of the transport object is used. Use the input help to select a transport object.
In the API calls in the behavior implementation class, the type of a transport object is either a separate parameter or T (Individual Transaction Object) by default. That is, remove the last character for the name of the transport object.
Example:
In ADT, the name of the transport object is "ZTOBJ1 T" or "ZCOMPANYCODET". In the behavior implementation class, use "ZTOBJ1" or "ZCOMPANYCODE".

Using Custom Logic in SAP S/4HANA Cloud to change field status of Purchase Requisition

2026-01-26T04:50:48.909000+01:00

Problem Background:

We received a customer request: when creating a purchase requisition, they want the Valuation Price field to be optional, but in the current system this field is mandatory.

Solution:

Attempt to meet the requirement through custom logic using a BAdI.

Analysis Steps:

1. After searching in SAP for Me, we found a KBA 3322867 - Valuation Price field is mandatory in Create Purchase Requisitions app - SAP for Me which provides a solution to this problem. So we can try to use BAdI MM_PUR_S4_PR_FLDCNTRL_SIMPLE to solve this problem.

2. We enter APP Custom Logic to create an implementation. The description of this BAdI is "Change of Field Control for Purchase Requisitions". In the documentation, we can get more information including supported fields. "PURCHASEREQUISITIONPRICE - Valuation Price" is included, that means our requirement can be fulfilled by this BAdI.

3. With this BAdI, we can set four status for supported fields of Purchase Requisition: Hidden, Read-only, Mandatory, Optional.

'-': To hide the field
'*': To make the field read-only
'+': To make the field mandatory
'.': To make the field optional

4. The sample code of this BAdI is quite readable and easy. Based on this problem, implement the BAdI. The specific code is as follows.

FIELD-SYMBOLS <fs> TYPE mmpur_s_pr_fldsel.

READ TABLE fieldselection_table ASSIGNING <fs> WITH KEY field = 'PURCHASEREQUISITIONPRICE'.
IF sy-subrc EQ 0.
    <fs>-fieldstatus = '.'.
ENDIF.

5. After testing, the BAdI works prefect. This BAdI not only supports GUI APP - Create Purchase Requisition - Advanced, but also supports Fiori APP - Manage Purchase Requisitions - Professional.

Conclusion:

By reading this article and several previous blogs on similar scenarios, I hope you now understand how to use custom logic to apply certain restrictions when creating preliminary invoices for purchase orders.
You can find more information about SAP S/4HANA Cloud procurement-related issues at the following link: SAP S/4HANA Cloud Public Edition Sourcing and Procurement - SAP Community

You can also read more blogs about SAP S/4HANA Cloud procurement at the following link: SAP S/4HANA Cloud Public Edition Sourcing and Procurement - SAP Community

If you have any suggestions or thoughts about this article, please feel free to share them in the comments section. I look forward to communicating with you. You are also welcome to follow my personal account, and I look forward to seeing you in the next blog post!

SAP ICC Introducing New Refreshed Framework: Two Paths to Confidence

2026-01-29T14:37:02.527000+01:00

SAP always enables partners to extend its solutions in ways that foster innovation while preserving the stability of the core system. This rests on four architectural principles that shape how SAP builds solutions and how partners extend them.

Cloud-First architecture
Clean Core extensibility principle
Business AI and intelligent applications
Data-driven business operations

SAP Integration and Certification Center (SAP ICC) goal is maintaining ecosystem quality while avoiding disruptive changes that unnecessarily burden partners or customers.

The certification framework is designed to validate that partner applications enhance our value proposition, maintain the technical qualities required for continuous innovation, and align with our strategic direction and below priorities

Platform alignment matters
Upgrade resilience is essential
Standard integration methods

As a partner, if you are looking to extend SAP solutions, integrate your own solution, build a standalone application from scratch, or develop a comprehensive offering embracing SAP technology, the SAP ICC team provides you with the right services.

Two paths to confidence: Integration Certification and Interoperability Review.

To know more please join us at the

In-person events

Location: SAP Labs India - Whitefield, Bengaluru - 560066

Date: 05th February 2026

SAP Partner Meet-up: Driving Innovations Together

Webinar:

EMEA/APAC session
10:00–11:00 CET (UTC+1) → 14:30 IST, 17:00 SGT, 18:00 CST (China), 20:00 AEST
NA/LAC session
12:00–13:00 ET (UTC‑5) → 11:00 CT (MX), 10:00 MT, 09:00 PT, 14:00 BRT

Kyma Evolution: Transforming SAP Kyma into a tailor-made SaaS Platform for sbs extensions

2026-02-03T07:53:06.319000+01:00

Introduction

Hello SAP Community!

As an Extensibility Expert, I’m constantly looking for the most efficient ways to build and operate enterprise-grade extensions for the SAP Cloud ERP following the Clean Core principles. We all know the Cloud Application Programming Model (CAP) is the go-to framework for Cloud Native side-by-side Extensions on BTP, but where you run them on large scale matters just as much as how you code it.

Today, I’m starting a 3-part series (Part 2, Part 3 ) "Kyma Evolution". We will explore how the powercouple of Kyma in combination with the CAP Operator provides a scalable, high-performance, cost-effective runtime for CAP Multitenancy SaaS applications. In case you don’t know SAP Kyma and its benefits yet, please have a look at the Kyma Learning which explains it quite well.

The paradigm shift: From monolithic to a modular environment

For a long time, SAP Kyma was seen as a fixed bundle of tools. You got everything, whether you needed it or not. That has changed. With the Kyma Module Concept, the platform is now modular and extensible. Even more exciting is the introduction of Community Modules. This means Kyma is no longer limited to what SAP provides out-of-the-box. The community can now contribute extensions. One of the most powerful examples so far is the CAP Operator. By adding the CAP Operator as a module, you transform a generic Kyma cluster into a specialized CAP SaaS Runtime.

The "Smart Broker": Why the CAP Operator is a game-changer

When we compare Kyma to SAP BTP Cloud Foundry, the advantages of using a dedicated Operator become clear. While Cloud Foundry is a great general-purpose platform, the CAP Operator on Kyma acts as a "smart broker" specifically for CAP Applications.

Key Benefits for Partners and Customers:

100% Automated Lifecycle Management: The Operator understands CAP. It handles application deployment, tenant management, DB model updates, and service bindings automatically and new capabilities like SAP HANA Cloud Native tenants (Videocast) including tenant backup and restore management can be added once available.
Cost-Efficiency via Higher Container Density: In contrast to Cloud Foundry, Kyma allows for fine-grained resource limits. This means you can run more services on the same infrastructure, lowering your BTP bill when you are running multiple CAP Applications.
Cost-Efficiency via Resource Sharing: Expensive Services like SAP HANA Cloud and Cloud Logging can be shared in CF and Kyma. However we will see in Part 2 that in the Kyma environment this will be more elegant and simplified using the CAP Operator.
Enterprise Resilience & Day-2 Ops: It provides built-in "Reconciliation Loops." If a tenant's database connection fails, the Operator detects and fixes it without human intervention.
Advanced Networking & Security (Zero Trust Architecture): One of the most significant advantages over Cloud Foundry is how Kyma handles connectivity. In Cloud Foundry, preventing a service from being publicly accessible often requires manual effort. In Kyma, thanks to the CAP Operator's integration with Istio, your internal services stay cluster-internal by default. You have full control over the attack surface.
Integrated Domain Management: Managing Custom Domains becomes a native experience using the CAP Operator. Instead of juggling external services for certificates, you can orchestrate your SaaS-brand URLs directly within the Kyma environment, providing a seamless, secure and automated experience.

The ecosystem enablers: Extensibility using CAP Plugins + Kyma Modules

SAP is providing enablers for the ecosystem on different levels:

At the Infrastructure Level (Kyma): We use Modules (like the CAP Operator) to make the runtime "CAP-aware."
At the Application Level (CAP): We use CAP Plugins to add business features like multitenancy or audit logging with a single command.
At CAP CLI Level: We can add plugins like CAP Operator Plugin to the cds cli which provides capabilities to generate CAP Operator resources essential for deploying multi-tenant CAP Applications from your project setup.

This synergy creates the ultimate development and operations experience. You use plugins to build fast and the Operator to run smart and it enables you to contribute and to add your specific capabilities at any level.

Turning Kyma into a CAP Runtime

The beauty of this evolution is simplicity. You can now add the CAP Operator Community Module directly from your Kyma Cockpit using the Add Modules or Modify Modules Button on the Cluster Details Screen.

The Modules overview shows you the SAP Provided and Managed Modules under the Module Pane and the installed Community Modules in a separate Pane.

As a next step use the Add button on the Community Module Pane.

On the next screen you need to choose the Add Source YAML’s button to get the list of community modules.

Just keep the defaults and press the Add button.

This will load the list of currently available Community Modules from which you need to check the cap-operator Tile and press Add.

This will start the automatic installation of the CAP Operator Components into the namespace called cap-operator-system.

The installation and module status will be displayed in the overview and will turn into green after installation is successfully finished.

By doing this, you aren't just deploying code; you are creating an intelligent system that manages your S/4HANA Multitenancy extensions built with CAP for you as it adds Custom Resources (CRs) like CAPApplication, CAPApplicationVersion, CAP Tenant and other to your cluster. This will enable:

Quick and easy deployment of CAP application backends, router, and related networking components.
Integration with SAP Software-as-a-Service Provisioning service to handle asynchronous tenant subscription requests, executing provisioning / deprovisioning tasks as Kubernetes jobs.
Automated upgrades of known tenants as soon as new application versions are available.
Support for deployment of service-specific content / configuration as a Kubernetes job with every application version (for example, HTML5 application content to SAP HTML5 Application Repository Service).
Management of TLS certificates and DNS entries related to the deployed application, with support of customer-specific domains.

and further capabilities.

What’s Next?

In Part 2, we will dive deeper. We’ll look in more details of the runtime and at a cost benefits to prove why this modular approach is a win for your bottom line. What are your thoughts on the modular Kyma concept? Have you tried the CAP Operator yet? Have you ideas for additional community modules for the ecosystem?

Part 2: Runtime Architecture & Cost efficiency gains

2026-02-04T16:53:28.002000+01:00

Introduction

In Part 1, we introduced the CAP Operator as the brain to make out of your Kyma Cluster a runtime for CAP Multitenancy SaaS applications. Today, we dive into technical architecture. We will see why Kyma isn't just "another place to run containers," but can be turned into a highly optimized environment that saves costs by being smarter about how it uses resources, especially when compared to a traditional Cloud Foundry setup, important if you need to run CAP Multitenancy Applications on a large scale.

1. The Core Architecture paradigm: Declarative Tenant Management

While Cloud Foundry relies on imperative commands (like cf push or cf deploy), the CAP Operator uses Custom Resources (CRs) the Kubernetes extensibility API for customization. The most important one for SaaS Multitenancy CAP Solutions is the CAPTenant.

In Cloud Foundry, the Service Manager handles the creation of HDI containers, and it does the same in Kyma. However, the CAP Operator adds a layer of "Operational Intelligence":

Autonomous Monitoring: The Operator doesn't just trigger the Service Manager; it monitors the entire lifecycle of the tenant's database schema. If a cds deploy (migration) fails, the Operator detects the "Unhealthy" state and can automatically retry or alert, integrated directly into the Kubernetes event stream.
State Reconciliation: It ensures that the state of your tenants always matches your configuration. If a tenant record is stuck, the Operator's reconciliation loop acts as an automated "Day-2" administrator.
Automatic creation of the Provider tenant: The CAP Operator will automatically take care that the provider tenant for your SaaS Application is created and updated like for the Subscriber tenants, whereas in Cloud Foundry you will need to to care.

2. The "Zero-Idle" secret: On-Demand MTXS Pods

In a typical CAP multitenancy setup, the CAP MTXS component is the heavy lifter. It handles onboarding, unsubscription and database upgrades.

The Cloud Foundry Challenge: In CF, the MTXS logic often runs as one container or a permanent process within your application instance. This means you are constantly paying for the RAM and CPU of this "waiting" process, even if no one is subscribing to your app for days.

The Kyma + CAP Operator Advantage: The Operator implements what we call a "Zero-Idle" policy for provisioning tasks:

Trigger-based Lifecycle: When a subscription event occurs, the CAP Operator spins up a short-lived Job Pod specifically for the MTXS task of that tenant. For more details on how the CAP Operator manages the tenant lifecycle please have a look at the Tenant Provisioning Documentation.
Scale-to-Zero: With the CAP Operator you can run upgrades of your database tenants in parallel. Once the tenant is successfully managed and the database tenant is ready, the MTXS Pod is terminated.
Cost Benefit: You pay zero for the MTXS infrastructure during idle times. In large-scale landscapes with many extensions, this optimization can reduce your runtime memory footprint by 20–30%.

3. Scaling without linear cost growth

A common concern is that Kubernetes might be more expensive than Cloud Foundry. The reality is the opposite when scaling SaaS:

Bin-Packing: Kubernetes allows for "Overcommitting." Since your applications and tenants aren't all active at the same millisecond, you can pack more application instances onto a single K8S Node than the rigid memory cells of CF allow.
Resource Pooling: By using the CAP Operator to orchestrate the Service Manager, you can efficiently fill up large, cost-effective HANA Cloud instances. You avoid the "base cost" of having many small, underutilized HANA instances.
Efficiency Gains: As you grow from 10 to 100 tenants, your infrastructure costs grow at a much flatter angle because the "management overhead" (like MTXS) only consumes resources when it's actually working.

4. Centralized Observability: Selective Logging

Logging is often an overlooked cost driver. While both BTP environments use the SAP Cloud Logging Service which can be shared among multiple deployments, the way how it's done and how they handle logging data (storage as the major cost driver) is fundamentally different.

Cloud Foundry: Every app instance pushes all logs blindly to the service. You have little control over the volume.
Kyma (The Daemon Approach): Kyma uses the Telemetry Module (Fluent Bit) running as a daemon on every node.

Pre-Filtering: You can define a LogPipeline to filter logs before they leave the cluster. For example, you can exclude send logs from specific production namespaces or filter the logs by specific attributes.
Centralized Sharing: You don't need to bind every app. You define one central pipeline that securely routes logs from the entire cluster to a single Cloud Logging instance, providing a unified view with significantly lower ingest costs.

On how to use the SAP Cloud Logging with SAP Kyma, please have a look into the Kyma Integration with SAP Cloud Logging Blog.

Summary: The Architect's choice

Choosing Kyma and the CAP Operator isn't just about a "new technology." It's a strategic decision to move from reserved resources to on-demand resources and how to utilize them more efficiently.

CF: Predictable, but you often pay for "idling" capacity.
Kyma + CAP Operator: Dynamic, ensuring you only pay for what is actively serving your business or your tenants.

What’s Next?

Now that we have seen how the Power couple ”BTP Kyma&CAP Operator” enables you to lower your infrastructure cost in case of running CAP applications on large scale, we will see in Part 3 how the CAP Operator helps you to run your Application Lifecycle Management 100% automated which is a further important pillar to reduce your overall TCO.

Transport Mechanism of Key-User Extensibility Objects in Public Cloud & Private Cloud

2026-02-08T13:27:26.853000+01:00

We are now quite familiar with the concept of Key User Extensibility/In-App Extensibility while working in a S/4 HANA Cloud environment. Key User Extensibility is available in both the environments of S/4 HANA Cloud (Public Edition & Private Edition) and is the preferred mode of creating extension due to its highest Clean Core level and being lightweight.

There are many blogposts available in the community showing creation and usage of the most commonly used Key User Extensibility Objects like Custom Fields / Custom Business Objects / Custom CDS Views etc.

However, in this blog post we will discuss about the difference in approach to Transport the Key User Extensibility objects to higher environments (Dev -> Test/QA ->Prod) in S/4 HANA Cloud, Public Edition & S/4 HANA Cloud Private Edition .

Considering a use case of Custom fields for demonstration. Although for creation and modification of custom fields, the approach is similar in both Private and Public cloud but there are few differences in approach while it comes to transporting them and one of the key differences being -

A transport process for Key User Extensibility objects in Private Cloud are associated with an actual Transport Request number while in Public Cloud there is no actual Transport Request number associated while transporting them.

In this blogpost we will focus on the Transportation part but however for explanation I have added brief details on the creation process too.

S/4 HANA Cloud, Public Edition

S/4 HANA Cloud, Private Edition

Creation -

Fiori Application used – Custom Fields and Logic

Create the new custom field for the required business context and activate it for the required areas where you want to use this custom field -

After Enabling Usage for the required areas, click on Publish for the field to be available on the selected contexts.

If you want to add this field to your Fiori Application’s UI then you can do that using the option Adapt UI from the particular Fiori application for which you have created and exposed the custom field.

*Same as Public Cloud in this context
Fiori Application used – Custom Fields and Logic

The steps for activating the usage of the custom field and publishing are also same in S/4 HANA Private Cloud as shown in the other column for Public Cloud so you can follow all the same screenshots given in the left column for Private Cloud environment also.

**Screenshots have not been repeated.

Transport process -

No actual Transport Request number associated. Transport of Key User Extensibility objects happens using two Fiori Applications –

Export Software Collection (To be used in Source System)

Import Collection (To be used in Target system)

Transport happens with actual Transport Request number with two Fiori applications used –

Configure Software Packages

Register Extensions for Transport

Transportation process in Source system -

The transportation process is done by Software Collection.

The first step is to create a Software Collection and add the Custom field in the collection. This is done by the Fiori App – Export Software Collection

Once you create a Software collection you have to add your Custom field or whichever Extensibility object you are planning to move by clicking on Add Items

You can filter your Objects by selecting the type of objects you want to add in the Software Collection

Once everything is added you can click on Check and then finally Export

First step go to the Fiori Application Configure Software Packages and add registration for your package by clicking on the button Add Registration

Add your Transport Number from the F4 search help available under the column Transport Request to assign the package to a particular Transport number available.
Optionally you can turn on the Automatic Request handling for this package with the option available.

Second step go to the Fiori Application Register Extensions For Transport

Select your Custom field or the Extensibility object that you want to transport and click on Reassign to Package and select the package you registered in previous step.

By default your Extensibility object will get assigned to the Transport to which the package is assigned but you can change the transport assignment by clicking on the option Assign to Transport Request.

You can now go to Transaction Code SE10 and check the transport number under your name. The Custom field or the extensibility object that you added will be available in the Transport Request .

You can release and move the transport to upper environments based on the transport mechanism that is being followed in your project.

Transportation process in Target system -

Based on architecture if it is a 3-Tier Public Cloud system then the next higher environment is going to be the Test Environment in Public Cloud.

In the Test Environment open the application Import Collection

Select your Software collection that you exported from source system and click on Check and Import

If you want to move your Software Collection to production environment then you can move it by the Forward option in the Import Collection app

No such similar activity is required here. Transport will be moved and available in QA/Test environment with transport release mechanism followed.

**Additional information –

Use the Fiori Application Extensibility Inventory in both the S/4 HANA Cloud versions to check dependencies of objects before transporting.

Unlock S/4HANA Cloud Secrets: Hybrid Events+APIs Strategy for Seamless BTP Data Flows

2026-02-12T01:30:35.487000+01:00

Strategic Financial Data Extraction from SAP S/4HANA Cloud Public Edition to SAP BTP

Using Transfer Pricing as a Real-World Example

Transfer pricing represents a perfect use case to demonstrate generic financial data extraction strategies from SAP S/4HANA Cloud Public Edition. Multinational organisations need GL, Controlling, Material Ledger, and Asset Accounting postings to flow reliably to external engines hosted on SAP BTP—but Public Cloud’s “no direct database access” constraint demands architecturally sound patterns.

Why Transfer Pricing Perfectly Illustrates the Challenge

The business need: Calculate inter-company markups (cost-plus, resale-minus) using real-time ACDOCA postings across multiple currencies, profit centres, and cost elements.
The constraint: Pure cloud extensibility—no RFCs, no custom ABAP, no direct table extracts.
The solution: Three proven patterns that work for any financial data integration scenario.

Pattern 1: Event Notifications (Real-Time Push Model)

How transfer pricing uses it: GL postings trigger automatic business event notifications routed through SAP Event Mesh to BTP applications.

Event Notification

Generic applicability: Works for any posting-driven process—revenue recognition, inter-company reconciliation, compliance monitoring.

High-level activation:

Integration configuration apps → Activate accounting-related event notifications
Communication scenarios → Configure outbound event destinations
Event Mesh subscription → Point to BTP service endpoint
Payload contains: Company codes, ledger amounts (local/group), profit centres, material valuations

Pattern 2: Standard Query Services (Scheduled Pull Model)

How transfer pricing uses it: BTP service queries S/4HANA nightly for new/changed financial postings.

Query ServiceKey services (release-dependent availability):

Financial line item services → GL/CO/ML/AA postings
Profitability services → Margin analysis data
Material valuation services → Cost component details

Generic applicability: Perfect for scheduled reconciliation, historical backfills, or validation runs.

Pattern 3: Hybrid Extraction (Production Resilience)

Transfer pricing demands 99.9% coverage. Smart architects layer all three patterns:

Use Case	Primary Pattern	Transfer Pricing Example	Generic Use
Real-time GL postings	Event notifications	Invoice → immediate markup	Any posting trigger
Historical catch-up	Standard APIs	Month-end reconciliation	Data migration
Day 1 implementation	Bulk extraction	Full ACDOCA baseline	Initial loads
Custom calculations	BTP processing	Exception overrides	Business rules

Three-tier reference flow:

Hybrid ExtractionBTP Implementation Patterns (Transfer Pricing Example)

Cloud Application Programming Model (CAP)

service FinancialIntegration {
  entity Postings as projection on external financial services;
  entity PricingResults as projection on HANA staging;
}

Pattern: Event handlers + scheduled queries → unified HANA staging → business rules.

ABAP RESTful Application Programming (RAP)

define root view entity FinancialDataView
  as select from standard financial services

Pattern: Analytical CDS views over external data → transactional services.

Architect’s Production Checklist

✅ Tenant validation: Test events/APIs in your specific S/4HANA Cloud environment
✅ Quota management: Monitor Event Mesh throughput + API rate limits
✅ Fallback design: API polling validates event stream completeness
✅ Quarterly readiness: SAP evolves event coverage and API fields continuously
✅ Pure cloud: Zero custom code in production S/4HANA

The Universal Pattern

Transfer pricing proves the strategy works for complex financial scenarios. The same architecture applies to:

Inter-company reconciliation
Revenue recognition automation
Compliance reporting engines
Analytics data pipelines
Any standard data object/model driven process

Universal PatternKey takeaway: This isn’t “just for transfer pricing”—it’s your reusable blueprint for any S/4HANA Cloud → BTP data integration.

🌥️ 为什么 S/4HANA Cloud 原来的两系统客户要转向三系统？

2026-02-12T07:19:23.345000+01:00

很多上 S/4HANA Cloud 的公司会问同一个问题：

我们之前用质量（Q）+ 生产（P）的“两系统”不也挺好吗？
为什么 SAP 现在要我们改成“三系统”？会不会更复杂？

其实，SAP 推三系统不是为了“复杂”，而是为了让云 ERP 更稳、更安全、更能支持企业未来的发展。下面用最简单的方式帮你理解。

🧩 1. 两系统 vs 三系统，用生活比喻怎么理解？

先看两系统（2SL）：

质量系统（做所有配置、测试）  
↓  
生产系统（真正用来跑业务）

听起来省事，但会有一个大问题：

配置、测试和变更全挤在一个质量系统里，风险集中，升级或大变更容易干扰上线节奏。

现在的三系统（3SL）结构：

开发系统（做配置 + 扩展）  
↓  
测试系统（专门用来测试）  
↓  
生产系统（跑真正业务）

这是一个 “Development + Test + Production” 的体系，也是SAP系统之前如此成功的原因之一。

就像你开餐厅：

开发系统 = 后厨的试菜间（可以自由尝试）
测试系统 = 员工试吃区（必须确保稳定、菜品没问题）
生产系统 = 正式给客人的餐厅（不能出错、不能乱改）

三系统 = 把“试菜”“试吃”“正式上菜”都分开，让餐厅品质更稳定。

🔍 2. 两系统为什么不够用？

SAP 官方给出的原因可以总结为四个词：
发展、稳定、创新、合规。

（1）业务越来越复杂，需要更稳的变更流程

旧的 Q 系统既是测试环境，又承担了变更准备、并行项目等任务。
一旦多个项目同时动起来，就很容易互相干扰。
三系统把开发与测试分开后，单独的开发、配置和测试的环境，项目并行、变更管理更安全。

（2）需要支持更多“开发能力”

三系统加入了正式的开发系统（Dev），其中包含开发租户（D080环境），可做更高级的 ABAP Cloud 扩展。
这让云系统也能支持更多个性化场景，而不会污染测试或生产环境。

（3）测试必须更专业，不能“和配置混在一起”

在三系统中：

配置在 Dev100租户做
测试在 Test租户专门验证
生产只运行最终正确版本

这种分离让测试质量更高，也不会因为配置冲突导致混乱。

（4）云升级节奏更快，三系统更能抗“升级风险”

S/4HANA Cloud 公有云每季度都有创新功能发布。

如果你用两系统：
升级期间 Q 系统要停用或冻结，可能影响你的项目时间线。

三系统可以：

Dev 做配置和升级适配
Test 做回归测试
Prod 等全部准备好后再升级
即使在升级期间，也不会冻结传输。例如，D在N版本，T在N+1版本，也同样可以传输。

这样升级更稳，不会影响日常业务运行。

🧠 3. 一句话总结：为什么 SAP 要让客户都转三系统？

👉 因为两系统已经不足以支持企业数字化的复杂度、并发项目数量、定制化扩展需求，以及云时代更快的更新节奏。
三系统能保证更高的质量、更低的风险、更强的灵活性。

🏢 4. 那对企业实际有什么好处？

✔ 业务变更更可控

所有新配置、新开发先在 Dev 做，再在 Test 验证，不会影响生产。

✔ 上线风险更低

Test 环境专注测试，质量更高，减少“带病上线”。

✔ 支持更强的扩展能力

Dev 系统包含 ABAP 开发租户，企业有更多自主扩展的空间。

✔ 更适合多国家、多业务线的公司

三系统可以免费申请并行线（Parallel Lines）环境，可多两个环境（D120和T120），更加灵活的满足项目实施和日常使用的场景：独立的配置、测试、数据迁移、培训等场景。

✔ 适应云时代更快的创新节奏

客户可以在更多测试空间里准备升级，不会因升级影响项目计划。

📦 5. SAP 已经启动“两系统客户升级到三系统”的计划（3SL Conversion Program）

SAP 热烈欢迎所有两系统客户加入三系统转换计划，并准备把所有用户统一迁移到最新的三系统架构（基于 SAP Central Business Configuration）。目前已经有超过50家两系统的客户成功升级到了三系统，这其中，既有来自中国的客户，也有来自全球其他国家的客户。如有兴趣了解更多关于三系统和三系统转换的信息，可参考链接：SAP S/4HANA Cloud Public Edition, Three-System Landscape | SAP Community

换句话说：

🟢 三系统将成为 S/4HANA Cloud 公有云的“标准配置”。
🟢 两系统将逐步退出历史舞台。

✨ 6. 用一个最简单的比喻总结

三系统=
“试做区（Dev） + 试运行区（Test） + 正式运行区（Prod）”

两系统=
“试做+试运行合并（Q） + 正式运行（P）”

为什么要升级？

因为做菜的人、吃菜的人、正式客人越来越多，让大家都挤在一个厨房里，风险太大了。

三系统能让所有流程更专业化，也更安全。

关于两系统和三系统的区别，请浏览该文档：2SL-3SL-Delta_Features_PUBLIC.pdf

🎯 最后的重点

向三系统转型，不是增加复杂度，而是让企业在云端走得更稳、更快、更灵活。

如想了解关于三系统转换的更多内容或有任何问题，请随时联系！

Cannot integrate SAP Cloud ALM

2026-02-16T04:00:45.885000+01:00

Dear All,

I cannot connect communication arrangement with cloud ALM.

It's an error as below. Please kindly advice me how to setup?

Regards,

Keratiya D,

How to Validate Business Partner’s CEP (Brazilian postal code) through Extensibility using ABAP

2026-02-19T18:11:34.521000+01:00

How to Validate Business Partner’s CEP (Brazilian postal code) through Extensibility using ABAP

SAP Solutions:

SAP S/4HANA Cloud, Public Edition (SAP Cloud ERP).
ABAP Development Tools (ADT) for Eclipse.

Third party API:

This blog utilizes the API https://viacep.com.br/. This is a free-to-use API provided by a third party, thus is not under any SAP responsibility. Keep in mind that its usage for CEP validation is at your own risk and that you can use any API of your choice.

Knowledge Required:

How to connect ADT for Eclipse to an SAP S/4HANA Cloud Public Edition system.
- Connect to the ABAP System | SAP Help Portal
How to create an ABAP Class using ADT for Eclipse.
- How to create a Class in ABAP 00 - 6 Steps to start | SAP Community
- How to create a class in ABAP 00 - example code, with little typing. AdT is great! | SAP Community

Step I – Create an ABAP Class

First of all, we need to create an ABAP class that makes the requests to the API. It should also handle the API response, which is in JSON format. Below, you will find a sample implementation of this class, but keep in mind that this is just an example and can be adjusted as needed.

CLASS zbl_cl_get_request DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .
  PUBLIC SECTION.
    TYPES: BEGIN OF ty_address_br,
             cep         TYPE c LENGTH 9,
             logradouro  TYPE c LENGTH 100,
             complemento TYPE c LENGTH 100,
             bairro      TYPE c LENGTH 60,
             localidade  TYPE c LENGTH 40,
             uf          TYPE c LENGTH 2,
             estado      TYPE c LENGTH 40,
             regiao      TYPE c LENGTH 20,
             ibge        TYPE c LENGTH 10,
             gia         TYPE c LENGTH 10,
             ddd         TYPE c LENGTH 3,
             siafi       TYPE c LENGTH 10,
             unidade     TYPE c LENGTH 50,
           END OF ty_address_br.

    TYPES: tt_address_br TYPE STANDARD TABLE OF ty_address_br WITH DEFAULT KEY.
    CLASS-METHODS create
      RETURNING VALUE(ro_instance) TYPE REF TO zbl_cl_get_request.
    CLASS-METHODS get_data
      IMPORTING iv_postal_code TYPE string
      RETURNING VALUE(rs_data) TYPE ty_address_br .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS ZBL_CL_GET_REQUEST IMPLEMENTATION.
  METHOD get_data.
    DATA ls_viacep TYPE ty_address_br.
    TRY.
        DATA(lo_destination) = cl_http_destination_provider=>create_by_url(  'https://viacep.com.br'  ).
      CATCH cx_http_dest_provider_error INTO DATA(lo_http_dest_provider_error).
        "handle exception
        DATA(lv_http_dest_provider_error) = lo_http_dest_provider_error->get_text( ).
    ENDTRY.

    TRY.
        DATA(lo_http_client) = cl_web_http_client_manager=>create_by_http_destination( lo_destination ).
      CATCH cx_web_http_client_error INTO DATA(lo_web_http_client_error).
        "handle exception
        DATA(lv_web_http_client_error) = lo_web_http_client_error->get_text( ).
    ENDTRY.

    " Set HTTP Method (GET, POST, etc.)
    DATA(lo_request) = lo_http_client->get_http_request( ).
    DATA(lv_uri) = '/ws/' && iv_postal_code && '/json/'.
    lo_request->set_uri_path( lv_uri ).
    " Send Request
    TRY.
        DATA(lo_response) = lo_http_client->execute( i_method = if_web_http_client=>get ).
      CATCH cx_web_http_client_error INTO lo_web_http_client_error.
        "handle exception
        lv_web_http_client_error = lo_web_http_client_error->get_text( ).
        "handle exception
    ENDTRY.

    " Get Response
    DATA(lv_resp_satus) = lo_response->get_status( ).
    DATA(lv_resp_text) = lo_response->get_text( ).
    /ui2/cl_json=>deserialize(
      EXPORTING json = lv_resp_text
      CHANGING  data = ls_viacep
    ).
    rs_data = ls_viacep.
  ENDMETHOD.

  METHOD create.
    CREATE OBJECT ro_instance.
  ENDMETHOD.

ENDCLASS.

Step II – Enable this Class to be Used in Key-User Extensibility

To use this class in the Custom Logic app inside SAP S/4HANA Cloud Public Edition, the property “Use in Key User apps”, under “API State”, must be set as “Yes”. This must be done in ADT for Eclipse.

Step III – Implement the Custom Logic

In the customizing tenant of SAP S/4HANA Cloud Public Edition, go to the Custom Logic app (F6957) and click on the “Create” button.
Choose the BAdI “Validate BP BADI” (ID: “CMD_VALIDATE_BP”).
Give it a name and description.
Open the implementation and click on the button “Open Code Editor”.
Add the sample code below.
Publish the code, then start testing.

Again, this is just an example and can be adjusted as needed.

DATA: ls_bp_address LIKE LINE OF it_bp_address,
           ls_message    LIKE LINE OF ct_validationmessage,
           lv_message    TYPE string,
          lv_postalcode TYPE string.
*Clearing the variants, just in case
CLEAR: lv_message, lv_postalcode.
*Fiiling ls_bp_address with it_bp_address data
LOOP AT it_bp_address INTO ls_bp_address.
*Attributing the value for lv_postalcode
  lv_postalcode = ls_bp_address-postalcode.
*Removing the '-' from the CEP
  REPLACE ALL OCCURRENCES OF SUBSTRING '-' IN lv_postalcode WITH ' '.
*Checking if the BP country is Brazil
  IF ( ls_bp_address-country = 'BR' OR ls_bp_address-country = 'Brazil' ).
    DATA(lo_srv) = zbl_cl_get_request=>create( ).
    DATA(ls_data) = lo_srv->get_data( iv_postal_code = lv_postalcode ).
    IF ls_data IS NOT INITIAL.
*Cheking if the region from the CEP's code list is differnent from the one informed in the BP Master Data
      IF NOT ls_data-uf = ls_bp_address-region.
        CLEAR ls_message.
        ls_message-msgty = 'E'.
        ls_message-msgv1 = |Region informed: { ls_bp_address-region }. Region CEP: { ls_data-uf }|.
        APPEND ls_message TO ct_validationmessage.
      ENDIF.
*Cheking if the city from the CEP's code list is differnt from the one informed in the BP Master Data
      IF NOT ls_data-localidade = ls_bp_address-cityname.
        CLEAR ls_message.
        ls_message-msgty = 'E'.
        ls_message-msgv1 = |City informed: { ls_bp_address-cityname }. City CEP: { ls_data-localidade }|.
        APPEND ls_message TO ct_validationmessage.
      ENDIF.
*Cheking if the street from the CEP's code list is differnt from the one informed in the BP Master Data
      IF NOT ls_data-logradouro = ls_bp_address-streetname.
        CLEAR ls_message.
        ls_message-msgty = 'E'.
        ls_message-msgv1 = |Street informed: { ls_bp_address-streetname }. Street CEP: { ls_data-logradouro }|.
        APPEND ls_message TO ct_validationmessage.
      ENDIF.
    ENDIF.
  ENDIF.
ENDLOOP.

Step IV – Transport

After testing, you can transport it.

Creating Extension Items and Transporting Them | SAP Help Portal

SAP S/4HANA Public Cloud Edition – All Communication Scenarios in One Place (Bookmark)

2026-02-22T22:46:31.615000+01:00

Make sure to bookmark this blog so you can easily revisit all communication scenarios in one place. Share it with your friends and colleagues—it’s a handy resource when searching across different SAP portals.

What is a Communication Scenario ?

A Communication Scenario in SAP S/4HANA Public Cloud is a predefined, packaged set of:

Inbound/Outbound APIs (OData, SOAP)
Business events (for event-based integration)
Message types
Authorizations

These scenarios act as the integration between SAP S/4HANA Public Cloud and other SAP Products or external systems.

Think of a communication scenario as a “bundle” :

These are the APIs and permissions this external system is allowed to use, and here’s how the communication should happen.

Each Communication Scenario is delivered by SAP S/4HANA Public Product Release and cannot be modified—but you can activate and use them.

Key Components of a Communication Scenario

A typical scenario includes:

1. Communication User

A technical user used for authentication.
Supports:

Basic Authentication
OAuth 2.0 (strongly recommended)

2. Communication System

Represents the external (non‑SAP) or SAP system you are integrating with.
Defines:

Hostname / Token URLs
Outbound target URLs
Authentication method

3. Communication Arrangement

This is where everything comes together.

You assign:

The Communication Scenario
The Communication System
The Communication User
Any specific parameters (e.g., service URLs, outbound destinations)

If you think of it simply:

Scenario = Template
Arrangement = Active Configuration

Why Are Communication Scenarios Important?

In S/4HANA Public Cloud, customers cannot create custom communication scenarios like in on‑premise or Private Cloud. This strict governance ensures:

Security and compliance
System stability
Standardized integration patterns
Ease of lifecycle management during upgrades

So instead of customizing scenarios, you configure and connect the right SAP‑delivered scenarios.

APIs usually come with a predefined communication scenario. To use the APIs, you first need to create a communication arrangement based on the communication scenario.

How to Configure a Communication Scenario: Step-by-Step

Step 1: Create a Communication User

SAP Fiori App: Maintain Communication Users

Create user → assign password → store securely
Or create an OAuth technical user (preferred)

Step 2: Create a Communication System

SAP Fiori App: Communication Systems

Here you:

Assign the communication user
Maintain authentication method
Provide target host details
Configure OAuth token endpoint (if applicable)

Step 3: Create Communication Arrangement

SAP Fiori App: Communication Arrangements

Steps:

Select the communication scenario (e.g., SAP_COM_0008)
Assign the communication system
Review/activate inbound and outbound services
Copy Service URLs for external system use

Once activated, the APIs are ready for use.

Testing Your Scenario

You can test APIs using tools like:

SAP Business Accelerator Hub (API Hub)
SAP Integration Suite (CPI)
SAP API Management
SAP BTP (Destinations, Side by Side Extensions, Extensibility Development)
Custom integrations

Check which communication scenario fits to your purposes best.

The following list gives you an overview of the most important communication scenarios available today

Communication Scenario ID	Description
SAP_COM_0227	(Deprecated) Marketing - Campaign Execution - Twitter Integration
SAP_COM_0346	(Deprecated) Product Lifecycle Management - Product Structure Integration
SAP_COM_0901	ABAP Test Cockpit - ATC Run Integration
SAP_COM_0942	Advanced Backorder Processing Integration
SAP_COM_0438	Advanced Compliance Reporting Integration using SLHACR
SAP_COM_0A49	AI-Assisted Situation Handling Integration
SAP_COM_0454	Application Monitoring Integration (Obsolete)
SAP_COM_0508	Ariba Network - Buyer Integration via CIG Integration
SAP_COM_0081	Ariba Network - Supplier Integration
SAP_COM_0032	Ariba Network Integration
SAP_COM_0244	Asset Central Foundation for Maintenance Execution Integration
SAP_COM_0262	Asset Intelligence Network for Product Information Integration
SAP_COM_0395	Asset Management Master Data Integration
SAP_COM_0927	Assignment Status for Project Demands Integration
SAP_COM_0790	Assortment Module Integration
SAP_COM_0935	Available-to-Promise (ATP) Check Integration
SAP_COM_0379	Bank - Bank Integration
SAP_COM_0141	Batch Management - Batch IDoc/RFC Inbound Integration
SAP_COM_0337	Batch Management - Batch OData Inbound Integration
SAP_COM_0774	Batch Management - Batch SOAP Inbound Integration
SAP_COM_0855	Batch Management - Batch SOAP Outbound Integration
SAP_COM_0120	Billing Integration
SAP_COM_0745	Block Intercompany Postings Integration
SAP_COM_0349	Buffer Profile Integration
SAP_COM_0359	Buffer Sizing Integration
SAP_COM_0888	Business Data Orchestration - UI Integration
SAP_COM_0594	Business Data Orchestration Integration
SAP_COM_0121	Business Event Handling Integration (Obsolete)
SAP_COM_0A54	Business Event Log - SQL Read Integration
SAP_COM_0943	Business Object Cost Center Integration
SAP_COM_0A91	Business Object Project Settlement Rules Integration
SAP_COM_0091	Business Partner, Customer and Supplier Blocking Integration
SAP_COM_0008	Business Partner, Customer and Supplier Integration
SAP_COM_0394	Business Place Integration
SAP_COM_0698	Business Process Intelligence Integration
SAP_COM_0523	Business Process Monitoring Push Integration
SAP_COM_0366	Business Role Change Document Integration
SAP_COM_0A04	Business Role Read Integration
SAP_COM_0345	Business Situation Integration
SAP_COM_0376	Business Situation Master Data Integration
SAP_COM_0706	Business Solution Order Integration
SAP_COM_0327	Business User Change Document Integration
SAP_COM_0889	Business User Logon Details Read Integration
SAP_COM_0083	Central Finance Subsidiary Integration
SAP_COM_0A94	Central Payment Repository - Requested Payment Integration
SAP_COM_0A13	Certificate Read Integration
SAP_COM_0160	Classification Systems Integration
SAP_COM_0163	Classification Systems OData/SOAP Integration
SAP_COM_0A31	Cloud Integration Automation Integration
SAP_COM_0430	CMIS Repository Synchronization Integration
SAP_COM_0054	Commercial Project Integration
SAP_COM_0A07	Communication Arrangement Read Integration
SAP_COM_0400	Communication Management - HTTP Inbound Test Integration
SAP_COM_0401	Communication Management - HTTP Outbound Test Integration
SAP_COM_0A48	Communication Management Integration
YY1_GLACCOUNTLINEITEM	Communication Scenario for GLAccountLineItem
YY1_GLACCOUNTLINEITEM_V2	Communication Scenario for GLACCOUNTLINEITEM_V2
YY1_I_GLACCLINEITEM	Communication Scenarion for I_GLAccountLineItem
SAP_COM_0A06	Communication System Read Integration
SAP_COM_0A05	Communication User Read Integration
SAP_COM_0946	Complaint Handling Integration
SAP_COM_0070	Concur Integration
SAP_COM_0536	Concur POC Integration
SAP_COM_0A08	Content Security Policy Read Integration
SAP_COM_0682	Contract Accounting - Payment Information Integration
SAP_COM_0298	Contract Proposal Integration (Deprecated)
SAP_COM_0165	Convergent Invoicing Integration
SAP_COM_0158	Credit Memo Request Integration
SAP_COM_0722	CSN Exposure Integration
SAP_COM_0464	Custom Code Migration Integration
SAP_COM_0449	Custom Services for Citizen Integration
SAP_COM_0589	Customer Data Return Integration
SAP_COM_0134	Customer Material Info Record Integration
SAP_COM_0459	Customer Return Bulk Integration
SAP_COM_0497	Customer Return Bulk Replication Integration
SAP_COM_0157	Customer Return Integration
SAP_COM_0730	Customer Type Integration
SAP_COM_0080	Data Quality Management Integration
SAP_COM_0209	Data Warehouse - ODP Data Extraction Integration
SAP_COM_0159	Debit Memo Request Integration
SAP_COM_0570	Delivery Insights Integration (Obsolete)
SAP_COM_0571	Delivery Insights Replication App Integration (Obsolete)
SAP_COM_0106	Delivery Processing Integration
SAP_COM_0557	Digital Manufacturing for Network wth Quality Info Record Integration (Obsolete)
SAP_COM_0693	Digital Vehicle Integration
SAP_COM_0426	Direct Material Sourcing With Blockchain Integration
SAP_COM_0077	Distributed Manufacturing Integration (Deprecated)
SAP_COM_0854	Document and Reporting Compliance Cloud Edition Integration
SAP_COM_0703	Document Compliance - Electronic Document File Integration
SAP_COM_0626	Document Compliance Localization Extension Integration (Obsolete)
SAP_COM_0529	Document Compliance PEPPOL Integration
SAP_COM_0A82	Document Information Extraction Integration
SAP_COM_0872	DRC - External reporting system integration
SAP_COM_0548	E-Mail - Outbound Integration
SAP_COM_0A52	EBPP Payment Request Integration
SAP_COM_0448	eDocument - Argentina eInvoice Integration
SAP_COM_0669	eDocument - Chile eInvoice and Delivery Note Integration
SAP_COM_0670	eDocument - Colombia eInvoice and Incoming eInvoice Integration
SAP_COM_0255	eDocument - eInvoice and ePayment for Mexico Integration
SAP_COM_0689	eDocument - Greece electronic Tax register books Integration
SAP_COM_0417	eDocument - Hungary Invoice Registration Integration
SAP_COM_0629	eDocument - India eInvoice Solution Integration.
SAP_COM_0429	eDocument - India eWay Bill Solution Integration
SAP_COM_0418	eDocument - Italy eInvoice and Incoming eInvoice Integration
SAP_COM_0873	eDocument - Peru eInvoice and Delivery Note Integration
SAP_COM_0856	eDocument - Poland eInvoice Integration
SAP_COM_0631	eDocument - Portugal eInvoice Integration
SAP_COM_0494	eDocument - Portugal Transport Registration Integration
SAP_COM_0859	eDocument - Romania eInvoice Integration
SAP_COM_0898	eDocument - Saudi Arabia eInvoicing Integration
SAP_COM_0A19	eDocument - Serbia eInvoice Integration
SAP_COM_0877	eDocument - Slovakia eInvoice Integration
SAP_COM_0468	eDocument - South Korea eInvoice Integration
SAP_COM_0419	eDocument - Spain Invoice Registration Integration
SAP_COM_0846	eDocument - Switzerland eInvoice and Incoming eInvoice Integration
SAP_COM_0851	eDocument - Thailand eInvoice Integration
SAP_COM_0421	eDocument - Turkey eDelivery Note and Incoming eDelivery Note Integration
SAP_COM_0422	eDocument - Turkey eInvoice and Incoming eInvoice Integration
SAP_COM_0225	eDocument - VAT Register Books for Spain Integration
SAP_COM_0688	EHS - Authority Servers with E-Waste Documents Integration
SAP_COM_0857	Electronic Document - Egypt Electronic Invoice Integration
SAP_COM_0056	Employee Central Cost Center Integration
SAP_COM_0441	Employee Central Financial Master Data Integration
SAP_COM_0028	Employee Central Payroll Integration
SAP_COM_0535	Employee Central via SAP CPI Integration
SAP_COM_0001	Employee Integration
SAP_COM_0518	Enterprise Contract Management - DocuSign Integration
SAP_COM_0521	Enterprise Contract Management - External Linked Objects Integration
SAP_COM_0809	Enterprise Contract Management - Hub System Integration
SAP_COM_0868	Enterprise Contract Management - Icertis Integration
SAP_COM_0869	Enterprise Contract Management - Icertis Operational Integration
SAP_COM_0890	Enterprise Contract Management - Icertis UI Integration
SAP_COM_0823	Enterprise Contract Management - Microsoft Teams Integration
SAP_COM_0824	Enterprise Contract Management - Microsoft Teams Operational Integration
SAP_COM_0437	Enterprise Contract Management and Assembly Integration
SAP_COM_0A23	Enterprise Event Enablement - Direct Event Inbound Integration
SAP_COM_0A22	Enterprise Event Enablement - Direct Event Outbound Integration
SAP_COM_0092	Enterprise Eventing Integration
SAP_COM_0963	Enterprise Project - Blockable Function Integration
SAP_COM_0470	Enterprise Project - Central Finance Integration
SAP_COM_0250	Enterprise Project - Collaboration Integration
SAP_COM_0252	Enterprise Project - Collaboration UI Integration
SAP_COM_0656	Enterprise Project - Collaborative Project Integration
SAP_COM_0723	Enterprise Project - Internal Project Type Integration
SAP_COM_0726	Enterprise Project - Project Priority Integration
SAP_COM_0725	Enterprise Project - Project Processing Status Integration
SAP_COM_0724	Enterprise Project - Project Profile Integration
SAP_COM_0917	Enterprise Project Element - Deliverable Type Integration
SAP_COM_0308	Enterprise Project Integration
SAP_COM_0945	Enterprise Project Service Organization Integration
SAP_COM_0369	Environment, Health and Safety - Incident Reporting Integration
SAP_COM_0671	Environment, Health and Safety - Workers' Compensation Associations Integration
SAP_COM_0747	Environment, Health, and Safety - Automatic Data Collection Integration
SAP_COM_0A71	Environment, Health, and Safety - SAP SuccessFactors Learning Integration
SAP_COM_0602	Event Consumption Model Inbound Test Integration
SAP_COM_0634	Excise Tax EMCS Integration
SAP_COM_0568	Excise Tax Integration
SAP_COM_0694	Extensibility UI Text Translation Adaptation Integration
SAP_COM_0176	External Billing Document Request Integration
SAP_COM_0301	External HR Workforce Integration
SAP_COM_0177	External Sales and Use Tax Calculation Integration
SAP_COM_0326	External Scheduler - Application Job Administration Integration
SAP_COM_0064	External Scheduler - Application Job Scheduling Integration (Deprecated)
SAP_COM_0944	Factory Calendar - Pull Inbound Integration
SAP_COM_0732	Field Logistics - Manage Supplier Item Integration
SAP_COM_0752	Field Logistics - Pack Container Integration
SAP_COM_0753	Field Logistics - Shipment Voyage Integration
SAP_COM_0952	Field Logistics Shipment Container Integration
SAP_COM_0679	Field Logistics Supplier Item to Fieldglass Integration
SAP_COM_0074	Fieldglass Integration
SAP_COM_0321	Finance - Account Payable Configuration Integration
SAP_COM_0313	Finance - Account Payable Payment Advice Integration
SAP_COM_0251	Finance - Account Payable Positive Pay Integration
SAP_COM_0316	Finance - Account Receivable Bank Statement Integration
SAP_COM_0314	Finance - Account Receivable Payment Advice Integration
SAP_COM_0303	Finance - Accounting Analytics Integration
SAP_COM_0338	Finance - Accounting Correspondence Integration
SAP_COM_0277	Finance - Accounting Document Integration
SAP_COM_0179	Finance - Accounting Master Data Integration
SAP_COM_0590	Finance - Accounts Payable Discount Management Integration
SAP_COM_0759	Finance - Accounts Receivable Lockbox Integration
SAP_COM_0719	Finance - Accounts Receivable SEPA Mandate Integration
SAP_COM_0775	Finance - ACR Services for Partner Enablement Integration
SAP_COM_0129	Finance - Activity Type Integration
SAP_COM_0649	Finance - Advanced Payment Management - Watch List Screening Hits Integration
SAP_COM_0648	Finance - Advanced Payment Management - Watch List Screening Integration
SAP_COM_0315	Finance - Allocation Posting Integration
SAP_COM_0278	Finance - Bank Account Inbound Integration
SAP_COM_0279	Finance - Bank Account Outbound Integration
SAP_COM_0256	Finance - Bank Connectivity Integration
SAP_COM_0127	Finance - Bank Integration
SAP_COM_0388	Finance - Bank Reconciliation Integration
SAP_COM_0733	Finance - Brazilian ACR Reports Integration
SAP_COM_0284	Finance - Cash Management Inbound Integration
SAP_COM_0285	Finance - Cash Management Outbound Integration
SAP_COM_0126	Finance - Central Entity Integration
SAP_COM_0674	Finance - Central Finance SEPA Mandates Integration (Obsolete)
SAP_COM_0727	Finance - China Payment Requisition Integration
SAP_COM_0241	Finance - Cloud Consolidation Data Collection Integration
SAP_COM_0336	Finance - Cloud Consolidation Master Data for Group Reporting Integration
SAP_COM_0903	Finance - Cloud Consolidation Task for Group Reporting Integration
SAP_COM_0348	Finance - Cloud Consolidation Transaction Data for Group Reporting Integration
SAP_COM_0A83	Finance - Collections and Dispute Automation - Dispute Integration
SAP_COM_0639	Finance - Contract Accounting Collection Agency Integration
SAP_COM_0638	Finance - Contract Accounting External Cash Desk Integration
SAP_COM_0663	Finance - Contract Accounting Factoring Integration
SAP_COM_0696	Finance - Contract Accounting General Ledger Hub Integration
SAP_COM_0731	Finance - Contract Accounting Integration
SAP_COM_0511	Finance - Contract Accounting Integration for SAP Cash Application
SAP_COM_0167	Finance - Contract Accounting Master Data Integration
SAP_COM_0361	Finance - Contract Accounting Open Item Management Integration
SAP_COM_0716	Finance - Contract Accounting Promise to Pay Integration
SAP_COM_0380	Finance - Contract Accounting Security Deposits Integration
SAP_COM_0458	Finance - Contract Accounting SEPA Mandate Integration
SAP_COM_0579	Finance - Contract Accounting: Disconnection and Reconnection of Services
SAP_COM_0357	Finance - Cost Center Activity Type Integration
SAP_COM_0133	Finance - Cost Center Integration
SAP_COM_0173	Finance - Credit Management Integration
SAP_COM_0740	Finance - Credit Management Master Data Integration
SAP_COM_0B18	Finance - Currency Exchange Rates Integration
SAP_COM_0B17	Finance - Direct Debit Mandate Integration
SAP_COM_0705	Finance - EBRR Manual Accruals Integration
SAP_COM_0645	Finance - ELSTER Integration
SAP_COM_0543	Finance - EU VAT Registration Number Validation Integration
SAP_COM_0312	Finance - Event-Based Revenue Recognition Integration
SAP_COM_0563	Finance - Fixed Asset Integration
SAP_COM_0A93	Finance - Fixed Asset Master Data Integration
SAP_COM_0A95	Finance - Fixed Asset Posting Integration
SAP_COM_0A97	Finance - Fixed Asset Revaluation Index Integration
SAP_COM_0A96	Finance - Fixed Asset Usage Object for UoP Depreciation Integration
SAP_COM_0362	Finance - Freeze Period Integration
SAP_COM_0370	Finance - Group Reporting Planning Integration
SAP_COM_0248	Finance - Group Reporting Reported Financial Data Integration
SAP_COM_0377	Finance - Intercompany Matching Item Integration
SAP_COM_0125	Finance - Internal Order Integration
SAP_COM_0559	Finance - Master Data Integration for Cost Center Integration (Obsolete)
SAP_COM_0585	Finance - Master Data Service for Account Assignment Elements Integration
SAP_COM_0A62	Finance - Memo Records 2.0 Integration
SAP_COM_0654	Finance - One Time Password Integration
SAP_COM_0331	Finance - Payment Advice Integration
SAP_COM_0711	Finance - Payment Approval Integration
SAP_COM_0132	Finance - Payment Request Integration
SAP_COM_0002	Finance - Posting Integration
SAP_COM_0131	Finance - Profit Center Integration
SAP_COM_0368	Finance - Profit Center OData Integration
SAP_COM_0754	Finance - Reassign Costs and Revenues Integration
SAP_COM_0852	Finance - SAP SuccessFactors Payroll - Journal Entry Integration
SAP_COM_0844	Finance - Slovakia Bank Accounts Register Integration
SAP_COM_0130	Finance - Statistical Key Figure Integration
SAP_COM_0B07	Finance - Statistical Key Figure OData Integration
SAP_COM_0554	Finance - Third-party's Communication Client Integration
SAP_COM_0794	Finance - Transaction Data - Write - for Group Reporting Integration
SAP_COM_0923	Finance - Treasury Financial Transaction NPV Integration
SAP_COM_0A85	Finance - Treasury FX Exposure Management Integration
SAP_COM_0442	Finance - Treasury Payment Request Integration
SAP_COM_0332	Finance - Treasury Position Flow Integration
SAP_COM_0333	Finance - Treasury Posting Journal Integration
SAP_COM_0853	Finance – SAP SuccessFactors Payroll – UI Integration
SAP_COM_0580	Finance Employee Central Account Assignment Derivation Validation Integration
SAP_COM_0B00	Finance-Contract Accounting Accounts Receivable/Accounts Payable Integration
SAP_COM_0416	Financial Closing Integration
SAP_COM_0566	Financial Tasklist Integration
SAP_COM_0096	Financials - SAP Customer Engagement Center Integration
SAP_COM_0114	Foundation Master Data Integration
SAP_COM_0782	Goods Receipt Confirmation Integration
SAP_COM_0230	GRC - Process Control and Risk Management Integration
SAP_COM_0734	GRC - SAP Risk and Assurance Management Integration
SAP_COM_0391	GRC SAP Privacy Governance Integration
SAP_COM_0364	Handling Unit Integration
SAP_COM_0932	IC Configure - Variant Configuration Bundle Model Integration
SAP_COM_0093	Identity Management Integration
SAP_COM_0193	Identity Provisioning Integration
SAP_COM_0431	Image Based Ordering for S/4H Procurement ML Integration (Deprecated)
SAP_COM_0A42	Incident Management - OSHA Reporting Integration
SAP_COM_0546	Incoming China VAT Invoice Integration
SAP_COM_0110	Inspection Master Data Integration
SAP_COM_0810	Integration of Enterprise Contract Management - Connected System
SAP_COM_0446	Intelligent Accruals Recommendation Integration
SAP_COM_0718	Intelligent Product Proposal Integration
SAP_COM_0572	Intelligent Product Selection Consumption Integration
SAP_COM_0538	Intelligent Product Selection Integration
SAP_COM_0280	International Trade Content - Commodity Codes Integration
SAP_COM_0281	International Trade Content - Control Classes Integration
SAP_COM_0282	International Trade Content - Customs Tariff Numbers Integration
SAP_COM_0240	Invoice Process Integration
SAP_COM_0B08	Invoice Summary Output Integration
SAP_COM_1238	Invoice Summary Output Integration (Deprecated)
SAP_COM_0383	Joint Venture Accounting API Integration
SAP_COM_0381	Joint Venture Partner Billing Files Integration
SAP_COM_0882	Joule Integration
SAP_COM_0330	Kanban Control Cycle Integration
SAP_COM_0520	Kanban Summarized JIT Call Outbound Integration
SAP_COM_0540	Key Mapping Client Integration
SAP_COM_0539	Key Mapping Hub Integration
SAP_COM_0647	Launchpad Content Exposure to SAP BTP Integration
SAP_COM_0791	Legal Context Integration
SAP_COM_0178	Legal Document Integration
SAP_COM_0140	Legal Transaction Integration
SAP_COM_0396	Maintenance Planning Integration
SAP_COM_0397	Maintenance Processing Integration
SAP_COM_0B27	Manage External Tax Items Integration
SAP_COM_0765	Manage User-Defined Criteria Integration
SAP_COM_0667	Manufacturing - MRP Change Request Integration
SAP_COM_0522	Manufacturing Execution - Order and Confirmation Integration
SAP_COM_0156	Manufacturing Execution Integration
SAP_COM_0135	Marketing - Campaigns Integration (Obsolete)
SAP_COM_0371	Marketing - Event Inbound Integration
SAP_COM_1095	Marketing - Kubernetes Dialog Scaler Integration
SAP_COM_0022	Marketing - Reporting Integration
SAP_COM_0780	Master Data - Location Substitution Integration
SAP_COM_0708	Master Data - Product Exclusion Integration
SAP_COM_0779	Master Data - Product Substitution Control Integration
SAP_COM_0778	Master Data - Product Substitution Group Integration
SAP_COM_0707	Master Data - Product Substitution Integration
SAP_COM_0581	Master Data Service for Proj Control Object Integate (Deprecated)\| (Obsolete)
SAP_COM_0108	Material Document Integration
SAP_COM_0263	Material Document Outbound Notification Integration
SAP_COM_0147	Material Price Changes and Inventory Values Integration
SAP_COM_0164	Material Stock Integration
SAP_COM_0447	Material Stock Quantity Replication Integration
SAP_COM_0A79	MDG - Cloud Integration - Business Partner Pull Integration
SAP_COM_0477	Message Monitoring - Error Propagation Integration
SAP_COM_0569	Message Monitoring - Outbound Integration of Error Propagation
SAP_COM_0578	Message Monitoring - SAP Alert Notification service for SAP BTP - Integration
SAP_COM_0947	Migration Cockpit API Integration
SAP_COM_0816	Migration Cockpit Direct Transfer Integration
SAP_COM_0259	Migration Cockpit Integration
SAP_COM_0678	Migration Cockpit Integration
SAP_COM_0181	OData Metadata Integration
SAP_COM_0B06	Omnichannel Promotion Pricing Services Integration
SAP_COM_0046	Open Catalog Integration
SAP_COM_0007	OpenText Business Event Integration
SAP_COM_0577	Outgoing China VAT Invoice Integration
SAP_COM_0881	Output Management - Output Queue Integration
SAP_COM_0399	Packing Instruction Integration
SAP_COM_0896	Packing Instruction Replication with Ariba Network Integration
SAP_COM_0A38	Payables and Receivables Financing with Taulia
SAP_COM_0644	Photo Replication for Workforce Integration
SAP_COM_0107	Physical Inventory Document Integration
SAP_COM_0A15	Planon Real Estate Management for SAP UI Integration
SAP_COM_0398	Plant Maintenance Execution Integration
SAP_COM_0319	Plant Maintenance Master Data Integration
SAP_COM_0322	Plant Maintenance Notification Integration
SAP_COM_0344	Plant Maintenance Order Integration
SAP_COM_0814	Portugal Series Validation Code Registration Integration
SAP_COM_0257	Portuguese Tax Authority Integration
SAP_COM_0920	PRA Accounting Data Integration
SAP_COM_0815	PRA Funds Notification Integration
SAP_COM_0919	PRA Production Data Integration
SAP_COM_0921	PRA Valuation Data Integration
SAP_COM_0940	PRA Well Completion Daily Pressure Integration
SAP_COM_0939	PRA Well Completion Downtime Integration
SAP_COM_0938	PRA WellTest Integration
SAP_COM_0806	PRA XI Inbound Integration
SAP_COM_0373	Predictive Journal Entry Data Integration
SAP_COM_0739	Predictive MRP Masterdata Integration
SAP_COM_0911	Preferred Supplier List Integration (Deprecated)
SAP_COM_0953	Preliminary Billing Document Integration
SAP_COM_0861	Price Calculation - UI Integration
SAP_COM_0294	Pricing Data Integration
SAP_COM_0295	Pricing Data Replication Integration
SAP_COM_0467	Printing - Notification Integration
SAP_COM_0A86	Printing - Print Queue Administration Integration
SAP_COM_0466	Printing - Pull Integration
SAP_COM_0524	Procurement - Ariba Contract Management Integration
SAP_COM_0450	Procurement - Ariba Sourcing Integration
SAP_COM_0451	Procurement - External Sourcing Integration
SAP_COM_0324	Procurement - Operational Supplier Evaluation Score Integration
SAP_COM_0760	Procurement - Supplier Quotation Management Integration (Deprecated)
SAP_COM_0526	Procurement – Ariba Supplier Risk Integration
SAP_COM_0633	Procurement Central Sourcing - Ariba Sourcing Integration
SAP_COM_0116	Procurement Master Data Integration
SAP_COM_0152	Product Allocation Object Integration
SAP_COM_0161	Product Allocation Sequence Integration
SAP_COM_0792	Product Assignment to Distribution Center Integration
SAP_COM_0115	Product Availability Information Integration
SAP_COM_0309	Product Classification Integration
SAP_COM_0797	Product Compliance - Integration
SAP_COM_0666	Product Compliance - Integration of Third-Party Regulatory Content
SAP_COM_0772	Product Compliance - Label Template Authoring Integration
SAP_COM_0A60	Product Compliance - Logistics Inbound Integration
SAP_COM_0786	Product Compliance - Regulatory Documentation Reference Service Integration
SAP_COM_0514	Product Compliance - Regulatory Documentation Service Integration
SAP_COM_0748	Product Compliance - Substance Volume Tracking Integration
SAP_COM_0009	Product Integration
SAP_COM_0339	Product Lifecycle Management - Change Record Integration
SAP_COM_0150	Product Lifecycle Management - Core Master Data Integration
SAP_COM_0151	Product Lifecycle Management - Engineering Change Management IDOC Integration
SAP_COM_0937	Product Lifecycle Management - EPD Integration
SAP_COM_0290	Product Lifecycle Management - Intelligent Product Design BOM Integration
SAP_COM_0214	Product Lifecycle Management - Intelligent Product Design DMS Integration
SAP_COM_0215	Product Lifecycle Management - Intelligent Product Design EADesigner Integration
SAP_COM_0291	Product Lifecycle Management - Intelligent Product Design RD Integration
SAP_COM_0428	Product Lifecycle Management - IPD Collaboration Change Record Integration
SAP_COM_0105	Product Lifecycle Management - Master Data Integration
SAP_COM_0254	Product Lifecycle Management - ML for Document Classification Integration
SAP_COM_0866	Product Lifecycle Management - PLM System Inbound Integration
SAP_COM_0867	Product Lifecycle Management - PLM System Outbound Integration
SAP_COM_0136	Product Lifecycle Management - Recipe Development Integration
SAP_COM_0A47	Product Lifecycle Management - UI Integration
SAP_COM_0149	Product Lifecycle Management - Variant Configuration Integration
SAP_COM_0751	Product Lifecycle Management - Variant Configuration Integration
SAP_COM_0910	Product Sourcing Integration (Deprecated)
SAP_COM_0104	Production Planning Integration
SAP_COM_0519	Production Planning Master Data Integration
SAP_COM_0328	Production Supply Area Integration
SAP_COM_0704	Production Volume Management Integration (Deprecated)
SAP_COM_0909	Project Billing Integration
SAP_COM_0111	Project Control Integration
SAP_COM_0925	Project Demand Category and Type Integration
SAP_COM_0783	Project Demand Integration
SAP_COM_0926	Project Demand Status Integration
SAP_COM_0843	Project Management in SAP Project and Resource Management - UI Integration
SAP_COM_0A09	Protection Allowlists Read Integration
SAP_COM_0761	Public Sector API Integration
SAP_COM_0101	Purchase Contract Integration
SAP_COM_0A29	Purchase Order Accruals Review Integration
SAP_COM_0053	Purchase Order Integration
SAP_COM_0238	Purchase Order Process Integration
SAP_COM_0113	Purchase Request for Quotation Integration
SAP_COM_0102	Purchase Requisition Integration
SAP_COM_0239	Purchase Requisition Process Integration
SAP_COM_0103	Purchase Scheduling Agreement Integration
SAP_COM_0123	Purchasing Category Integration
SAP_COM_0145	Purchasing Info Record Integration
SAP_COM_0166	Purchasing Quota Arrangement Integration
SAP_COM_0162	Purchasing Source Integration
SAP_COM_0588	Quality Certificate Exchange Integration
SAP_COM_0389	Quality Certificate Inbound Integration
SAP_COM_0358	Quality Info Record Integration
SAP_COM_0124	Quality Inspection Process (with BAPI) Integration
SAP_COM_0318	Quality Inspection Process Integration
SAP_COM_0153	Quality Notification and Defect Processing Integration
SAP_COM_0915	Read Access Log Integration
YY1_READWORKFORCEPERSON	Read workforce person
SAP_COM_0402	Remote Function Call - RFC Inbound Test Integration
SAP_COM_0636	Remote Function Call - RFC Metadata Integration
SAP_COM_0403	Remote Function Call - RFC Outbound Test Integration
SAP_COM_0404	Remote Function Call - WebSocket RFC Inbound Test Integration
SAP_COM_0405	Remote Function Call - Websocket RFC Outbound Test Integration
SAP_COM_0902	Renegotiation Integration
SAP_COM_0112	Reservation Integration
SAP_COM_0928	Resource Assignment Source for Project Demands Integration
SAP_COM_0A11	Resource Management in SAP Project and Resource Management - API Integration
SAP_COM_0840	Resource Management in SAP Project and Resource Management - UI Integration
SAP_COM_0560	Responsibility Management Team Integration
SAP_COM_0640	Retail Merchandise Management - Point of sale Master data Integration
SAP_COM_0652	Retail Merchandise Management - Point Of Sale Transaction Data Integration
SAP_COM_0795	Returns Inspection OData v4 Integration
SAP_COM_0701	Revenue Accounting Integration
YY1_RM_SCENARIO	RM api call
SAP_COM_0A33	S/4H Document and Reporting Compliance - SAP CIM Integration
SAP_COM_0228	S/4HANA Activate New Features - Innovation Discovery System Integration
SAP_COM_0837	S/4HANA QM/NCM - Quality Issue Resolution Integration
SAP_COM_0641	Sales - Document Information Extraction Service Integration
SAP_COM_0427	Sales Area Replication Integration
SAP_COM_0A10	Sales Contract Bulk Replication Integration
SAP_COM_0119	Sales Contract Integration
SAP_COM_0325	Sales Credit Management Integration
SAP_COM_0829	Sales Credit Management Outbound Integration
SAP_COM_0117	Sales Inquiry Integration
SAP_COM_0746	Sales Master Data Integration
SAP_COM_0B03	Sales Material Determination Record Integration
SAP_COM_0288	Sales Order Bulk Integration
SAP_COM_0287	Sales Order Bulk Replication Integration
SAP_COM_0109	Sales Order Integration
SAP_COM_0334	Sales Order Without Charge Integration
SAP_COM_0702	Sales Price Integration
SAP_COM_0A12	Sales Quotation Bulk Replication Integration
SAP_COM_0118	Sales Quotation Integration
SAP_COM_0382	Sales Scheduling Agreements Consignment Issue Integration
SAP_COM_0360	Sales Scheduling Agreements Integration
SAP_COM_0444	Sales Scheduling Agreements With Buyers Integration
SAP_COM_0223	Sales with Buyers Integration
SAP_COM_0848	Sales with SAP Business Network Integration
SAP_COM_0A69	SAP AI Core - GenAI - Customer Outbound Integration
SAP_COM_0443	SAP Analytics Cloud for Liquidity Planning Integration
SAP_COM_0087	SAP Analytics Cloud for Planning Integration
SAP_COM_0065	SAP Analytics Cloud Integration
SAP_COM_0545	SAP Ariba Buying Integration
SAP_COM_0A00	SAP Ariba Buying UI Integration
SAP_COM_0574	SAP BTP Connectivity Service - On Premise Integration
SAP_COM_0A34	SAP Build - Extensibility Integration
SAP_COM_0A61	SAP Build Process Automation - Master Data Governance Process Integration
SAP_COM_0743	SAP Business Accelerator Hub - Open Resource Discovery Integration
SAP_COM_0A84	SAP Business Network - Supplier Search UI Integration
SAP_COM_0042	SAP Business Warehouse Integration
SAP_COM_0A20	SAP Cash Application for ISLM Integration
SAP_COM_0650	SAP Cash Application Integration
SAP_COM_0897	SAP Central Invoice Management - UI Integration
SAP_COM_0690	SAP Cloud ALM - Change and Deployment Management Integration
SAP_COM_0527	SAP Cloud ALM for operations - Application Monitoring Push Integration
SAP_COM_0A43	SAP Cloud Application Event Hub - UI Integration
SAP_COM_0892	SAP Cloud Application Event Hub Integration
SAP_COM_0200	SAP Cloud Connector Integration (Obsolete)
SAP_COM_0838	SAP Cloud for Real Estate - UI Integration
SAP_COM_0213	SAP Cloud for Real Estate Contract Management Integration
SAP_COM_0066	SAP Cloud Identity Access Governance Integration
SAP_COM_0180	SAP Cloud Platform - Financials Integration
SAP_COM_0434	SAP Cloud Platform ABAP Environment - CRP Usage Integration
SAP_COM_0510	SAP Cloud Platform ABAP Environment - Software Component Test Integration
SAP_COM_0235	SAP Cloud Platform Business Rules - Inbound Integration
SAP_COM_0236	SAP Cloud Platform Business Rules - Outbound Integration
SAP_COM_0528	SAP Cloud Platform Master Data for Workforce Integration(obsolete)
SAP_COM_0575	SAP Cloud Platform Master Data Service for Workforce Integration (Obsolete)
SAP_COM_0835	SAP Collaboration Manager Integration
SAP_COM_0676	SAP Conversational AI Integration
SAP_COM_0683	SAP CP Notification Service Integration
SAP_COM_0576	SAP Data Intelligence - Metadata Explorer Integration
SAP_COM_0531	SAP Datasphere - ABAP CDS Extraction - OData Integration (Deprecated)
SAP_COM_0532	SAP Datasphere - ABAP CDS Extraction - WebSocket Integration
SAP_COM_0216	SAP Digital Payments Add-On Integration
SAP_COM_0653	SAP Digital Payments Add-On Integration
SAP_COM_0A67	SAP Document AI - UI Integration
SAP_COM_0597	SAP Document Management Service - Attachments Integration
SAP_COM_0194	SAP Document Management Service - Notification Inbound Integration
SAP_COM_0191	SAP Document Management Service - OAuth2.0 mTLS Outbound Integration
SAP_COM_0668	SAP Document Management Service - Outbound Integration
SAP_COM_0190	SAP Document Management Service - SAML Bearer Outbound Integration
SAP_COM_0A66	SAP Dynamic Forms Integration
SAP_COM_0011	SAP Enable Now Integration
SAP_COM_0B10	SAP FSM - Plant Maintenance - CPI Based Integration
SAP_COM_0B12	SAP FSM - Plant Maintenance - Direct Integration (P2P)
SAP_COM_0084	SAP Global Trade Services Integration
SAP_COM_0246	SAP GR/IR Account Reconciliation Status Proposals Integration (Obsolete)
SAP_COM_0A98	SAP Green Ledger - UI Integration
SAP_COM_0573	SAP HANA Spatial Services Integration
SAP_COM_0492	SAP Integration Suite, Advanced Event Mesh Integration
SAP_COM_0493	SAP Integration Suite, Advanced Event Mesh Integration, Validation Service
SAP_COM_0275	SAP Localization Hub - eDocuments - DCS Integration
SAP_COM_0047	SAP Localization Hub - eDocuments Integration
SAP_COM_0249	SAP Localization Hub - External Tax Calculation Engine Integration
SAP_COM_0549	SAP Maintenance Assistant Integration
SAP_COM_0841	SAP Market Rates Management - UI Integration
SAP_COM_0659	SAP Master Data Integration - Outbound Integration
SAP_COM_0060	SAP Order Management Integration
SAP_COM_0863	SAP Process Automation Integration
SAP_COM_0A63	SAP Real Estate - Finance Interface Integration
SAP_COM_0393	SAP Real Estate Contract API Integration
SAP_COM_0918	SAP Real Estate Master Data Event Integration
SAP_COM_0697	SAP Real Estate Master Data Integration
SAP_COM_0657	SAP Remittance Advices Integration
SAP_COM_0098	SAP S/4 HANA Extensibility Cockpit – Best Practices Explorer Integration
SAP_COM_0793	SAP S/4HANA Cloud for Credit Integration - Data Integration
SAP_COM_0826	SAP S/4HANA Cloud for Credit Integration - UI Integration
SAP_COM_0076	SAP S/4HANA Finance Cloud for Customer Payments Integration
SAP_COM_0887	SAP S/4HANA for Microsoft Teams - Contact Integration
SAP_COM_0A17	SAP S/4HANA for Microsoft Teams - Situation Notification Integration
SAP_COM_0A32	SAP S/4HANA for Microsoft Teams - Task Notification Integration
SAP_COM_0860	SAP S/4HANA for Microsoft Teams - UI Integration
SAP_COM_0930	SAP S/4HANA Migration Cockpit - Data Migration to BTP Integration
SAP_COM_0525	SAP S/4HANA Procurement Hub - Ariba Central Contract Management Integration
SAP_COM_0292	SAP S/4HANA Procurement Hub - Ariba GB - Hub to Ariba GB Integration
SAP_COM_0293	SAP S/4HANA Procurement Hub - Ariba GB - Hub to Subsidiary Integration
SAP_COM_0420	SAP S/4HANA Procurement Hub - Ariba GB - Subsidiary to Hub Integration
SAP_COM_0243	SAP S/4HANA Procurement Hub - Central Contract Management Integration
SAP_COM_0515	SAP S/4HANA Procurement Hub - Central Invoice Hub Integration (Obsolete)
SAP_COM_0516	SAP S/4HANA Procurement Hub - Central Invoice Satellite Integration
SAP_COM_0266	SAP S/4HANA Procurement Hub - Central Purchasing Inbound Integration
SAP_COM_0267	SAP S/4HANA Procurement Hub - Central Purchasing Outbound Integration.
SAP_COM_0736	SAP S/4HANA Procurement Hub - Central Request For Quotation Integration
SAP_COM_0512	SAP S/4HANA Procurement Hub - Central Sourcing Hub Integration
SAP_COM_0513	SAP S/4HANA Procurement Hub - Central Sourcing Satellite Integration
SAP_COM_0737	SAP S/4HANA Procurement Hub - Central Supplier Quotation Integration
SAP_COM_0673	SAP S/4HANA Procurement Hub - Centrally Managed PO with Supplier Integration
SAP_COM_0587	SAP S/4HANA Procurement Hub - Foundation Layer Hub Integration
SAP_COM_0586	SAP S/4HANA Procurement Hub - Foundation Layer Satellite Integration
SAP_COM_0090	SAP S/4HANA Procurement Hub Integration
SAP_COM_0672	SAP S/4HANA Procurement Hub-Central Purchase Contract with Supplier Integration
SAP_COM_0564	SAP Self-Billing Cockpit Integration
SAP_COM_0642	SAP Subscription Billing - API Integration
SAP_COM_0884	SAP Subscription Billing - Event Consumption Integration
SAP_COM_0845	SAP Subscription Billing - UI Integration
SAP_COM_0095	SAP Subscription Billing with Sales Billing Integration
SAP_COM_0686	SAP SuccessFactors Employee Central - UI Integration
SAP_COM_0A76	SAP Task Center - Task Consumption Integration
SAP_COM_0501	SAP Task Center Integration
SAP_COM_0922	SAP Treasury Management - Financial Transaction Integration
SAP_COM_0B26	SAP Treasury Management - Financial Transaction Integration
SAP_COM_0839	SAP Treasury Management - SAP Trading Platform Integration
SAP_COM_0226	SAP Treasury Management - SAP Trading Platform Integration (Deprecated)
SAP_COM_0954	SAP Treasury Management - Securities Master Data Integration
SAP_COM_0203	SAP Treasury Market Rate Integration
SAP_COM_0222	SAP Watch List Screening - Screening Hits Integration
SAP_COM_0219	SAP Watch List Screening - Screening Integration
SAP_COM_0013	SAP Web IDE Integration (Obsolete)
SAP_COM_0637	SAP Workflow Management Process Visibility Capability Integration
SAP_COM_0542	SAP Workflow Management Workflow Capability Integration
SAP_COM_0750	Security Audit Log Integration
SAP_COM_0961	Serial Number Management Integration
SAP_COM_0802	Service - Field Service Management UI Integration
SAP_COM_0717	Service - In-House Repair OData Integration
SAP_COM_0764	Service - Master Data Integration
SAP_COM_0933	Service - Repair Confirmation Integration
SAP_COM_0858	Service - Repair Confirmation SOAP Integration
SAP_COM_0742	Service - Repair Order Integration
SAP_COM_0677	Service - Repair Order SOAP Integration
SAP_COM_0744	Service - Repair Quotation Integration
SAP_COM_0687	Service - SAP Field Service Management - Direct Integration (P2P)
SAP_COM_0A50	Service - SAP FSM -CPI Based Integration
SAP_COM_0352	Service Confirmation OData Integration
SAP_COM_0423	Service Confirmation SOAP Integration
SAP_COM_0558	Service Contract OData Integration
SAP_COM_0789	Service Contract OData V4 Integration
SAP_COM_0436	Service Contract SOAP Integration
SAP_COM_0788	Service Contract Template Integration
SAP_COM_0A92	Service Document Settlement Rules Integration
SAP_COM_0146	Service Entry Sheet Integration
SAP_COM_0237	Service Entry Sheet Process Integration
SAP_COM_0350	Service Order OData Integration
SAP_COM_0424	Service Order SOAP Integration
SAP_COM_0715	Service Order Template Integration
SAP_COM_0355	Service Quotation Integration
SAP_COM_0530	Service Quotation Integration
SAP_COM_0831	SLT - CDS View Extraction Integration
SAP_COM_0026	Social Collaboration Integration
SAP_COM_0582	Software Assembly Integration
SAP_COM_0948	Software Component Management Integration
SAP_COM_0367	Sold-to Party Assignment of Sales Scheduling Agreement Integration
SAP_COM_0445	Sourcing and Procurement Scheduling Agreements With Suppliers Integration
SAP_COM_0224	Sourcing and Procurement with Suppliers Integration
SAP_COM_0A80	Stock Transport Order Integration
SAP_COM_0700	SuccessFactors Payment Options Check Integration
SAP_COM_0137	Supplier Activity Integration
SAP_COM_0138	Supplier Activity Task Integration
SAP_COM_0904	Supplier Confirmation Integration
SAP_COM_0827	Supplier Confirmation Process Integration
SAP_COM_0828	Supplier Confirmation Third-party Integration
SAP_COM_0139	Supplier Evaluation Response Integration
SAP_COM_0122	Supplier Evaluation Scorecard Integration
SAP_COM_0057	Supplier Invoice Integration
SAP_COM_0384	Supply Availability Protection Plan Integration
SAP_COM_0347	Support User Request Log Read Integration
SAP_COM_0664	Sustainability - Product Footprint Management Integration
SAP_COM_0883	Sustainability Data Exchange Integration
SAP_COM_0465	System for Cross-domain Identity Management Integration
YY1_TASK_CENTER_TEST	Task Center Test
SAP_COM_0620	Test Automation - Cloud ALM Integration
YY1_TESTCOMMUSER	Test for CFO Dashboard
SAP_COM_0253	Text Analysis - Purchasing (Deprecated)
SAP_COM_0850	Transportation Management - Advanced Shipping Notification Integration
SAP_COM_0756	Transportation Management - Freight Agreement Integration
SAP_COM_0906	Transportation Management - Freight Booking Integration
SAP_COM_0905	Transportation Management - Freight Order Integration
SAP_COM_0908	Transportation Management - Freight Unit Integration
SAP_COM_0813	Transportation Management - LSP Freight Booking Integration
SAP_COM_0534	Transportation Management - LSP Freight Order Integration
SAP_COM_0414	Transportation Management - Order-Based Transportation Consolidation Integration
SAP_COM_0767	Transportation Management - Rate Table Integration
SAP_COM_0660	UI Text Translation Adaptation Integration
SAP_COM_0086	UI Theme Designer Integration
SAP_COM_0623	UI Theme Designer Integration
SAP_COM_0929	Update Source for Project Demands Integration
SAP_COM_0537	Variant Configuration and Pricing Integration
SAP_COM_0323	Visual Business - GeoJSON Inbound Integration
SAP_COM_0A78	WalkMe Digital Adoption Platform - Outbound Integration
SAP_COM_0A65	Warehouse Management Control Cycle Integration
SAP_COM_0386	Warehousing - Attachment Service Integration
SAP_COM_0875	Warehousing - ERP Integration
SAP_COM_0385	Warehousing - Inbound Delivery Integration
SAP_COM_0374	Warehousing - Master Data Integration
SAP_COM_0378	Warehousing - Physical Inventory Integration
SAP_COM_0356	Warehousing - Process Outbound Delivery Order Integration
SAP_COM_0353	Warehousing - Process Warehouse Task Integration
SAP_COM_0755	Warehousing - Stock Integration
SAP_COM_0766	Warranty Claim Management Integration
SAP_COM_0632	Web Dynpro ABAP ALV for PDF Signing Integration (SAP_COM_0632)
SAP_COM_0914	Workforce Availability Integration
SAP_COM_0A35	Workforce Person OData Integration
SAP_COM_0027	Workforce Timesheet Integration
SAP_COM_0242	WSIL Integration

Communication Arrangements in SAP S/4 HANA Public Cloud

2026-02-24T07:04:51.057000+01:00

Communication Arrangements

Communication Arrangements is one of the Key User Extensibility Tools.

With Communication Arrangements App,

Communication Arrangements details can be viewed.
Custom Communication Arrangements can be created with standard communication or custom communication scenarios using Communication Arrangements App.

Finding the Standard Communication Scenarios in SAP Business Accelerator Hub

Navigate to SAP Business Accelerator Hub

Choose the Product

SAP S/4 HANA Cloud Public Edition

Navigate to APIs -> ODATA V2 / ODATA V4.

Search Required API

List of results for Purchase Order.

Purchase Order API Overview

API Resources

Navigate to API Resources -> Attributes -> Communication Scenario

API Specifications

Authentication Methods for API

Configuration Details for API

Extensibility

Custom Fields can be added to the API using below Business Contexts - Header and Items in Custom Fields App with Key User Extensibility.

API Reference

List of Entity Sets Available in the APIs.

Communication Scenarios

Navigate to Display Communication Scenarios,

All these are Standard Communication Scenarios.

Standard Communication Scenarios of Purchase Order - SAP_COM_0053

Steps to Create Communication Arrangements

Maintain Communication Users

Navigate to Maintain Communication Users App.

Maintain Communication Users is to create Communication Users for the API Access.

Choose New button to create Communication User

Add User Name and Password.

Propose Password can be chosen to generate password by system.

Save the Communication User.

If communication User is added to any Communication system or communication Arrangements, here it shows those details.

Communication System

Navigate to Communication System App.

Communication System is to maintain communication system with host name and communication User.

Provide Communication System ID and Name.

Add the Host Name

Add necessary details

Choose Add button to add Inbound Communication User.

Available Authentication Methods

Required details for SSL Client Certificate.

Required details for OAuth 2.0

Choose the Authentication Method, and choose User Name/Client ID.

Click on Ok after choosing Communication User.

Communication User is added.

Communication System is saved.

Communication Arrangements

Navigate to Communication Arrangements app.

Communication Arrangements is to generate Inbound Service URLs by adding Communication System and Communication User.

Choose New Option to create Custom Communication Arrangements.

Standard or Custom Communication Scenarios is required to create Custom Communication Arrangements.

Search for the Standard or Custom Communication Scenario

‘SAP_COM_0053’ is the Standard Communication Scenario for the Purchase Order API.

Arrangement appears automatically based on Communication Scenario and it can be changed.

Click on Create button to create Communication Arrangement.

List of Inbound Services available for that Communication Scenario.

WSDL/Service Metadata will be generated once Saved the Communication Arrangement.

Communication System and Communication User is required to create Communication Arrangements.

WSDL/Service Metadata is generated.

Service Metadata

Service URL is available in Communication Arrangement.

Access the Service URLs through the Communication User details.

Conclusion

standard communication or custom communication scenarios are used to create Communication Arrangements.

In Communication Arrangements, OData URLs are generated based on inbound Service.

References

On-Stack Partner Reference App: A Guide to Clean-Core Extensions in SAP S/4HANA Cloud Public Edition

2026-03-02T14:06:51.614000+01:00

As SAP partners and customers continue to innovate in the SAP cloud ERP space, one principle remains non-negotiable: keep the core clean. While SAP’s extensibility guidelines often favor side-by-side builds on the SAP Business Technology Platform (SAP BTP), some scenarios require tighter, real-time integration with core processes. For these tightly coupled cases, on-stack extensibility within SAP S/4HANA Cloud Public Edition provides the essential solution. It offers a powerful way to enhance standard business processes—without modifying SAP-delivered code—enabling end users to innovate securely and at scale.

To bridge theory and practice, the On-Stack Partner Reference Application provides a practical blueprint for building these clean-core extensions. Using modern ABAP and RAP principles, it demonstrates how to extend standard SAP applications in a secure, upgrade-stable, and scalable way, fully aligned with SAP guidelines.

When to Choose On-Stack Extensibility

While a side-by-side architecture on SAP Business Technology Platform is a powerful approach, it isn’t the ideal fit for every business need. Sometimes, an extension must be tightly woven into the main system to deliver the best results. On-stack extensibility is the recommended path for these tightly coupled scenarios, especially when your solution requires:

Deep integration with standard business processes
Seamless navigation across SAP Fiori applications
A harmonized user experience
Enhancements that are upgrade-safe within the same system

On-stack extensibility allows developers and organizations to achieve these goals by building directly within the SAP S/4HANA Cloud stack. This approach preserves the clean-core architecture, ensuring the system remains stable and maintainable. The Partner Reference Application demonstrates the recommended “golden path” for achieving this perfect balance.

The Reference Scenario: Loyalty Hub

When on-stack extensibility is the right approach, the On-Stack Partner Reference Application provides a hands-on example that demonstrates how to extend standard SAP processes securely and efficiently. It goes beyond theory to present a full end-to-end scenario that partners can explore, adapt, and use as a practical blueprint.

The scenario uses a Loyalty Hub application integrated with the standard Manage Sales Orders – Version 2 SAP Fiori application. Its goal is to help organizations manage customer loyalty programs directly within sales operations, while preserving seamless navigation between standard SAP functionality and the custom extension.

To make the scenario concrete, we demonstrate the application using two personas:

Aarti, the loyalty administrator, manages memberships, awards loyalty points, and issues gift cards
Julia, the sold-to party or customer, earns points, redeems rewards, and applies gift cards during sales transactions

This approach highlights both administrative and customer perspectives, showing how Loyalty Hub supports real-world workflows and interactions. Here’s how the Loyalty Hub works from both the administrative and customer perspectives:

Key Capabilities

The application delivers comprehensive loyalty management:

Handles memberships, tiers, and related transactions
Tracks and awards loyalty points automatically in response to sales order events
Issues and redeems gift cards tied to customer orders
Sends automated notifications for points updates and tier changes
Supports both administrator workflows and end-user interactions

Technical and Operational Design

Built with ABAP RAP and custom business objects in the Z namespace
Data modeled using CDS, ensuring separation from standard SAP objects and upgrade stability
User interfaces designed with SAP Fiori elements, supporting flexible extensions and semantic navigation
SAP-standard authentication and role-based authorization for secure access
Operational readiness includes scheduled jobs for membership evaluation, number range handling for controlled object creation, and application logging/messaging for monitoring and troubleshooting

This scenario illustrates how partners can innovate within the SAP S/4HANA Cloud stack, extending functionality while preserving clean-core principles, upgrade safety, and a consistent SAP user experience — all while reflecting both administrative and customer perspectives.

Key Business Value

The reference application helps your organization accelerate development while staying fully compliant with clean-core principles. By using it as a guide, your teams can:

Gain a reference architecture aligned with SAP standards.
Use proven patterns to integrate with standard applications.
Learn to build reusable and deployable solutions.
Accelerate the delivery of robust and upgrade-safe extensions.

The Loyalty Hub demonstrates that innovation and compliance can coexist—adding real business value without compromising the SAP clean core. The best way to understand the power of this approach is to see it in action.

You can get started and try the Loyalty Hub example by accessing the complete reference application on GitHub. By following this framework, you can confidently deliver the innovative, compliant, and upgrade-safe solutions your business requires.

On Stack Partner Reference Extension for SAP S/4HANA Cloud Public Edition

Explore Other Reference Applications

Depending on your extensibility strategy, you can also explore:

Together, these resources guide developers and architects across on-stack, side-by-side, and cross-stack extension patterns—helping them choose the right architecture while staying aligned with SAP’s clean-core and cloud-first principles.

Part 1: Introduction & Overview	Link
Part 2: Integration of Employees from SAP SuccessFactors	Link
Part 3: Integration of Business Partners & Material from SAP Master Data Governance (MDG)	Link
Part 4: Integration of Functional Locations & Equipment from SAP S/4HANA On-Premise System	Link
Part 5: Extensibility Scenarios & Further Implementation	Link
Part 6: Summary & Outlook	Link