SAP Community - SAP S/4HANA Public Cloud

Conditions Not Saved After First Entry in Purchase Contract

2026-04-10T08:18:06.702000+02:00

In this blog post, I would like to share an issue we encountered in SAP S/4HANA Public Cloud where where pricing conditions are not saved after being entered for the first time in a purchase contract in the App Manage Purchase Contracts. This may help others facing similar inconsistencies in condition handling.

Issue:

In one of our test scenarios, condition DRV1 was maintained in a purchase contract.

The steps were as follows:

Open the purchase contract in Manage Purchase Contracts.
Navigate to the conditions section.
Enter condition DRV1.
Save the contract.

At first glance, everything seemed fine — no error messages were shown during the save process.
However, when checking the Purchase Contract Output, the condition was not printed here. And when reopening the purchase contract afterward, the condition DRV1 was no longer visible and appeared to be missing entirely.

Interestingly, when the same condition DRV1 was entered a second time, followed by saving the contract again, the condition is then stored correctly and remains visible when reopening the document.

Analysis:

At first, this behavior looked like a system defect or an issue with condition determination to us. Since there are no error messages and the save action completes successfully, the expectation was that the condition data has been stored.

However, the fact that the condition was only saved after re-entering it a second time suggests that the system never actually registered the initial input as confirmed data.

Root Cause:

The root cause of the issue is missing confirmation of the condition entry. SAP Support confirmed that the system was showing its' expected behaviour here.

When maintaining conditions, the entered condition must be explicitly confirmed by pressing Enter.
If the user enters the condition and immediately saves the document without pressing Enter, the system does not fully recognize the condition line as final input — even though it appears on the screen.

As a result, the condition is not transferred to the document data and is therefore not persisted during save.

Solution:

To ensure that conditions are saved correctly:

✅Confirm the condition with the Enter key before saving.

Once the condition has been confirmed with Enter, it will be saved correctly and will remain visible when the contract is reopened and will also be printed on the generated output.

Summary:

If you encounter situations where conditions or other values appear to be “lost” after saving, always check whether the input was properly confirmed beforehand by using the Enter key before saving.

Your Sherlock Homes – How to Segregate Configuration from Releasing Transports

2026-04-10T21:25:51.770000+02:00

Co-Author: Lisa Kouch

Introduction

Recently I got a question from a customer: In the SAP S/4HANA Cloud Public Edition, we usually give BPC Expert business role to a user who does the CBC and system configurations. However, to segregate the responsibility, we don’t want that configuration user to be able to release transports; we want to add a layer of control for the internal control purpose. Only the transport releaser can release a transport. How can I achieve this?

If the purpose of this responsibility lies in the approval and documentation purpose (aka process control), my blog Using SAP CALM Features App to Track Transports in the SAP S/4HANA Cloud Public Edition should serve the purpose. However, if you want to know the details on controlling this responsibility in the system, this blog discusses the segregation of configurations from releasing transports.

Check Out the Business Catalogs

If you are not familiar with the user management concept in the SAP S/4HANA Cloud Public Edition, please refer to my blog User Management in a Nutshell for the SAP S/4HANA Cloud, public edition.

As always, my first step of research is the infamous SAP Fiori Apps Reference Library. Since I want to control who can release the configuration transports, let me check out the app Export Customizing Transports. By selecting the IMPLEMENTATION INFORMATION tab, then expanding the Configuration section, we can find the important information as below:

Access Control of App Export Customizing Transports

There are three Business Catalogs control the access (disregard two deprecated ones):

SAP_CORE_BC_BCT_TRN_DSP_PC for Transport Display
SAP_CORE_BC_BCT_TRN_MNG_PC for Transport Management
SAP_CORE_BC_BCT_TRN_REL_PC for Transport Release Management

My idea is to only give the Configurator the Business Catalogs SAP_CORE_BC_BCT_TRN_DSP_PC and SAP_CORE_BC_BCT_TRN_MNG_PC so that he/she cannot release the transports. If you take out the SAP_CORE_BC_BCT_TRN_MNG_PC, the configurator cannot create a transport which is not what we want.

Next, I found out two Business Roles might contain these three business catalogs:

SAP_BR_ADMINISTRATOR
SAP_BR_BPC_EXPERT

To verify my idea, I need to get into the system to check the Business Role derived from the template SAP_BR_BPC_EXPERT. In my case, it is the Z_BR_BPC_EXPERT. All Three transport related business catalogs are there.

Three Transport Related Business Catalogs in the Business Role Z_BR_BPC_EXPERT

Testing

When all three business catalogs were assigned to the business role Z_BR_BPC_EXPERT, I created a dummy (empty) configuration transport. Then I take out the business catalog SAP_CORE_BC_BCT_TRN_REL_PC. When opening the app Export Customizing Transports, the Release button is grayed out. Therefore, I achieved the objective: the configuration user can view but cannot release the transport. Furthermore, since the business catalog SAP_CORE_BC_BCT_TRN_MNG_PC is assigned, the user can still manage the transport, such as creating a transport, assigning a transport to him/herself, delete a transport, etc.

Without Business Catalog SAP_CORE_BC_BCT_TRN_REL_PC, the User Cannot Release a Transport

Recommendations

To handle the situation described in this blog, I recommend using an adapted business role from an SAP template. You can add or remove necessary business catalogs as needed. For the transport releaser, you won’t give him/her the BPC Expert business role. You can create a new role with very limited business catalog such as the SAP_CORE_BC_BCT_TRN_REL_PC and assign to him/her. For the configurator, you should remove the business catalog SAP_CORE_BC_BCT_TRN_REL_PC from any business roles assigned to him/her. In particular, we know that the business role derived from the SAP Template SAP_BR_ADMINISTRATOR includes the business catalog SAP_CORE_BC_BCT_TRN_REL_PC as shown below. Therefore, don’t give the system configurator the administration business role. Just be thorough when doing your investigation.

Two Transports Related Business Catalogs in the SAP Template SAP_BR_ADMINISTRATOR

Conclusion

By removing one business catalog SAP_CORE_BC_BCT_TRN_REL_PC usually assigned to the configurators as a BPC Expert, you can segregate the configuration from transport releases.

References

Changing the Fiscal Year Variant in SAP S/4HANA Cloud, Public Edition

2026-04-13T04:28:49.070000+02:00

What You Need to Know Before Requesting a Fiscal Period Variant Change

Changing the fiscal year definition in a productive SAP S/4HANA Cloud, public edition system is a rare but critical requirement—typically driven by major business events such as company sales, mergers, demergers, or acquisitions.

This blog post explains why fiscal year variant changes are complex, what scenarios are supported, and how customers can proceed safely and compliantly using SAP’s recommended approach.

Business Context: Why Companies Need to Change Their Fiscal Year Variant

Customers usually request a fiscal year or fiscal period change when new business conditions arise, for example:

Sale of a company or business unit
Merger or acquisition
Division or carve‑out of an existing entity
Alignment with a new group reporting calendar

These changes often impact how financial reporting periods are structured—and therefore require changes to the fiscal year variant.

Common Scenarios

Introducing a Shortened Fiscal Year

A typical example is a transition from a calendar fiscal year (January–December) to a non‑calendar fiscal year (July–June).

In this case:

The old fiscal year ends in December
The new fiscal year starts in July
A shortened fiscal year is required to bridge the period January–June

This avoids gaps or overlaps in financial reporting.

Changing Fiscal Posting Period Definitions

Another common requirement is changing posting period structures, for example:

From calendar months to a 4‑4‑5 calendar
Or to 13 posting periods based on four‑week cycles

Although the fiscal year start/end dates may remain the same, the fiscal period definition must be adjusted accordingly.

Why Fiscal Year Variants Cannot Be Changed Directly in Production

In SAP S/4HANA Cloud, public edition, it is not possible to change the fiscal year variant retrospectively in a productive system.

The key reasons are:

🔹Data Integrity and Dependencies

Fiscal year information is deeply embedded in financial data such as:

Journal entries
Actuals and planning data
Universal Journal tables (for example, ACDOCA, ACDOCP)

Changing the fiscal year definition directly would risk inconsistencies in existing transaction data.

🔹Cross‑Application Impact

The fiscal year variant is used across multiple application areas:

General Ledger Accounting
Asset Accounting
Controlling
Reporting

Any change affects the entire financial landscape, not just one configuration object.

🔹Customer‑Specific Complexity

Each customer has a unique setup:

Ledger assignments
Reporting requirements
Audit constraints

This makes a standardized, self‑service change technically and operationally infeasible.

The Supported Approach: SAP DMLT Consulting Service

For SAP S/4HANA Cloud, public edition, changing the fiscal year definition or fiscal period structure requires a customer‑specific DMLT (Data Management & Landscape Transformation) consulting Service.

The consulting service typically includes:

Impact analysis
Configuration of the new fiscal year variant
Data conversion where required
Support for customer‑specific execution steps
Coordination with audit and compliance requirements

This applies whether you:

Introduce a shortened fiscal year, or
Change only the fiscal period (posting period) definition

Important Scope and Restrictions

Please consider the following constraints when planning:

✅Only one single fiscal year variant assigned across all ledgers and company codes can be changed
✅Supported only for SAP Central Business Configuration–managed implementations
✅The change impacts future data only
❌Historical transaction data is out of scope

Technical Note

If a preconfigured fiscal year variant was used during the initial implementation:

A new customer‑specific fiscal year variant ID must be created
All data containing the old variant ID (for example, line items in ACDOCA) must be converted as part of the project

How to Request the Change

To initiate the process:

Plan early and ensure sufficient lead time
Align with internal stakeholders and your auditor
Create a case under component CA‑LT‑SRV‑2CL
Engage with SAP DMLT Consulting Service to define scope, timeline, and execution strategy

Early engagement significantly reduces risk and helps ensure a smooth transition.

Key Takeaways

Changing a fiscal year in SAP S/4HANA Cloud is not a configuration activity, but a controlled transformation
Shortened fiscal years and fiscal period changes are fully supported—with expert guidance
Early planning, audit alignment, and SAP DMLT involvement are critical for success
3678328 - Change of Fiscal Year Variant in S/4HANA Cloud Public Edition

If you have gone through a fiscal year change in SAP S/4HANA Cloud or are planning one, feel free to share your experience or questions in the comments. Collaboration and shared learnings make these complex topics easier for everyone.

Preserving Critical Supplier Information: Transferring of Supplier Material Number (IDNLF)

2026-04-13T08:00:00.019000+02:00

Preserving Critical Supplier Information:

Why Transferring the Supplier Material Number (IDNLF) from Purchase Requisition to Purchase Order Matters

In SAP S/4HANA Public Cloud, procurement processes are designed to be efficient, guided, and seamlessly integrated. From purchase requisition creation to purchase order execution, data consistency is key to ensuring smooth operational flows.

However, in everyday procurement scenarios, even small gaps in data transfer can lead to unnecessary effort, loss of information, and reduced user confidence. One such gap exists today in the handling of the Supplier Material Number (IDNLF) during the transition from Purchase Requisition (PR) to Purchase Order (PO).

________________________________________________________________________________________________________

The Business Scenario: A Common, Real‑World Process

Let’s look at a typical procurement flow:

A Purchase Requisition is created in Manage Purchase Requisitions – Professional
- A Desired Supplier is maintained
- A Supplier Material Number (IDNLF) is entered at item level
The requisition is processed in Process Purchase Requisitions
- A Source of Supply is assigned (matching the Desired Supplier)
A Purchase Order is created using Create Purchase Order

At this point, users expect all relevant and already‑maintained information to be transferred consistently.
However, the resulting Purchase Order does not contain the Supplier Material Number (IDNLF).

________________________________________________________________________________________________________

The Gap Today: Information Is Lost Along the Process

The Supplier Material Number is not a cosmetic field—it is often a business‑critical identifier used by suppliers for:

Order confirmation
Logistics and delivery processing
Invoice matching and clarification
Communication with supplier purchasing departments

When this field is entered manually in the Purchase Requisition but not transferred to the Purchase Order, important information is lost along an otherwise integrated process.

As a result:

Users need to re‑enter data manually
The risk of inconsistencies or errors increases
Additional clarification with suppliers becomes necessary

This breaks the promise of an end‑to‑end digital procurement process.

________________________________________________________________________________________________________

Why This Matters for Procurement Efficiency

In productive environments, Purchase Requisition processors handle high volumes of requisitions under time pressure. Every additional step reduces efficiency and increases frustration.

The missing transfer of IDNLF leads to:

Extra manual steps during PO creation or follow‑up changes
Reduced process speed
Potential quality issues in supplier communication

Instead of focusing on value‑adding tasks, users are forced to compensate for system limitations.

________________________________________________________________________________________________________

The Opportunity: Small Enhancement, High Value

The proposed improvement is straightforward:

Automatically transfer the Supplier Material Number (IDNLF) from the Purchase Requisition to the Purchase Order when a matching Source of Supply is assigned.

This ensures that:

All relevant procurement data is preserved throughout the process
The Purchase Order is complete from the moment it is created
Manual rework is eliminated

Technically simple, but with a disproportionately positive impact on daily procurement operations.

________________________________________________________________________________________________________

Expected Benefits

By closing this gap, SAP S/4HANA Public Cloud customers benefit from:

Improved efficiency and productivity
Purchase Requisition processors can order faster with fewer steps in between.
Enhanced user experience
Users trust that entered data is reliably carried forward.
Higher data quality
Ensuring that no critical information is lost along the process.
Better supplier communication
Suppliers receive Purchase Orders containing their own material references.

________________________________________________________________________________________________________

Call to Action: Support the Improvement Request

This improvement request is based on real customer usage. If you encounter similar challenges or agree that procurement data should remain consistent from requisition to order, I encourage you to:

👉 Please Vote to Idea # 343655 on SAP Influence and help move this enhancement forward.

Custom Logic using Key User Extensibility in SAP S/4 HANA Public Cloud

2026-04-13T13:40:50.234000+02:00

Introduction

In On Stack extensibility, Enhancements can be created using Custom Logic App in Key User Extensibility.

Key user extensibility also know as In App extensibility, extensions can be added with key user tools.

Key User Extensibility / In App Extensibility- Custom Logic

Custom Logic is one of the Key User Extensibility Tools

In the Custom logic App,

Custom logic can be added
Easy exploration of extension points, key user documentation
Syntax check, syntax highlighting, code completion
Draft, published, testing included
ABAP Language Version for Key Users
Enhancements can be created using Custom Logi App

Business Accelerator Hub

SAP Business Accelerator Hub provides a section for On Stack extensibility (key user extensibility and developer extensibility), to know list of SAP CDS views, APIs, Business Add-ins etc. are available with the release status.

Navigate to Business Accelerator Hub to find BAdis

On Stack Extensibility -> Business Add-ins

Search for required BAdi.

This BAdi is related to check purchase order before saving to create it.

Here it shows BAdi Definition and Enhancement spot.

BAdi can be used in both Key User and Developer Extensibility as both states of BAdi is in released state.

Methods and its Parameters

Steps to Create Custom Logic

Navigate to Custom logic App

Custom Logic App

Choose Create button to create Custom Logic.

Choose Required Business Content

List of available BAdi Definitions for the business context.

Choose required BAdi Definition.

Its Documentation.

Choose Step 2 to add Implementation Description and ID.

Implementation ID automatically appears based on Description and it can also be changed.

Choose Review

Choose Create

Click on Publish button.

Its published.

Click on Open Code Editor to write the logic.

Importing Parameters.

Changing Parameters.

Sampe Code -> Show Sample Code

Keyboard Shortcuts -> three dot menu -> Show Keyboard Shortcuts

Write the required logic.

IF purchaseorder-supplier EQ '0000100005'.
APPEND VALUE #( messagetype = 'E' messagevariable1 = |Choose another Supplier| ) TO messages.
ENDIF.

Navigate to Create Purchase order (ME21N)

Provide the required details and check.

Error is appeared as per logic written.

This implementation class can be opened in the eclipse, and break point can be added in the logic, and it triggers when creating purchase order in the Create Purchase Order (ME21N).

Key-user objects can be displayed and debugged but cannot be edited with ABAP development tools.

Conclusion

In Key User Extensibility,

Custom logic can be added and Enhancements can be created using Custom Logic App.

Own implementation can be created and those can be deleted.

Implementation can be published to test, production systems

Code can be compared with older code versions.

References

Enhance Your AI Knowledge in SAP Finance: New Learning Journey Now Available

2026-04-13T17:13:10.073000+02:00

The future of finance is here, and it's powered by artificial intelligence. Are you ready to lead the charge in AI-driven financial transformation? We're excited to announce the launch of our latest learning journey: Applying Business AI Solutions and Expertise in SAP Finance

Why This Learning Journey Matters

In today's rapidly evolving business landscape, finance professionals who can harness the power of AI aren't just staying competitive; they're becoming indispensable. This intermediate learning journey is designed specifically for the next generation of finance professionals who are ready to take the lead in digital transformation and unlock the full potential of SAP's cutting-edge AI solutions.

What You'll Learn

This learning journey takes you on an immersive exploration of key AI tools that are revolutionizing finance operations:

SAP Joule: Discover how this intelligent assistant transforms everyday finance tasks
SAP Joule Agents: Learn to leverage specialized AI agents for complex financial processes
SAP Joule for Consultants: Master the tools that empower finance consulting excellence
SAP Business Data Cloud in Finance: Unlock the potential of intelligent data management

A Hands-On Learning Experience

What sets this learning journey apart is its practical, experience-driven approach. You explore Joule features in Finance firsthand through practical, hands-on exercises that enable learners to experience these capabilities themselves. You'll follow a fictitious consultant's journey as they implement AI tools across various finance business processes, giving you real-world context and actionable insights you can apply immediately.

Starting Your AI Journey? We've Got You Covered

If you're new to AI in finance, we recommend starting with our beginner-level learning journey: Discovering SAP Business AI Capabilities for SAP Finance. This foundational course introduces you to the core concepts and capabilities of AI in the finance domain, providing the perfect stepping stone before diving into the more advanced, hands-on content in our new intermediate learning journey. Whether you're taking your first steps or ready to deepen your expertise, we have a path designed for your learning needs.

Curious?

The intersection of AI and finance represents one of the most exciting opportunities in today's business world. By completing our learning journey, you'll not only gain technical expertise but also position yourself as an expert in the AI-driven future of finance. Start learning right now!

DebugSheet: Get XML Data for Local Print Form Preview in the Adobe LiveCycle Designer

2026-04-13T23:34:06.533000+02:00

Overview of my Print Form Resources

I decided to create a separate article to avoid duplicate content in each print form blog post and simplify the maintenance. You can find the list of print form-related Blogs, information on Live Sessions and an Onboarding Video for beginners in the following blog post:

Print Form Adaptation with Adobe LiveCycle Designer Overview - Onboarding, Blogs and Live Session

Intro

When working on print forms in Adobe LiveCycle Designer, having XML data (sometimes called sample data) to preview the form locally is invaluable. Here are some of the key benefits:

No need to upload to preview: You can check your current layout and verify that adjustments render correctly — all without uploading the form and opening the target business object in the system again and again after each little adjustment.
Field identification: With real sample data from your system, you can compare the output directly to the system screen and locate fields by their content, which is especially helpful when you don’t know a field’s exact technical name.
Local data manipulation: You can modify data locally — extend a text, insert line breaks, duplicate items, and so on — to see how the form behaves with different data sets.

Bottom line: Nothing beats real sample data from the target system. 💪

How to get XML Data in SAP systems?

The ways to obtain that XML data vary significantly across SAP solutions and often even differ by business object within the same solution. This guide applies to SAP solutions where forms are rendered via the Adobe Document Services (ADS) and customized using Adobe LiveCycle Designer. These include:

SAP Sales/Service Cloud (Version 1, formerly SAP Cloud for Customer)
SAP Sales/Service Cloud Version 2
SAP S/4HANA Cloud Public Edition
SAP Business ByDesign

The approach described here is often a last resort, as it involves some effort — if a system offers better ways, use those 😉
However, the DebugSheet provides an unfiltered look behind the scenes.

Important: Since this method requires replacing the currently active form template in the system, it should never be used in production environments!

Procedure

Copy the content of the XML code block from the end of this blog into a text editor and save the file as DebugSheet2.xdp
This workaround is necessary because uploading .xdp files is not supported here.
Next, upload the file as the template for the desired document in your system. Here’s where to do that in each solution:
- SAP Sales/Service Cloud: Work Center Administrator → View Form Template Maintenance
- SAP Sales/Service Cloud Version 2: System Settings → Form Templates → (All Settings) → (Output Management) → Maintain Form Template
- SAP S/4HANA Cloud Public Edition: Output Management Form Template app
- SAP Business ByDesign: Work Center Application and User Management → View Form Template Maintenance
Don’t forget to publish/activate the template and, if applicable, configure any rules that ensure the template is actually used for output.
Now navigate to the relevant business object or app in the system and trigger the PDF generation.
The DebugSheet will appear, displaying the XML data.

A word of caution when copying: Copying text from PDF files is generally not as seamless as copying from, say, a Word document. For example, selecting and copying text across multiple pages in a PDF often pulls in unwanted content from headers, footers, or other overlapping elements. The DebugSheet uses a layout that is optimized for copying XML content spanning multiple pages, but you may still encounter issues with truncated or wrapped lines. At the very least, however, you can search for specific fields and their values to verify whether certain values are part of the data set at all and could therefore be displayed in the PDF.

Behind the Scenes

Extracting the XML data is no rocket science. The DebugSheet essentially leverages a built-in function and outputs the result in an optimized layout. The following line of JavaScript does the heavy lifting:

this.rawValue = xfa.data.saveXML("pretty");

Here, this should reference a text field that allows line breaks and whose height expands automatically to fit the content.

DebugSheet2.xdp

Copy the code block's content to a text editor and save it as DebugSheet2.xdp. This workaround is necessary because uploading .xdp files is not supported here. (Do not use Word or similar programs, since they don't save plain text files.)

<?xml version="1.0" encoding="UTF-8"?>
<?xfa generator="AdobeLiveCycleDesigner_V11.0.9.20230825.1.45_SAP" APIVersion="3.6.23237.0"?>
<xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/" timeStamp="2024-07-10T10:21:11Z" uuid="178558f9-0971-43fe-b129-712041047f6d">
<template xmlns:xliff="urn:oasis:names:tc:xliff:document:1.1" xmlns="http://www.xfa.org/schema/xfa-template/2.8/">
   <?formServer defaultPDFRenderFormat acrobat9.0dynamic?>
   <?formServer allowRenderCaching 0?>
   <?formServer formModel both?>
   <subform name="DebugSheet" layout="tb" locale="ambient" restoreState="auto">
      <pageSet>
         <pageArea name="Page1" id="Page1">
            <subform x="6.265mm" y="6.196mm" w="203.285mm" name="frmPage">
               <field h="7.5mm" name="SheetCount" presence="hidden" w="55mm" access="readOnly" id="floatingField018467">
                  <ui>
                     <numericEdit>
                        <border>
                           <edge stroke="lowered"/>
                        </border>
                        <margin/>
                     </numericEdit>
                  </ui>
                  <font typeface="Arial"/>
                  <margin bottomInset="1mm" leftInset="1mm" rightInset="1mm" topInset="1mm"/>
                  <para vAlign="middle"/>
                  <caption reserve="20mm">
                     <para vAlign="middle"/>
                     <value>
                        <text xliff:rid="712B8C5D-0781-41F3-B070-E3EFA6323D8E">Text Field</text>
                     </value>
                  </caption>
                  <calculate override="error"/>
                  <event name="event__layout_ready" activity="ready" ref="$layout">
                     <script contentType="application/x-javascript">this.rawValue = xfa.layout.sheetCount();
</script>
                  </event>
                  <?templateDesigner floatingFieldPlaceholder ##?>
                  <bind match="none"/>
               </field>
               <draw name="lblSheetsCount" x="8.003347in" y="0.006069in" w="25.4mm" minH="3.175mm" anchorType="topRight">
                  <ui>
                     <textEdit>
                        <margin/>
                     </textEdit>
                  </ui>
                  <value>
                     <exData contentType="text/html" maxLength="0" xliff:rid="959E1C9E-9773-4F4F-9D17-C142F6A50880">
                        <body xmlns="http://www.w3.org/1999/xhtml" xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/"><p style="text-decoration:none;letter-spacing:0in">Pages:<span style="xfa-spacerun:yes"> </span><span xfa:embedType="uri" xfa:embedMode="raw" xfa:embed="#floatingField018467"/></p></body>
                     </exData>
                  </value>
                  <font typeface="Arial"/>
                  <margin bottomInset="0mm" leftInset="0mm" rightInset="0mm" topInset="0mm"/>
                  <para vAlign="middle" hAlign="right"/>
               </draw>
               <bind match="none"/>
               <draw name="lblDebugSheet" y="0.154mm" x="0.085mm" w="28.575mm" h="5.2331mm">
                  <ui>
                     <textEdit/>
                  </ui>
                  <value>
                     <text xliff:rid="7E7B56D4-9286-4193-8B26-4D213D1B55B8">Debug Sheet 2</text>
                  </value>
                  <font typeface="Arial"/>
                  <margin topInset="0.5mm" bottomInset="0.5mm" leftInset="0.5mm" rightInset="0.5mm"/>
                  <?renderCache.bounds 78166 12000 0 0 1417 1417 0 0?>
                  <?renderCache.textRun 13 Debug Sheet 2 0 1417 9313 0 0 0 "Arial" 0 0 10000 ISO-8859-1?></draw>
               <draw name="lblContact" y="0.154mm" x="35.01mm" w="136.525mm" h="5.2331mm">
                  <ui>
                     <textEdit/>
                  </ui>
                  <value>
                     <text xliff:rid="262929AF-8D12-4FFF-AE77-20CD8FA57EB2"/>
                  </value>
                  <font typeface="Arial">
                     <fill>
                        <color value="192,192,192"/>
                     </fill>
                  </font>
                  <margin topInset="0.5mm" bottomInset="0.5mm" leftInset="0.5mm" rightInset="0.5mm"/>
                  <para hAlign="center"/>
                  <?renderCache.bounds 384166 12000 0 0 1417 1417 0 0?></draw>
               <?templateDesigner expand 1?></subform>
            <contentArea x="6.35mm" y="12.7mm" w="203.2mm" h="260.35mm"/>
            <medium stock="default" short="215.9mm" long="279.4mm"/>
            <draw name="Line" y="273.05mm" x="6.35mm" w="203.2mm" h="0in">
               <value>
                  <line slope="/"/>
               </value>
            </draw>
            <occur min="1" max="1"/>
            <?templateDesigner expand 0?></pageArea>
         <pageArea name="Page2" id="Page2_ID">
            <medium stock="default" short="612pt" long="792pt"/>
            <contentArea x="6.35mm" y="6.35mm" w="203.2mm" h="266.7mm"/>
            <draw name="Line" y="6.35mm" x="6.351mm" w="203.2mm" h="0in">
               <value>
                  <line slope="/"/>
               </value>
            </draw>
            <draw name="Line" y="273.05mm" x="6.351mm" w="203.2mm" h="0in">
               <value>
                  <line slope="/"/>
               </value>
            </draw>
            <?templateDesigner expand 1?></pageArea>
         <?templateDesigner expand 0?></pageSet>
      <subform w="8in" name="bdy_Page" layout="tb">
         <subform w="203.2mm" minH="9mm" layout="tb" name="frmInfo">
            <draw name="lblHostInfo" w="203.2mm" h="7mm">
               <ui>
                  <textEdit/>
               </ui>
               <value>
                  <text xliff:rid="CD6FDAB8-DDDA-4732-98C1-45A4E7EE1732">Host+Form Information</text>
               </value>
               <font typeface="Arial"/>
               <margin topInset="0.5mm" bottomInset="0.5mm" leftInset="0.5mm" rightInset="0.5mm"/>
               <para vAlign="middle" hAlign="center"/>
               <border>
                  <edge>
                     <color value="192,192,192"/>
                  </edge>
                  <corner thickness="0.176mm">
                     <color value="192,192,192"/>
                  </corner>
                  <fill>
                     <color value="204,255,204"/>
                  </fill>
               </border>
               <?renderCache.bounds 573166 17009 0 0 1417 1417 0 0?>
               <?renderCache.textRun 21 Host+Form Information 0 236733 12817 0 0 0 "Arial" 0 0 10000 ISO-8859-1?></draw>
            <field name="dtNow" w="62mm" h="9mm" presence="hidden">
               <ui>
                  <dateTimeEdit>
                     <border>
                        <edge stroke="lowered"/>
                     </border>
                     <margin/>
                  </dateTimeEdit>
               </ui>
               <font typeface="Arial"/>
               <margin topInset="1mm" bottomInset="1mm" leftInset="1mm" rightInset="1mm"/>
               <para vAlign="middle"/>
               <caption reserve="25mm">
                  <para vAlign="middle"/>
                  <value>
                     <text xliff:rid="CDB41F6E-8154-4C44-8ACF-95C28ABC6C04">Date/Time Field</text>
                  </value>
               </caption>
               <format>
                  <picture>datetime.full{}</picture>
               </format>
               <event activity="initialize" name="event__initialize">
                  <script contentType="application/x-javascript">
this.rawValue = xfa.host.currentDateTime();

</script>
               </event>
            </field>
            <field name="txtHostInformation" w="203.2mm" minH="9mm" access="readOnly">
               <ui>
                  <textEdit multiLine="1">
                     <border>
                        <?templateDesigner StyleID aped3?>
                        <edge stroke="lowered"/>
                     </border>
                     <margin/>
                  </textEdit>
               </ui>
               <font typeface="Arial"/>
               <margin topInset="1mm" bottomInset="1mm" leftInset="1mm" rightInset="1mm"/>
               <para vAlign="middle"/>
               <bind match="none"/>
               <event activity="initialize" name="event__initialize">
                  <script contentType="application/x-javascript">
this.rawValue = "DateTime:\t" + dtNow.rawValue + "\n" +
"   Formatted:\t" + dtNow.formattedValue + "\n" +
"   Pattern:\t" + dtNow.format.picture.value + "\n" +
"   Locale:\t" + dtNow.locale + "\n" +
"Name:\t\t" + xfa.host.name + "\n" +
"Version:\t" + xfa.host.version + "\n" +
"Platform:\t" + xfa.host.platform + "\n" +
"Host Lang.:\t" + xfa.host.language;

this.rawValue += "\nHost Title:\t" + xfa.host.title;
</script>
               </event>
            </field>
            <bind match="none"/>
            <?templateDesigner expand 1?></subform>
         <subform w="203.2mm" minH="9mm" layout="tb" name="frmDebug">
            <field name="txtDebug" w="203.2mm" minH="9mm" presence="hidden">
               <ui>
                  <textEdit>
                     <border>
                        <?templateDesigner StyleID aped3?>
                        <edge stroke="lowered"/>
                     </border>
                     <margin/>
                  </textEdit>
               </ui>
               <font typeface="Arial"/>
               <margin topInset="1mm" bottomInset="1mm" leftInset="1mm" rightInset="1mm"/>
               <para vAlign="middle"/>
               <value>
                  <text xliff:rid="AB0D916A-DAD3-4139-A4F9-DD2C4FA08241">DEBUG</text>
               </value>
               <border>
                  <edge presence="hidden"/>
                  <fill>
                     <color value="255,204,153"/>
                  </fill>
               </border>
               <bind match="none"/>
            </field>
            <?templateDesigner expand 1?></subform>
         <subform y="16mm" w="203.2mm" minH="9mm" layout="tb" name="frmDataSource">
            <draw name="lblDataSource" w="203.2mm" h="7mm">
               <ui>
                  <textEdit/>
               </ui>
               <value>
                  <text xliff:rid="8D7B9F04-8587-4E36-904E-576E51709E41">DataSource</text>
               </value>
               <font typeface="Arial"/>
               <margin topInset="0.5mm" bottomInset="0.5mm" leftInset="0.5mm" rightInset="0.5mm"/>
               <para vAlign="middle" hAlign="center"/>
               <border>
                  <edge>
                     <color value="192,192,192"/>
                  </edge>
                  <corner thickness="0.176mm">
                     <color value="192,192,192"/>
                  </corner>
                  <fill>
                     <color value="204,255,204"/>
                  </fill>
               </border>
               <?renderCache.bounds 573166 17009 0 0 1417 1417 0 0?>
               <?renderCache.textRun 10 DataSource 0 261596 12817 0 0 0 "Arial" 0 0 10000 ISO-8859-1?></draw>
            <field name="txtContent" w="203.2mm" minH="9mm" access="readOnly">
               <ui>
                  <textEdit multiLine="1">
                     <border>
                        <?templateDesigner StyleID aped3?>
                        <edge stroke="lowered"/>
                     </border>
                     <margin/>
                  </textEdit>
               </ui>
               <font typeface="Arial" size="5pt"/>
               <margin topInset="1mm" bottomInset="1mm" leftInset="1mm" rightInset="1mm"/>
               <para vAlign="middle"/>
               <border>
                  <edge presence="hidden"/>
               </border>
               <value>
                  <text> </text>
               </value>
               <bind match="none"/>
               <event activity="initialize" name="event__initialize">
                  <script contentType="application/x-javascript">
this.rawValue = xfa.data.saveXML("pretty");
</script>
               </event>
            </field>
            <bind match="none"/>
            <?templateDesigner expand 1?></subform>
         <bind match="none"/>
         <?templateDesigner expand 1?></subform>
      <proto/>
      <desc>
         <text name="version">2.1</text>
         <text name="contact">f.wyskocil@sap.com</text>
         <text name="creator">Felix Wyskocil</text>
         <text name="title">DebugSheet</text>
      </desc>
      <?templateDesigner expand 1?>
      <?templateDesigner Hyphenation excludeInitialCap:1, excludeAllCaps:1, wordCharCnt:7, remainCharCnt:3, pushCharCnt:3?>
      <?renderCache.subset "Arial" 0 0 ISO-8859-1 4 140 35 00030006000E00120015001D0025002700280029002A002B002C0033003600370038004400450046004700480049004A004B004C004F0050005100520055005600570058005B #+/2:BDEFGHIPSTUabcdefghilmnorstux?></subform>
   <?templateDesigner DefaultPreviewDynamic 1?>
   <?templateDesigner Grid show:1, snap:1, units:17, color:ff8080, origin:(0,0), interval:(79375,79375), objsnap:0, guidesnap:0, pagecentersnap:1050195012?>
   <?templateDesigner SavePDFWithLog 0?>
   <?originalXFAVersion http://www.xfa.org/schema/xfa-template/2.8/?>
   <?templateDesigner SaveTaggedPDF 0?>
   <?templateDesigner SavePDFWithEmbeddedFonts 0?>
   <?templateDesigner Rulers horizontal:1, vertical:1, guidelines:1, crosshairs:0?>
   <?templateDesigner Zoom 142?>
   <?templateDesigner FormTargetVersion 28?>
   <?templateDesigner DefaultLanguage JavaScript?>
   <?templateDesigner DefaultRunAt client?>
   <?acrobat JavaScript strictScoping?>
   <?PDFPrintOptions embedViewerPrefs 0?>
   <?PDFPrintOptions embedPrintOnFormOpen 0?>
   <?PDFPrintOptions scalingPrefs 0?>
   <?PDFPrintOptions enforceScalingPrefs 0?>
   <?PDFPrintOptions paperSource 0?>
   <?PDFPrintOptions duplexMode 0?>
   <?templateDesigner DefaultPreviewType interactive?>
   <?templateDesigner DefaultPreviewPagination simplex?>
   <?templateDesigner XDPPreviewFormat 20?>
   <?templateDesigner DefaultPreviewDataFileName .\SampleData.xml?>
   <?templateDesigner DefaultCaptionFontSettings face:Arial;size:10;weight:normal;style:normal?>
   <?templateDesigner DefaultValueFontSettings face:Arial;size:10;weight:normal;style:normal?></template>
<config xmlns="http://www.xfa.org/schema/xci/2.8/">
   <agent name="designer">
      <!--  [0..n]  -->
      <destination>pdf</destination>
      <pdf>
         <!--  [0..n]  -->
         <fontInfo/>
      </pdf>
   </agent>
   <present>
      <!--  [0..n]  -->
      <pdf>
         <!--  [0..n]  -->
         <version>1.7</version>
         <adobeExtensionLevel>3</adobeExtensionLevel>
      </pdf>
      <common>
         <data>
            <xsl>
               <uri/>
            </xsl>
            <outputXSL>
               <uri/>
            </outputXSL>
         </data>
      </common>
      <cache>
         <macroCache/>
      </cache>
      <xdp>
         <packets>*</packets>
      </xdp>
   </present>
</config>
<localeSet xmlns="http://www.xfa.org/schema/xfa-locale-set/2.7/">
</localeSet>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2.1-c043 52.451533, 2010/12/17-12:49:35        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:pdf="http://ns.adobe.com/pdf/1.3/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:pdfuaid="http://www.aiim.org/pdfua/ns/id/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:desc="http://ns.adobe.com/xfa/promoted-desc/" rdf:about="">
         <xmp:MetadataDate>2024-07-10T10:21:11Z</xmp:MetadataDate>
         <xmp:CreatorTool>Adobe LiveCycle Designer 11.0</xmp:CreatorTool>
         <pdf:Producer>Adobe LiveCycle Designer 11.0</pdf:Producer>
         <xmpMM:DocumentID>uuid:178558f9-0971-43fe-b129-712041047f6d</xmpMM:DocumentID>
         <pdfuaid:part>1</pdfuaid:part>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>Felix Wyskocil</rdf:li>
            </rdf:Seq>
         </dc:creator>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">DebugSheet2</rdf:li>
            </rdf:Alt>
         </dc:title>
         <desc:version rdf:parseType="Resource">
            <rdf:value>2.1</rdf:value>
            <desc:ref>/template/subform[1]</desc:ref>
         </desc:version>
         <desc:contact rdf:parseType="Resource">
            <rdf:value>f.wyskocil@sap.com</rdf:value>
            <desc:ref>/template/subform[1]</desc:ref>
         </desc:contact>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>
<connectionSet xmlns="http://www.xfa.org/schema/xfa-connection-set/2.8/"/>
<xfa:datasets xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
   <xfa:data xfa:dataNode="dataGroup"/>
</xfa:datasets></xdp:xdp>

Getting Services Right from the Start: Why the Product Type Group Should Be Assignable in the IR

2026-04-14T08:00:00.022000+02:00

Getting Services Right from the Start:

Why the Product Type Group Should Be Assignable in the Purchasing Info Record

Accurate classification of materials and services is essential for smooth procurement and follow‑on processes in SAP S/4HANA Public Cloud. Especially in production‑related procurement, correctly distinguishing between materials and services is not optional—it is a prerequisite for compliant and efficient execution.

Yet in real customer scenarios, this distinction is not always preserved automatically. A critical gap exists around the Product Type Group when external services are procured via Purchasing Info Records.

________________________________________________________________________________________________________

The Business Scenario: External Processing in Production Orders

A typical business case looks like this:

A Production Order is created
An Operation for external processing is defined
This operation uses a Purchasing Info Record
A Purchase Requisition item is generated automatically
A Purchase Order is created based on the requisition

At first glance, this end‑to‑end process appears fully integrated and automated. However, an important detail is missing along the way.

________________________________________________________________________________________________________

The Gap Today: Product Type Group Is Defaulted Incorrectly

The issue arises at the Purchase Requisition level:

The automatically created Purchase Requisition item does not carry a Product Type Group
As a result, when the Purchase Order is created, the system defaults the Product Type Group to:
- 1 – Material

For external services, this default is incorrect.

Services must be handled differently from materials, both functionally and legally. By defaulting to “Material”, the system places the document on the wrong processing path from the very beginning.

________________________________________________________________________________________________________

Why This Is a Critical Issue for Service Procurement

The incorrect Product Type Group has direct downstream consequences:

Service‑specific processes are not triggered
The Service Entry Sheet process is not initiated correctly
Additional manual correction is required
The risk of posting and compliance errors increases

In other words:
Although the business process clearly involves services, the system treats them as materials—forcing users to intervene manually.

This contradicts the goal of automated, guided processes in SAP S/4HANA Public Cloud.

________________________________________________________________________________________________________

Root Cause: Missing Product Type Group in the Purchasing Info Record

The underlying reason for this issue is straightforward:

The Purchasing Info Record does not allow maintenance of the Product Type Group
Therefore, the Purchase Requisition created from it lacks this essential classification
The Purchase Order inherits an incorrect default

Without a way to define whether the Info Record represents a material or a service, the system cannot make the right decision automatically.

________________________________________________________________________________________________________

The Proposed Improvement: Extend the Purchasing Info Record

The improvement request proposes a clear and targeted enhancement:

Allow the Product Type Group to be maintained in the Purchasing Info Record and transferred automatically to the Purchase Requisition and Purchase Order.

With this enhancement in place:

External services can be clearly marked as Product Type Group 2 – Service
Materials remain correctly classified as Product Type Group 1 – Material
The correct processing path is selected automatically

A small master data extension would eliminate a recurring operational issue.

________________________________________________________________________________________________________

Business Benefits of This Improvement

Introducing the Product Type Group into the Purchasing Info Record delivers multiple benefits:

Correct service processing from the start
Service entry sheets and related follow‑up processes are triggered as intended.
Reduced manual effort
No need for corrections during Purchase Order creation.
Higher data quality and consistency
Classification reflects the true business context.
Improved compliance and process reliability
Especially important for service procurement in production environments.
Enhanced user experience
Users can rely on the system instead of compensating for missing logic.

________________________________________________________________________________________________________

Call to Action: Support Better Service Handling in Procurement

This improvement request addresses a real, recurring issue in production‑related service procurement. If your organization uses external processing or service procurement via Production Orders and Purchasing Info Records, I encourage you to:

👉 Please Vote to Idea # 369894 on SAP Influence and help move this enhancement forward.

A Missing Distinction in Master Data: Why SAP S/4HANA Cloud Needs a Dedicated Business Partner Role

2026-04-15T08:00:00.018000+02:00

A Missing Distinction in Master Data:

Why SAP S/4HANA Public Cloud Needs a Dedicated Business Partner Role for Manufacturers

Master data clarity is a cornerstone of efficient procurement and material management processes in SAP S/4HANA Public Cloud. Business Partners (BP) play a central role in ensuring that responsibilities, relationships, and business contexts are clearly modeled in the system.

While SAP S/4HANA Public Cloud already provides a Business Partner role for Suppliers, an important real‑world distinction is currently missing: Manufacturers are treated like any other Business Partner, despite playing a fundamentally different role in the business process.

________________________________________________________________________________________________________

The Business Reality: Suppliers Are Not Manufacturers

In typical procurement scenarios:

Suppliers are contractual partners
→ We place purchase orders, receive invoices, and process payments with them.
Manufacturers produce the goods
→ There is no direct commercial relationship with them.

We buy materials from suppliers, not from manufacturers — yet manufacturers are essential for:

Product identification
Compliance and regulatory requirements
Quality management
Supplier‑independent material transparency

This distinction is common business practice, but currently not reflected cleanly in SAP S/4HANA Public Cloud master data.

________________________________________________________________________________________________________

The Gap Today: No Dedicated BP Role for Manufacturers

In SAP S/4HANA Cloud Public Edition:

Business Partners can be created
BP roles such as Supplier can be assigned
However, no BP role exists for “Manufacturer”

This leads to a concrete issue in daily master data maintenance.

Example: Material Master Data (Purchasing View)

To maintain the Manufacturer field (MFRNR) in the Material Master (Purchasing view), the system requires:

Selection of a Business Partner

Since there is no BP role specifically for manufacturers:

Manufacturers must be created using unrelated or generic BP roles
Sometimes even as suppliers — despite no purchasing relationship

The result: inconsistent and misleading master data.

________________________________________________________________________________________________________

Impact of the Current Situation

The missing BP role for manufacturers causes multiple challenges:

Data inconsistency Manufacturers appear in the system without a clearly defined business context.
Blurring of responsibilities Suppliers and manufacturers cannot be cleanly distinguished in analytics, governance, or data ownership.
Reduced data quality Master data no longer reflects the real business relationship.
Higher risk in compliance and audits Especially when manufacturer information is legally or regulatorily relevant.

Instead of supporting clean master data modeling, the system forces customers into workarounds.

________________________________________________________________________________________________________

The Opportunity: Introduce a Dedicated BP Role “Manufacturer”

The proposed improvement is conceptually simple but highly valuable:

Introduce a dedicated Business Partner role for “Manufacturer”.

This would allow customers to:

Clearly separate manufacturers from suppliers
Assign manufacturers only where they are actually required (e.g. Material Master)
Prevent incorrect role usage and misinterpretation

Most importantly, it aligns SAP master data modeling with real‑world business structures.

________________________________________________________________________________________________________

Business Benefits of This Improvement

Introducing a BP role for manufacturers enables:

Clearer master data structures
Distinct, purpose‑driven Business Partner roles.
Improved data quality and consistency
Manufacturer information is stored correctly and transparently.
Better governance and compliance support
Especially relevant in regulated industries.
Improved user experience
Master data specialists no longer need to apply workarounds or compromises.
Future‑proof data models
Clean separation allows better extensibility and reporting.

________________________________________________________________________________________________________

Call to Action: Help Improve SAP Master Data Modeling

This improvement request is based on real customer requirements and widely used procurement processes. If you face similar challenges or agree that manufacturers deserve their own Business Partner role, I encourage you to:

👉Please Vote to Idea # 353179 on SAP Influence and help move this enhancement forward.

客户项目首付款开票流程

2026-04-15T09:24:46.325000+02:00

本博文简单介绍Professional Service客户项目首付款开票流程

系统演示

1.创建客户项目，建立开票，案例用的是固定价格合同开票类型

合同总金额3000，首付款1000

2.APP：管理项目开票，点击黄色三角形查看预付款金额

点击设置按钮，把字段Down Payment Received和Down Payment Requested勾选。

选择开票项，点击Prepayment

点击Submit

开票请求已生成

APP:创建开票凭证，设置开票类型FAZ，对首付款进行开票并过账生成日记账

点击Entry View查看分录

3. APP: Post Incoming Payment

查看日记账分录

4.创建总发票，APP:管理项目开票，点击Prepare Billing

开票凭证请求已生成

APP:创建开票凭证，设置开票类型CI01

查看日记账分录，冲销了首付款的分录

感谢观看

Strengthen Your SAP Projects in Q2 with SAP Enterprise Support Advisory Council

2026-04-15T10:24:30.493000+02:00

Looking for more hands-on support and early access to the latest SAP Enterprise Support services?

With SAP Enterprise Support, part of the Foundational Success Plan included in all cloud subscriptions, you already have a strong foundation to get up and running, safeguard business continuity, and drive ongoing value.

Through the SAP Enterprise Support Advisory Council (ESAC), you can go even further. As a key component of this offering, ESAC connects you directly with SAP experts and peers to bring hands-on support to your projects, co-innovate, test new services early, and help shape future support offerings.

Why join?

Get expert guidance for your projects
Access and influence new services before general release
Turn your feedback into real support improvements

What’s New in Q2?

New workstreams:

CQC* Transformation Assessment for SAP Transportation Management (Blog)
CQC Transformation Assessment for SAP Extended Warehouse Management (Blog)

Still open to new customers:

CQC Technical Preparation for SAP Signavio Process Insights and Intelligence (Blog)
CQC Deployment Readiness for the Integrated Toolchain (Blog)
CQC Deployment Readiness for SAP Signavio Process Manager and Collaboration Hub (Blog)
CQC Security Optimization for SAP S/4HANA Cloud Public Edition (Blog)
EGI* Support Migration to SAP Integration Suite (Blog)

Discover our workstreams: workstream overviews

Get Involved?

Learn more: visit us on SAP Support Portal.
contact us: esac@sap.com

Your SAP Enterprise Support Advisory Council team

*Continuous Quality Check (CQC): Work with our experts to analyze your system using real data and receive a report with key findings and a clear action plan to improve outcomes and reduce risks.

*Expert-Guided Implementation (EGI): A multi-day, remote, workshop-style session where participants learn to complete a defined activity with the support of experienced SAP service engineers.

BAdi Enhancement Implementation using Developer Extensibility in SAP S/4HANA Cloud Public Edition

2026-04-15T10:40:40.392000+02:00

Introduction

In On Stack extensibility, Enhancements can be created using BAdi Enhancement Implementation in Developer Extensibility.

Developer extensibility using SAP Cloud ABAP Environment for developer extensions.

Business Accelerator Hub

On Stack Extensibility -> Business Add-ins

Search for required BAdi.

This BAdi is related to check purchase order before saving to create it.

Here it shows BAdi Definition and Enhancement spot.

BAdi can be used in both Key User and Developer Extensibility as both states of BAdi is in released state.

Methods and its Parameters

Developer Extensibility – BAdi Enhancement Implementation

Steps to Create Impelementation

Create New BAdi Enhancement Implementation

Chose BAdi Enhancement Implementation.

Add Name and description.

Add Enhancement Spot

BAdi Enhancement Implementation is created.

Choose BAdi Implementation to add Implementations.

Add BAdi Definition and Custom Class name

Add Implementation Class

Choose Implementation Class, add Custom Class name and its description

Implementation Class is created.

ZCL_CHECK_PO▸
CLASS zcl_check_po DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
   
   INTERFACES if_badi_interface
   INTERFACES if_ex_mmpur_final_check_po .

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_check_po IMPLEMENTATION.

  METHOD if_ex_mmpur_final_check_po~check. 
  ENDMETHOD.
ENDCLASS.

Implementation Class is added to Badi Implementation details

Logic can be added to implementation class

ZCL_CHECK_PO▸
CLASS zcl_check_po DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
   
   INTERFACES if_badi_interface
   INTERFACES if_ex_mmpur_final_check_po .

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_check_po IMPLEMENTATION.

  METHOD if_ex_mmpur_final_check_po~check. 
    IF purchaseorder-supplier EQ '0000100005'. 
      APPEND VALUE #( messagetype = 'E' messagevariable1= |Choose another Supplier] ) TO messages.
    ENDIF.  
  ENDMETHOD.
ENDCLASS.

Navigate to Create Purchase Order (ME21N)

Provide the required details and check

Error appeared as per logic written.

Add breakpoint in the implementation class to debug.

Place cursor on the logic, choose right click.

Break point is added

Break point can be added in the logic, and it triggers when creating purchase order in the Create Purchase Order (ME21N).

Conclusion

In Developer Extensibility, BAdi Enhancement Implementation can be created and deleted.

Custom Implementation can be captured in TR's and those can be moved to test, production systems.

This custom implementation can also be debugged.

References

Setting Mandatory Fields in Purchase Requisitions via Custom Logic in Public Cloud

2026-04-15T11:40:00.015000+02:00

In SAP S/4HANA Public Cloud, Purchase Requisitions (PRs) often require additional field validations to ensure data completeness and process compliance. While some fields can be defined as mandatory through standard customizing, this is limited to predefined fields and specific scenarios.

This blog post explains how to set additional standard fields as mandatory in Purchase Requisitions by using Custom Logic with Key User Extensibility.

The solution applies to the following apps:

Manage Purchase Requisitions – Professional
Create Purchase Requisition – Advanced

Business Requirement

The business requirement was to enforce mandatory entry of the following fields at purchase requisition item level:

Purchasing Organization (Field EKORG)
Requisitioner (Field AFNAM)

Why standard customizing is not sufficient

Using the customizing activity Maintain Account Assignment Categories (ID 101815), some fields (for example Cost Center) can be set as mandatory. However:

This applies only during the creation of an account assignment category
Only predefined fields are available
Additional standard fields cannot be enforced

To cover these gaps, Custom Logic (BAdIs) must be used.

Solution Overview

To fulfill the requirements, two different Custom Logic extension points are used:

Both extension points are available via the Custom Logic app in SAP S/4HANA Public Cloud.

Custom Logic 1: Change of Field Control (Purchasing Organization)

Extension Point: Change of Field Control for Purchase Requisitions

Extension Point ID: MM_PUR_S4_PR_FLDCNTRL_SIMPLE

Description

This BAdI allows you to:

Hide fields
Set fields as read-only
Set fields as mandatory
Set fields as optional

It works directly at UI field control level.

⚠️Limitation
This extension point supports the field PURREQNSSPREQUESTOR, which is relevant only for Self‑Service Procurement.
It does not enforce the Requisitioner field in apps Manage Purchase Requisitions - Professional or Create Purchase Requisition - Advanced.

Sample Code – Change of Field Control (Purchasing Organization)

* Sample Code

    FIELD-SYMBOLS <fs> TYPE mmpur_s_pr_fldsel.


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

* END OF Sample Code

✔️ Result:

The Purchasing Organization field becomes mandatory on PR item level.

Custom Logic 2: Check of Purchase Requisition Item (Requisitioner)

Since the Requisitioner (AFNAM) cannot be enforced via field control, a check-based validation is required.

Extension Point: Check of Purchase Requisition Item

Extension Point ID: MM_PUR_S4_PR_CHECK

Description

This BAdI allows you to:

Perform custom validations
Trigger error messages
Prevent saving the Purchase Requisition

Sample Code – Check of Purchase Requisition Item (Requisitioner)

* Sample Code

DATA: ls_message LIKE LINE OF messages.

IF PURCHASEREQUISITION-PURCHASINGDOCUMENTTYPE = 'NB'.
LOOP AT purchaserequisitionitem_table INTO DATA(ls_item).
      IF ls_item-PURREQNREQUESTOR = ''.

         APPEND VALUE #( messagetype = 'E'
         messageid = 'ME'
         messagenumber = '999'
         messagevariable1 = 'Enter Requisitioner / Anforderer fehlt' ) TO messages.
         purchaserequisitionhaserror = abap_true.
         RETURN.
      ENDIF.
  ENDLOOP.
ENDIF.

* END OF Sample Code

✔️ Result:

The PR cannot be saved if the Requisitioner is missing
A clear error message is displayed to the user

Transport

Custom Logic implementations are not transported automatically and must be added to a Software Collection.

Steps

Open Export Software Collection
Select an existing collection or create a new one
Choose Add Items
Filter by:
- Last Changed On
- Last Changed By
Add the Custom Logic entries
Transport the collection as usual

Summary

By combining two Custom Logic extension points, it is possible to:

Enforce mandatory fields beyond standard customizing limits
Apply validations consistently across professional and advanced PR apps
Stay fully within SAP-recommended extensibility

This approach provides a flexible and upgrade-safe way to enhance Purchase Requisition quality.

References

Instructor‑Led Training Now Available: Applying Business AI Solutions and Expertise in SAP Finance

2026-04-15T16:00:48.353000+02:00

Following our recent post announcing the new Learning Journey Applying Business AI Solutions and Expertise in SAP Finance, we would like to remind you that the corresponding instructor‑led Training is already open for registration and coming up soon.

SAP Business AI is shaping how Finance processes are designed and executed today. While the Learning Journey offers flexible, self‑paced access to this topic, the instructor‑led Training provides an opportunity to deepen this knowledge in a guided, hands‑on setting with direct expert interaction.

Instructor‑led Training: Applying Business AI in SAP Finance

The two‑day instructor‑led Training focuses on the practical application of SAP Business AI in Finance and is designed for consultants and finance professionals who want to actively work with these capabilities.

During the training, participants will:

Apply SAP Joule in concrete Finance processes and scenarios
Work hands‑on with SAP Joule Agents to support more complex Finance activities
Explore consultant‑focused SAP Joule use cases for analysis, explanation, and solution design
Gain practical insights into Finance functionality within SAP Business Data Cloud
Understand the technical and functional foundation needed to position and demonstrate AI in SAP Finance

The course places strong emphasis on interactive exercises, live demonstrations, and real‑world Finance examples, allowing participants to directly transfer what they learn into project and customer contexts.

Instructor‑led Training details:

Duration: 2 full days
Delivery format: Hybrid, with on‑site participation in Walldorf and virtual attendance
Upcoming session: June 10–11
Language: German for this session; English sessions are planned and will be announced

Registration link: F0610 - Applying Business AI Solutions and Expertise in SAP Finance | SAP Training

You’re also welcome to check out our new Business AI Learning Journey: Applying Business AI Solutions and Expertise in SAP Finance

Both the Learning Journey and the instructor‑led Training stand on their own and do not require completion of the other. They can be taken individually or combined to deepen Business AI expertise in SAP Finance.

Both formats support the development of practical, role‑relevant AI expertise in SAP Finance.

We look forward to your participation.

SAP S/4HANA Group Reporting: Using Automatic Postings for Revenue-Based Cost Distribution

2026-04-15T19:35:19.507000+02:00

Introduction

In Group Reporting, the financial "Close" process is frequently delayed by the reliance on external distribution cycles. Distributing shared costs or risks across entities often requires moving data between modules, creating silos, and slowing down the path to a consolidated view.

By utilizing Automatic Postings, organizations can implement simple logic directly within the consolidation engine. This native approach offers a transparent, audit-ready method for managing financial adjustments. This post shows how to automate the distribution of Bad Debt Allowance to profit centers based on Revenue drivers, ensuring your consolidated data reflects real-world credit exposure with clinical precision.

The Scenario: Revenue-Based Distribution

In this scenario, our objective is to distribute Bad Debt Allowance (FS Item 583000) across Profit Centers. The distribution is proportional to the Revenue (FS Item 411100 – Sale of Goods) generated by each profit center.

The underlying financial logic is straightforward: Higher Revenue → Higher Credit Exposure → Higher Bad Debt Allowance.

By automating this with the rules for automatic postings, we ensure that as revenue figures shift, the corresponding risk provision is redistributed without manual intervention or data.

Source Data (Before Distribution)

Results (After Distribution)

Solution Overview: The Modular Rule Design

To achieve this distribution, we employ a modular two-rule design. This structure allows the system first to establish the driver and then apply it to the financial values.

Rule ID	Purpose	Outcome
Rule 1	Calculate Revenue Share (%)	Calculates the percentage of total revenue per Profit Center and stores it as a quantity driver (%).
Rule 2	Distribute Bad Debt	Consumes the stored quantity driver (%) to post the proportional bad debt distribution.

Step 1: Calculating the Revenue Share (The Driver)

Rule 1 identifies the revenue for each Profit Center and determines its share relative to the total.

First, we define a selection, Z_SOG, to filter relevant source data. The criteria include:

FS Item: 411100 (Sale of Goods)
Posting levels: #, 0C, 00, 01
Profit center: not empty

Selection used in Rule 1:

Posting Logic & Variables To ensure the calculation is dynamic, we use the variable Z_VAR_SOG to represent the total revenue across all relevant Profit Centers. The system then calculates the share for each specific Profit Center using the following formula:

Revenue Share per profit center = SOURCE_LC / Z_VAR_SOG

Variable used in Rule 1:

Since the driver calculation must be processed within each consolidation unit, it is important to include the field Consolidation Unit in the list of matching fields of the variable.

Rule 1 Setting:

Record the result of this calculation to a statistical FS item, such as ZS_PC_SHR, and set the Base Unit to PRC (Percentage). This means that the FS item must be assigned to a breakdown category with unit of measure. Also, it is critical to enable "Posting with Quantities." Setting the unit to PRC ensures that a result of "0.15" is correctly interpreted as 15% during the multiplication in Step 2.

Step 2: Performing the Bad Debt Distribution

Once Rule 1 has prepared the drivers and stored them as quantities, Rule 2 executes the actual distribution. Rule 2 requires a Variable Z_VAR_BDA to select the total Bad Debt Allowance Amount.

Variable used in Rule 2:

Here again, it is important to include the field Consolidation Unit in the list of matching fields of the variable because the distribution must be processed within each consolidation unit.

The system applies the following formula to distribute the bad debt value across the target Profit Centers:

Distributed Value = Bad Debt * Z_PC_SHARE (Profit Center Share)

Selection used in Rule 2:

Rule 2 Setting:

The first posting line records the distributed amount on each profit center, and the second posting line reverses the full amount initially reported without profit center. Using the formula Balance() ensure that not rounding entry will remain.

Rule Group Setting:

The Rule Group includes above two rules, which are designed to work together in sequence.

The first rule prepares the driver, which is calculated based on the sales revenue for each profit center. This step is essential because it creates the weighting factor that will be used in the next step.

The second rule then uses this driver to distribute the bad debt across the profit centers. Since this distribution relies directly on the values calculated in the first rule, there is a clear dependency between the two.

To ensure everything runs correctly, the dependency is explicitly defined in the rule group by setting the second rule to “Depends on Previous Rules” . This guarantees that the first rule is executed before the second one. The sequence number further reflects this order, making sure the driver is prepared first, so the bad debt distribution can be calculated accurately based on it.

The result is a proportional distribution that accurately aligns risk provisions with revenue performance, visible in the task log .

Key Design Decisions & Why They Matter

Quantities as Drivers: By storing percentages as quantities, once a driver is calculated for a period, it remains in the database as a quantity that can be referenced by multiple rules without re-calculation.
Variable Usage (Z_VAR_SOG): Utilizing variables for the "Total" denominator ensures the calculation remains dynamic. If a new Profit Center is added or revenue data is updated, the variable automatically reflects the new total, ensuring the sum of shares always equals 100%.
Auditability via Document Types: We recommend dedicated Document Types (e.g., Z7, Z8) for these distributions. This isolates the distribution logic from original reported data, providing a clear trail for auditors to distinguish between original balances and calculated results.

Conclusion & Community Engagement

Working with the “Manage Rules for Automatic Postings” app is less technical than it may initially appear. In practice, defining simple distribution rules is quick and requires minimal effort—especially compared to other solutions that rely on scripting or complex calculation logic. A key advantage is how easily these basic setups can be extended to support more dynamic distribution scenarios, without introducing additional complexity. From a group reporting consultant’s perspective, this simplicity streamlines implementation and keeps teams flexible, while ensuring full audit transparency.

References:

SAP S/4HANA for Group Reporting - Introducing New Rules for Automatic Postings

SAP S/4HANA for Group Reporting - Using Variables and Functions in Rules for Automatic Postings

Rules for Automatic Postings

________________________________________________________________________________________________________

Special thanks to @GregoireDesombrefor his thoughtful review of this blog—much appreciated!

Managing Multi-Country/Region Implementations with a Parallel Line

2026-04-16T09:14:40.250000+02:00

Co-authored by @StefanBarth and @Nicola_Pace

Implementing SAP S/4HANA Cloud Public Edition across multiple countries/regions is a complex endeavor that requires careful planning and robust configuration management. The parallel line provides a powerful solution for managing multi-wave, multi-country/region rollouts without disrupting your productive environment. In this post, I’ll walk you through a proven approach for leveraging the parallel line to run phased country/region implementations efficiently and safely.

For more information about the system landscape with a parallel line, parallel line management, and the lifecycle processes branch, rebase, and merge, refer to the product assistance on SAP Help Portal.

Why Use a Parallel Line for Multi-Country/Region Implementations?

The parallel line offers a separate workspace in SAP Central Business Configuration and additional SAP S/4HANA Cloud Public Edition tenants in your development and test systems. This separation enables you to:

Develop and test new country/region configurations without affecting your stable main line
Maintain operational continuity in live countries/regions while preparing for future waves
Validate complex configurations thoroughly before merging them into your main line
Reduce risk by isolating configuration changes until they're fully tested

Understanding the Foundation: The 5-Country/Region Limit

SAP Central Business Configuration has a critical deployment constraint that directly impacts how you plan and run multi-country/region implementations. The 5-country/region limit is a technical recommendation designed to optimize system performance and ensure smooth activation processes in the main line as well as the parallel line.

When the Limit Applies

This limit applies every time there is deployment and activation from SAP Central Business Configuration to the customizing tenant of SAP S/4HANA Cloud Public Edition:

For each group or batch of countries/regions implemented in the main line and deployed from the SAP Central Business Configuration workspace to the customizing tenant (D.100) in the main line
For each group or batch of countries/regions implemented in the parallel line and deployed from the SAP Central Business Configuration workspace to the parallel customizing tenant (D.120) in the parallel line

Critically for merges: When merging from the parallel line to the main line, deployment and activation are performed in one step. In this case, 5 is the maximum number for the entire wave, not just for a single configuration group or batch

This deliberate technical limit is designed to prevent performance bottlenecks, maintain system responsiveness, and ensure smooth configuration processes during critical implementation milestones.

How the Limit Works with the Merge Strategy

When you plan to merge configurations from the parallel line to the main line, you can scope a maximum of 5 countries/regions total in the parallel line before deploying them from the SAP Central Business Configuration workspace to the parallel customizing tenant (D.120).

Key Understanding: The 5-country/region limit becomes a total limit for the entire wave when you plan to merge. This is not just a per-batch limit. It’s the maximum you can merge from the parallel line to the main line in one implementation wave.

Why the 5-Country/Region Limit Matters

The recommended batch of 5 countries/regions serves three critical purposes that directly impact your implementation success:

Content Deployment Optimization: Large country/region volumes can strain content activation and transport processes, potentially causing failures or excessive processing times that disrupt project timelines. By limiting batches to 5 countries/regions, you ensure that the activation process completes reliably and within acceptable timeframes.
System Performance: Processing too many countries/regions simultaneously can create bottlenecks that affect system responsiveness during deployment and potentially impact other users working in the system. The 5-country/region limit prevents these performance degradations, ensuring consistent system behavior throughout your implementation.
Configuration Efficiency: Smooth processing during scope confirmation milestones reduces project risks by making each deployment cycle predictable and manageable. When deployments consistently succeed without performance issues, your project team can focus on configuration quality rather than troubleshooting technical problems.

Critical constraint: The limit becomes absolute during merge operations, where all parallel line configurations must be processed in a single wave.

Implementing the Multi-Wave Approach

The parallel line approach allows teams to work on new country/region configurations without disrupting live operations or ongoing customer adaptations in the main line. Here’s how to implement this strategy effectively:

Wave 1: Initial Implementation in the Main Line

Start by implementing your first group of countries/regions directly in the main line. Complete all configuration, testing, and validation activities, then proceed with your wave 1 go-live. This establishes your baseline configuration and validates your core setup.

Wave 2: Branch the Main Line and Configure in the Parallel Line

Step 1: Branch the Main Line to Set Up the Parallel Line

After wave 1 is live and stable, branch the parallel line through SAP for Me. This process replicates the main line business configuration comprehensively. It includes all business configuration data, organizational structures, and reference content in the parallel line workspace.

During branching, when you enable the Copy Master Data for Business Configuration Consistency option, not only configuration master data but an extensive list of configuration and master data tables are transferred to ensure consistency. This comprehensive data transfer is critical for maintaining configuration integrity across both lines. Be aware that business users are copied without business role assignments, so you’ll need to assign business roles after branching. Also note that the development and test systems in the main line will be temporarily locked during the branch process.

Step 2: Configure Wave 2 Countries/Regions in the Parallel Line

In your parallel line, configure the second group of countries/regions (wave 2). Limit this to a maximum of 5 countries/regions to avoid performance degradation and activation issues during the subsequent merge.

In SAP Central Business Configuration, scope the new countries/regions, configure organizational structures such as company codes, plants, and sales areas, and set up country/region-specific customization and localizations. Utilize the Configuration Localization Tool (CLT) if applicable for your implementation.

During wave 2 configuration in the parallel line, limit main line activities to minor adjustments and customer adaptations only. Avoid large configuration changes in the main line to prevent complex merge conflicts later. This discipline is critical for maintaining a clean separation between lines.

Step 3: Test and Validate in the Parallel Line

Transport your configuration from the parallel customizing tenant (D.120) to the parallel test tenant (T.120) using the Export Customizing Transports and Import Collection apps. Conduct thorough system integration testing (SIT), user acceptance testing (UAT), and end-to-end business process validation.

Use the test automation tool in your parallel test tenant to streamline testing activities. For more information, refer to Testing in SAP S/4HANA Cloud Public Edition.

Step 4: Rebase from Main Line

Before merging wave 2 into the main line, perform a rebase to synchronize any incremental configuration changes made in the main line since the branch or last rebase. Regular rebasing ensures your parallel line includes urgent fixes, legal updates, or small adjustments made in your productive main line.

In SAP Central Business Configuration:

Initiate a rebase from the workspace for the parallel line.
Review possible scoping or configuration conflicts. For more information, refer to Conflict Resolution.

In SAP S/4HANA Cloud Public Edition:

Review and activate the Customer staging entries in the Display Business Configuration Stagings app.
Resolve any conflicts using the compare & adjust tool in the Implementation Activities app.

Step 5: Run Pre-Merge Validation

Before initiating a merge, run the Simulation of Cross-Client Validation check in the Manage Check Runs for Business Configuration app. For more information, refer to Simulation of Cross-Client Validation.

Step 6: Merge Wave 2 to Main Line

Once validation is clean and the rebase is complete, initiate a merge from the SAP Central Business Configuration workspace in the parallel line. All wave 2 configurations, including organizational structures and related product configuration, are transferred to the SAP Central Business Configuration workspace of the main line, deployed to the customizing tenant (D.100), and immediately activated there.

The merge process includes:

SAP Central Business Configuration staging entries
Customer staging entries

Activate the Customer staging entries to complete the transfer to the main line. For more information, refer to Maintain Business Configuration Stagings.

Step 7: Verify Deployment and Activation in the Customizing Tenant (D.100)

Check that the wave 2 configuration has been successfully deployed from the SAP Central Business Configuration workspace for the main line to the customizing tenant (D.100) of the development system in the main line and activated there. Review the staging status in the Display Business Configuration Stagings app.

Step 8: Transport to Test System

Move the wave 2 configuration from the customizing tenant (D.100) to the test tenant (T.100) for comprehensive testing before forwarding it to production.

Step 9: Adaptations in the Main Line

Perform any necessary product configuration for wave 2 directly in the customizing tenant (D.100). Transport these refinements to the test tenant (T.100) for final validation. This ensures that all final adjustments are captured in your production path.

Step 10: Deploy to Production

At this stage, you have two options:

Immediate Go-Live: If wave 2 is ready for production, transport the full configuration to the production tenant (P.100) for cutover and go-live activities.
Consolidated Go-Live: Keep the validated wave 2 configuration on hold in the test tenant T.100 and merge it with subsequent waves for consolidated testing before moving to production. This provides flexibility to go live with multiple waves together rather than deploying each wave individually.

Wave 3 and Beyond: Repeat the Cycle

When you’re ready for wave 3 and beyond, you have two options depending on your organizational preferences and project requirements:

Aspect	Option A: Clean Slate Approach	Option B: Continuous Extension
Process	Delete the existing parallel line and request to branch from the main line again	Continue using the same parallel line
Configuration	Set up a fresh parallel line and configure the next 5 countries/regions	Add up to 5 more countries/regions to the existing parallel line
Best For	Large-scale implementations requiring strict governance	Smaller rollouts where team familiarity with existing structure adds efficiency
Advantages	Cleaner tenant environment, simplified governance, reduced complexity	Continuity, efficiency if team knows the existing structure
Recommended For	Implementations with many waves (for example, 40+ countries/regions)	Short-term extensions with limited additional waves

The choice between these options depends on your preference for tenant cleanliness, organizational complexity, and the total number of remaining countries/regions to implement.

Example: Implementing 40 Countries Using the Merge Strategy

To illustrate how the 5-country/region limit works in practice across a large-scale implementation, consider a scenario where you need to implement SAP S/4HANA Cloud Public Edition across 40 countries/regions. Using the merge strategy, you would structure your implementation as follows:

Wave 1: Foundation (Countries 1-5)
Implement the first 5 countries/regions directly in the main line. Complete configuration, testing, and validation. You can either go live with these countries immediately as your baseline or keep them in the test system for consolidated deployment with subsequent waves.

Wave 2: First Parallel Line Use (Countries 6-10)
After wave 1 is stable, branch the main line and configure the next 5 countries/regions in the parallel line. Test thoroughly in the parallel test tenant (T.120,) rebase to synchronize with any main line changes, then merge back to the main line. After successful testing in test tenant (T.100), decide whether to deploy to the production tenant (P.100) immediately or consolidate with additional waves before go-live.

Wave 3: Clean Slate (Countries 11-15)
Delete the existing parallel line and branch again from the main line (which now contains 10 countries/regions). Configure the next 5 countries/regions in the fresh parallel line, then follow the same rebase, merge, and test process.

Waves 4-8: Repeat the Cycle (Countries 16-40)
Continue with this pattern: delete the parallel line after each successful merge, branch again, configure the next batch of 5 countries/regions, and merge. You maintain flexibility to go live with selected wave groupings rather than deploying each wave individually to production. Each wave builds on the consolidated configuration in the main line, ensuring a single source of truth while respecting the 5-country/region merge limit.

Timeline Considerations

When planning your multi-wave implementation, keep the following timing factors in mind:

Each wave requires time for branching (8-10 hours typical), configuration, testing, rebase, merge, and deployment
Plan for adequate time between waves to ensure stability and allow for thorough validation
The clean slate approach (Option A from Wave 3 onwards) is recommended for large-scale implementations to maintain system cleanliness and reduce complexity

This systematic approach allows you to scale to any number of countries/regions while maintaining the integrity and performance benefits that the 5-country/region limit provides.

Best Practices for Success

Several key practices will significantly improve your success with parallel line implementations:

Sequential Wave Implementation: After completing one wave of up to 5 countries/regions, you can immediately begin planning and configuring the next wave. There’s no waiting period required between waves, which means you can maintain project momentum while respecting the technical constraints.
Main Line Discipline: During parallel line configuration periods, keep main line changes minimal to simplify rebase and merge operations. This discipline prevents configuration conflicts and makes synchronization between lines much smoother. Reserve your main line for urgent fixes and critical updates only while major implementation work happens in the parallel line.
Thorough Testing: Always validate configurations in the test tenant (T.100) or parallel test tenant (T.120) before moving to production. Never skip testing phases, even when you’re confident in your configuration. The test phase catches issues before they impact production and provides a safe environment for end-to-end process validation.
Regular Rebasing: Before every merge, perform a rebase to ensure your parallel line includes the latest main line updates. This practice minimizes merge conflicts and ensures consistency between your configuration tracks.
Clear Wave Planning: Define your country/region groupings upfront to optimize the parallel line lifecycle. Understanding which countries/regions will be implemented together, and in what sequence, allows you to plan resources, manage stakeholder expectations, and structure your project timeline realistically. Remember that the 5-country/region limit is absolute for merge operations, so plan your waves accordingly.

Conclusion

The merge strategy provides centralized governance and a single source of truth for your global implementation while leveraging the isolation and safety that the parallel line provides during configuration and testing. This transforms complex multi-country/region rollouts from overwhelming challenges into manageable, systematic processes that can be repeated reliably across multiple implementation waves.

To execute this strategy successfully, focus on the following critical practices:

Understanding the 5-country/region deployment limit as a strict per-wave constraint when merging configurations back to the main line
Branching strategically to create isolated workspaces for new country/region groups
Configuring efficiently within the 5-country/region limit to optimize performance
Rebasing regularly to stay synchronized with main line updates
Merging carefully after thorough validation to maintain configuration integrity
Minimizing main line changes during parallel line configuration periods
Defining country/region groupings upfront to plan resources and timelines realistically
Validating thoroughly in the parallel test tenant (T.120) before merging and again in the test tenant (T.100) before production deployment

By following these practices and respecting the technical constraints, organizations can scale globally while maintaining system performance and configuration quality.

Have you used the parallel line for multi-country/region implementations? I’d love to hear about your experiences and any lessons learned in the comments below!

Advanced Success Plan im Detail - Mehr Wert aus SAP-Cloud-Investitionen ziehen

2026-04-16T11:40:39.735000+02:00

Im zweiten Teil der Webcast-Serie im April 2026 zu den SAP Success Plans stellte Jesper Waaben, Chief Product Owner für die Advanced Success Plans im Bereich ERP, den Advanced SuccessPlan exemplarisch vor. Während der erste Webcast den Gesamtüberblick lieferte, ging es hier um konkrete Services, neue Formate wie Success Packs und die Frage, was sich gegenüber dem Vorgänger Preferred Success tatsächlich geändert hat. Anbei die Zusammenfassung.

Was bleibt, was ist neu im Advanced Success Plan von SAP?

Waaben machte transparent, wo der Advanced Success Plan auf Bewährtem aufbaut und wo er Neuland betritt.

Was bleibt:

Die proaktive Partnerschaft, die technische und funktionale Unterstützung sowie die Release Guidance. Kunden, die Preferred Success kennen, werden viele Elemente wiedererkennen.

Was neu ist:

Hands-on Activation: Der wohl greifbarste Unterschied. Unter Preferred Success durften SAP-Experten nicht in die Kundensysteme eingreifen – alles war „hands off". Jetzt können sie neue Funktionalitäten direkt im System aktivieren und eine erste, leichte Konfiguration anleiten. Das muss natürlich mit dem Projektteam und gegebenenfalls dem Implementierungspartner abgestimmt werden.
KI-gestützte Guidance: Eine in SAP Cloud ALM integrierte Lösung analysiert automatisch Systemdaten – insbesondere im Bereich SAP S/4HANA Private und Public Cloud – und leitet daraus Empfehlungen für Prozessverbesserungen, Funktionalitäten und Systemlandschaften ab.
Abdeckung der gesamten Business Suite: Der Advanced Plan deckt nun End-to-End-Szenarien über die gesamte SAP-Lösungslandschaft ab.
Verbesserte SLAs: 50 % schnellere Initial Response Times und beschleunigte Corrective Actions gegenüber dem Foundational Plan.

Die fünf Säulen des Advanced Success Plans

Der Advanced Plan ergänzt den Foundational Success Plan um fünf konkrete Bereiche:

1. Innovation and Adoption Guidance

SAP-Experten analysieren gemeinsam mit dem Customer Success Manager spezifische Funktionalitäten und Prozesse in der jeweiligen Lösung – auch funktionalitätsübergreifend. Daraus entstehen Empfehlungen: Welche Funktionalitäten lassen sich verbessern? Welche neuen Features sollten aktiviert werden?

2. Activation and Optimization Services

Hier werden die identifizierten Empfehlungen umgesetzt. SAP-Berater gehen ins System, aktivieren Funktionalitäten und leiten erste Konfigurationsschritte an. Waaben betonte: Die eingesetzten Experten sind erfahrene SAP-Berater aus dem Projektgeschäft – keine reine Support-Organisation.

3. KI-gestützte Qualitäts- und Prozess-Guidance

Die in Cloud ALM integrierte KI-Lösung nutzt gesammelte Systemdaten, um Erkenntnisse und Empfehlungen zu generieren. Voraussetzung: Cloud ALM muss aktiv genutzt werden, um den vollen Mehrwert zu realisieren.

4. Orchestrierung des Success Plans

Ein Punkt, den Waaben als häufig unterschätzt bezeichnete. Customer Success Manager und Success Plan Manager sorgen dafür, dass die richtigen Services zum richtigen Zeitpunkt eingesetzt werden. Das Ziel: weg vom Gießkannenprinzip, hin zu gezieltem Service-Einsatz. Die Orchestratoren können zu jedem Thema in einer Lösung die passenden SAP-Experten hinzuziehen.

5. Enhanced Support SLAs

Konkret: 50 % schnellere Initial Response Times und beschleunigte Corrective Actions – für Kunden mit geschäftskritischen Systemen ein relevanter Faktor.

Abbildung: Gegenüberstellung des Advanced & Foundational Success Plan

Service Maps und Success Packs: Komplexität beherrschbar machen

Service Maps pro Lösung

Für jede SAP-Lösung – ob S/4HANA Public, S/4HANA Private, Supply Chain, Ariba, SuccessFactors, CX oder Business Data Cloud – gibt es eine eigene Service Map. Diese zeigt, welche Services konkret verfügbar sind: von fokussierten funktionalen Services bis hin zu transformativen Formaten wie dem Cloud Mindset Workshop.

Über alle Lösungen hinweg stehen die sogenannten Success Expert Services zur Verfügung:

Value Management: Aufbau einer Baseline für Wertverfolgung über den gesamten Lösungs-Lifecycle
Service Planning: Workshop-basierte Zuordnung der Kundensituation zu passenden Services, daraus entsteht ein konkreter Serviceplan
Adoption Checkpoint: Experten prüfen die Lösung auf ungenutztes Potenzial und neue Funktionalitäten
Innovation Checkpoint: Bewertung neuer Releases und Innovationen – einschließlich KI-Funktionen – für den konkreten Kundenkontext

Success Packs: Thematische Bündelung

Mit wachsendem Service-Volumen steigt die Komplexität. SAP begegnet dem mit Success Packs – thematischen Bündelungen zusammengehöriger Services. Beispiele:

S/4HANA Public: Implementation Essentials, Finance Foundation, Finance Expansion (mit Services wie Advanced Financial Closing, Advanced Cash Operations, Group Reporting)
S/4HANA Private: Clean Core, Business AI CoE, Finance Optimization, SAP Methodology
Supply Chain/IBP: APO Transformation, Sales and Operations Planning, Demand Planning, Inventory Optimization
Ariba, SuccessFactors, CX, BTP, Business Data Cloud: Jeweils eigene Success Packs

Grafik aus dem Webinar: SuccessPack am Beispiel von CloudERP Public.

Kunden müssen nicht alle Services eines Packs buchen. Die Packs dienen als thematische Orientierung und heben das Gespräch auf die Ebene von Prozessen und Geschäftsthemen statt einzelner Service-Tickets.

Business AI: Strukturierte Begleitung über alle Stufen

Das Thema KI zog sich als roter Faden durch den Vortrag. Jesper Waaben zeigte, wie die drei Plan-Stufen beim AI-Rollout ineinandergreifen:

Foundational: Erste Guidance-Services im Self-Service-Format
Advanced: Expert Advisory zu Governance, Compliance und Clean Core für KI. Workshops zur Identifikation von KI-Use-Cases. Aktivierung von Joule, Agents und intelligenten Apps. AI Business Readiness Workshops, um die Organisation vorzubereiten
Max: Umsetzung identifizierter Use Cases in Prototypen und Individualentwicklungen

Die Services vom Advanced & Max Plan lassen sich einzeln buchen oder als durchgängige Begleitung auf der KI-Reise nutzen.

Darstellungen aus dem Webinar die zeigt, wie die Success Pläne bei der AI Adoption helfen.

Marktvalidierung: IDC und Forrester bestätigen den Ansatz

Zwei unabhängige Analysen von IDC und Forrester – durchgeführt mit Fokus auf Preferred Success aber durchaus vergleichbar – bestätigten drei zentrale Erkenntnisse:

Zugang zu SAP-Expertise ist geschäftskritisch – bei den hohen Investitionen in SAP-Systeme brauchen Kunden direkten Zugang zu Herstellerwissen
Geschäftsanwender erwarten schnelleren Nutzen aus IT-Investitionen, was den Druck auf IT-Abteilungen erhöht
KI verändert Softwarelandschaft und Investitionshorizonte radikal – Kunden suchen gezielt Unterstützung bei der Einordnung

Kunden mit Success Plans kommen laut den Analysen schneller und sicherer ins Ziel mit ihren Projekten. Details zu den Studien finden sich hier auf der sap.com Seite zu den Advanced Success Plans.

Aussagen aus dem Webinar

Anbei einige Aussagen von Jesper, die ich pointiert fand.

„Früher durften wir mit Preferred Success nicht in die Systeme reingehen. Jetzt dürfen wir mit Hands-on Activation neue Funktionalitäten aktivieren und eine leichte Konfiguration anleiten."
„Mit den Success Plans kriegen Sie SAP an die Hüfte geschnürt – und Sie können, wenn Sie wollen, einfach von der Hüfte einen Experten hochziehen."
„Ich habe in den letzten Jahren sehr oft gesehen, dass wir Services pushen, um einfach Services zu pushen – aber nicht notwendigerweise die richtigen. Diese Orchestrierung ist nicht zu unterschätzen."
„Wir können uns nicht leisten, KI nicht anzugehen. Und da kann man die Success Plans als Unterstützung und Begleitung dafür benutzen."
„Wir haben schon in den ersten zwei Monaten mehr als 200 Kunden, die Advanced Success Plans gekauft haben."
Praktische Tipps für die Umsetzung
Cloud ALM aktiv nutzen: Die KI-gestützte Guidance setzt voraus, dass Cloud ALM im Einsatz ist. Wer hier früh investiert, profitiert stärker von den analytischen Services.
Success Packs als Einstieg nutzen: Statt einzelne Services aus dem Katalog zu wählen, bieten die thematischen Bündelungen eine bessere Orientierung – etwa „Clean Core" oder „Finance Expansion".
Orchestrierung ernst nehmen: Nutzen Sie den Customer Success Manager aktiv, um die richtigen Services zur richtigen Zeit zu identifizieren. Nicht die Menge der gebuchten Services zählt, sondern deren Passung.
Hands-on Activation mit dem Projektteam abstimmen: Die neue Möglichkeit der direkten Systemaktivierung ist wertvoll, sollte aber immer in Abstimmung mit internen Teams und Implementierungspartnern erfolgen.
KI-Readiness als Einstiegsthema wählen: Die AI Business Readiness Workshops im Advanced Plan helfen, die Organisation vorzubereiten, bevor konkrete Use Cases umgesetzt werden.
Value Management von Anfang an einsetzen: Die Baseline für Wertverfolgung früh zu legen, macht den Nutzen der Success Plans messbar und argumentierbar.
Resümee
Der Advanced Success Plan ist die konsequente Weiterentwicklung von Preferred Success – mit dem entscheidenden Unterschied, dass SAP-Experten jetzt direkt im System arbeiten dürfen. Die Einführung von Success Packs als thematische Bündelungen adressiert das Komplexitätsproblem eines wachsenden Service-Portfolios. Mit bereits über 200 Kunden in den ersten zwei Monaten zeigt sich, dass der Markt das neue Modell annimmt.
Die durchgängige KI-Integration über alle Plan-Stufen hinweg positioniert die Success Plans als zentralen Baustein für Unternehmen, die ihre SAP-Landschaft zukunftsfähig aufstellen wollen. Jesper hat exemplarisch schön gezeigt, wo der Advanced Success Plan einen Unterschied macht - auch bei AI.
Was mich persönlich freut: Das Thema Lernen und Adoption wird nicht als Nebenschauplatz behandelt, sondern ist strukturell in die Success Plans eingebaut – von den Learning Journeys im Foundational Plan bis zur AI Business Readiness im Advanced Plan.
Wo finden sich weiterführende Informationen zu den Success Plänen? Im Überblicks Blog sammeln wir Links und Informationen: SAP Success Pläne - Der Guide zum neuen SAP Support und Service Modell 2026
Zusätzlich ist am 25.06. ein Vor-Ort Event geplant in Walldorf – Details finden Sie hier.
FAQ
Was unterscheidet den Advanced Success Plan von Preferred Success?
Der Advanced Plan baut auf Preferred Success auf, bringt aber wesentliche Erweiterungen und Neuerungen: Hands-on Activation erlaubt SAP-Experten erstmals, direkt in Kundensystemen Funktionalitäten zu aktivieren und leichte Konfigurationen anzuleiten. Hinzu kommen KI-gestützte Guidance über Cloud ALM, verbesserte SLAs und eine breitere Abdeckung der gesamten Business Suite. Interessant ist auch zu wissen, dass Elemente von Preferred Success Expanded Edition beim Advanced Plan dabei sind - was früher eine noch teurere Edition war. Damit bekommen Kunden mehr für weniger Kosten.
Gibt es eine maximale Anzahl an Beratungstagen oder Tickets im Advanced Plan?
Nein. Die Anzahl der Services im Advanced Plan ist nicht limitiert. Kunden können so oft und so viele Services buchen, wie sie benötigen.
Was sind Success Packs?
Success Packs sind thematische Bündelungen zusammengehöriger Services – etwa „Clean Core", „Finance Expansion" oder „Demand Planning". Sie dienen als Orientierungshilfe und heben das Gespräch von einzelnen Service-Tickets auf die Ebene von Geschäftsthemen und Prozessen. Kunden müssen nicht alle enthaltenen Services buchen.
Welche Rolle spielt der Implementierungspartner im Success-Plan-Konzept?
SAP tritt mit den Success Plans nicht in Konkurrenz zu Implementierungspartnern. Die Hands-on Activation muss mit dem Projektteam und gegebenenfalls dem Partner abgestimmt werden. SAP liefert Expertise zu Best Practices, Standards und Architektur – Implementierung kann beim Partner bleiben.
Muss ich Cloud ALM nutzen, um vom Advanced Plan zu profitieren?
Für die volle Nutzung der KI-gestützten Guidance ist Cloud ALM die Voraussetzung. Die übrigen Services – Activation, Adoption Guidance, Expert Advisory – sind davon unabhängig nutzbar.
Welche Experten liefern die Advanced-Services?
Die eingesetzten Experten sind erfahrene SAP-Berater aus dem Projektgeschäft und erfahrene Customer Success Experten, die Services für Advanced und teilweise Max liefern – keine reine Support-Organisation.
Für welche SAP-Lösungen gibt es Service Maps?
Service Maps existieren für S/4HANA Public, S/4HANA Private, Supply Chain/IBP, Ariba, SuccessFactors, Customer Experience (Sales & Service Cloud, Commerce Cloud, Marketing Cloud), BTP und Business Data Cloud.
Wie unterstützt der Advanced Plan konkret bei Business AI?
Im Advanced Plan stehen Expert Advisory zu KI-Governance und Compliance, Workshops zur Identifikation von KI-Use-Cases, AI Business Readiness Workshops sowie die Aktivierung von Joule, Agents und intelligenten Apps zur Verfügung. Er unterstützt somit entlang jeder Stufe Ihrer AI Adoption. Für die Umsetzung identifizierter Use Cases in Prototypen ist der Max Plan erforderlich.
Gibt es bereits Erfahrungswerte aus dem Markt?
Ja. In den ersten zwei Monaten nach Launch haben bereits mehr als 200 Kunden den Advanced Success Plan gekauft. Unabhängige Analysen von IDC und Forrester bestätigen, dass Kunden mit Success Plans schneller und sicherer ihre Projektziele erreichen.

SAP S/4HANA Cloud Public Edition 2602.2: Final What's New & Product Assistance available

2026-04-16T13:53:30.898000+02:00

With immediate effect, the final What's New information for SAP S/4HANA Cloud Public Edition 2602.2 is now available.

To access the final What’s New information, please use the What’s New Viewer. In addition, the final Product Assistance (aka Application Help) for SAP S/4HANA Cloud Public Edition 2602.2 is available. Please use the SAP S/4HANA Cloud Public Edition Help Portal page to access it.

For you as a customer, we recommend to also use the Release Assessment and Scope Dependency (RASD) tool. The Release Assessment and Scope Dependency (RASD) tool provides you with a personalized and tailored view on What’s New information based on the activated and used scope within your system. The information for SAP S/4HANA Cloud Public Edition 2602.2 will be available in RASD within the next few days. A valid Customer S-user ID is required for login. We recommend to use RASD to prepare for upgrades and updates of your system and to focus on the new and changed features that are relevant for you as a customer.

You can use the commenting feature for What’s New. With this feature, authors can evaluate your feedback and incorporate it into the documentation, if needed. We hope that by opening this channel of communication, we can learn how to further improve our What’s New content for you. To use this feature, you need to be logged into the Help Portal. The feature will only be available in the English version of the documents. To learn more about how the feedback process works in SAP Help Portal, see Giving Documentation Feedback.

Third-Party Payments with SIPO (SAP S/4HANA Cloud Public Edition)

2026-04-16T16:02:56.020000+02:00

This blog post introduces business scenarios and explains how to process payment with SIPO in Czech Republic for SAP S/4HANA Cloud public edition. 

SIPO (Soustředěné Inkaso Plateb Obyvatelstva) that is used for direct debit of multiple payments through the Czech Post’s system. It is a national payment aggregation system operated by the Czech Post. This business concept relates to payments through a third party. 

Business Scenarios 

Let’s start with the parties involved in SIPO payments.  

Customers that have SIPO connection number pay on a regular basis 
Service providers that offer services of utilities, multimedia, or internet, send payment requests to SIPO 
Czech Post Office, or the SIPO operator, collects all payment requests, aggregates them into one payment, and distribute paid money by customers to service providers 
Banks that serve as payment channels carry out direct debit from bank accounts

There are two business scenarios of payments involving SIPO: 

Scenario 1: You, as a service provider, post receivable items. After executing a payment run, you send a SIPO file, as an outgoing file, to the Czech Post for informing the customers to pay.  

Scenario 2: Continuing with scenario 1, you, as a service provider, want to clear the open items by processing incoming SIPO files after your customer completes the payment. 

Prerequisites 

Bank Account Settings  

Since the payments with SIPO order are not directly paid out from the payer's bank account, instead it is paid out from the post office, it is necessary to create a fictive bank account and account ID for the post office.  

Open the Manage Bank Accounts app.  

For your company code, create a fictive Bank Account and Account ID for the Czech Post.

Define Parameters for Paying Out   

Since payment is carried out through the third party (Czech Post),  you need to identify which payee whom the post office pays.   

In the Define Parameters for Foreign Payment Transactions (ID: 101953) configuration to fill the service provider's SIPO number in the Customer number field.  

Define Payment Methods 

Open the Define Payment Methods (ID: 101952) to create a payment method or use the pre-delivered format - CZ_PSTLPAYMENT_SIPO as the payment medium format for Czech SIPO payments.

Define Payment Lot Specifications  

Open the Define Payment Lot Specification activity (ID:107255).  

Select the format type Czech Republic: Postal Payment Item (SIPO file) (CZ-POSTAL-PAYMENT-ZA) and complete the Bank statement settings section.  
Note: It is not required to configure the Czech Republic: Postal Payment Header (SIPO file) (CZ-POSTAL-PAYMENT-PZ).

Define Interpretation Rules for Note to Payee   

Open the Define Interpretation Rules for Note to Payee activity (ID: 103949) to assign keywords.

Procedure

Processing SIPO Outgoing Payment Files 

You post contract accounting receivable items. 
Execute a payment run. The payment order then is created. 
During the payment run, the system uses the payment format CZ-POSTAL-PAYMENT-SIPO to generate the payment file for the Czech Post. 
You then send the payment file to Czech Post. 
Czech Post informs the customer to conduct the payment.

Processing SIPO Incoming Payment Files

After the customer pays, the Czech Post sends back the SIPO files.  

The SIPO files contain the following files: 

SIPO header file – Includes the total settlement amount that matches the bank statement of the incoming payment

SIPO item file – lists the clearing of open receivable items per customer’s individual SIPO number

You have to import both files in the Manage Incoming Payment File (3rd-Party Payments) app (F1680).  

Open the Manage Incoming Payment File (3rd-Party Payments) app (F1680). 
- Select Import and choose Third-party Payment.
- Select Czech Republic: Postal Payment Header (SIPO file) and upload the SIPO header file. 
- Repeat the same operation and upload the Czech Republic: Postal Payment Item (SIPO file). 
Open the Process Imported Third-Party Payments app (F9000) to schedule a run. 
- Select Third-Party Payment: Transfer data as the job template.  
- In the Parameters, select Czech Republic: Postal Payment Item (SIPO file) (CZ-POSTAL-PAYMENT-ZA) as a format type.  
  Note: When processing the imported file, you only need to process the item files. (Header files are not required.) 
- Schedule a run and you can see that the payment lot number is created in the log .
  If you select the Post Lot check box and you can directly process the payment order lot without additional operation. 
Run the payment lot and you clear the open items. Use the payment lot and process it in the Process Payment (Order) Lot app and clear open items of the customer. If you did not select the checkbox in the previous step.

Is this blog post useful to you? Leave your comments below to let us know your thoughts. 

New SAP Signavio Value Accelerators: Process Landscape Design & Fit-to-Standard in SAP S/4HANA Cloud

2026-04-17T09:49:58.938000+02:00

We are excited to announce two new additions to the SAP Signavio Value Accelerator Library:

Process Landscape Design & Fit-to-Standard in SAP S/4HANA Cloud Private Edition
Process Landscape Design & Fit-to-Standard in SAP S/4HANA Cloud Public Edition

These accelerators bring a harmonized process structure that connects the SAP Reference Business Process Architecture with SAP S/4HANA best practices ready to use out of the box. They are built for everyone working on transformation, running Fit-to-Standard workshops, or who’s simply looking to enrich their Signavio workspace with first process content to get started.

Key highlights include:

SAP Reference Business Process Architecture including specific end-to-end variants
Out-of-the-box synchronization with SAP LeanIX thanks to renewed structure
Mapping to S/4HANA best practice diagrams
Dictionary entries to capture information structurally

You can find both accelerators directly in your SAP Signavio workspace by opening the Value Accelerator Library (VAL) and searching for "Process Landscape Design".

We have put together more information and a step-by-step installation and setup guide. Check it out here.

If you have any questions, feel free to reach out to your BTM contact.