Hello SAP Community,

We're excited to share a new feature in the EFD-Reinf report for Brazil, specifically for users of the Statutory Reporting framework: Mass Rectification for the R-4000 Series. This enhancement is set to transform how you manage corrections for the EFD-Reinf R-4000 series.

Introducing Mass Rectification in R-4000 Series

With the new Mass Rectification functionality, users can now easily generate rectification files for multiple events at once during the Correction Phase of your reporting tasks. This means faster and more efficient handling of corrections when you need to rectify several events for a given company and branch.

How It Works

When running the Brazil EFD-Reinf Periodic Files task, you'll notice a new Run Mass Rectification checkbox in the selection criteria popup, as seen below:

Here’s what you need to know about the options:

• File ID for Rectification:
  • When a specific File ID is entered in this field, the system will create the rectification file only for the provided File ID (i.e., only the selected event will be corrected). 

• Run Mass Rectification Checkbox:
• If you select the Run Mass Rectification flag without entering a File ID, rectification files will be generated for all eligible R-4000 series events for the specified Company Code and Business Place.
• This is especially useful when multiple corrections are needed across several events, saving you significant manual effort!

Additionally, you can schedule or run this task immediately with the standard Run Options for background processing that is recommend for large volume of files, making it even easier to fit rectification into your processes.

Why Use Mass Rectification?

• Faster Corrections: Generate rectification files for many events in a single run.
• Greater Flexibility: Correct either specific events by ID or all relevant events for your company and branch at once.
• Improved Compliance: Stay up to date with changing requirements and ensure your data is always accurate.

Learn More

To explore this new functionality and stay updated on further enhancements, check out these SAP Help Portal resources:

• Document and Reporting Compliance
• EFD-Reinf Report

We value your feedback!
If you have any questions or suggestions for future topics, please leave your comment below.

See you in the next post!

Statutory Reporting for Brazil Team

Welcome to another series mainly focusing on SAP PaPM Cloud Universal Model (UM) and SAP Analytics Cloud (SAC) integration.

Some time back, I shared how to read and write data to SAC using the SAP Profitability and Performance Management Cloud Standard Model (SAP PaPM Cloud SM). Now, as we prepare a new “how-to” guide focused on the SAP PaPM Cloud UM integration with SAC, it’s time to set the stage with some key prerequisites.

In this post, I’ll walk you through the high-level steps for consuming data both to and from SAP Analytics Cloud using the SAP PaPM Cloud UM.

Let’s breakdown the topics into four scenarios:

Inbound means any data going in to SAP PaPM UM from SAC
Scenario 1. SAP PaPM UM pulling data from SAC through SAC Model Connections.

Outbound means any data going out of SAP PaPM UM to SAC
Scenario 2. SAP PAPM UM pushhin Data to SAC through SAC Model Connection

Scenario 3. SAC consuming data from SAP PaPM UM through Odata Connection (Z-Artifacts)

Scenario 4. SAC consuming data from SAP PaPM UM through HANA Live Connection
Note: Auto Generated Calculation Views is not available yet in Universal Model.  There could be a way to do this in BYOD Plan with the use of Business Application Studio where you manually create CV's out of UM's Z Artifacts then share it with SAC.

Prerequisites:

1. You are subscribed to SAP PaPM Cloud where Universal Model is enabled see Subscription section.
2. SAC Model available for reading and writing purposes.
3. You are able to perform Modeling in Universal Model.
4. You are familiar with How SAP Analytics Cloud (SAC) pulls data from SAP Profitability and Performance Management Cloud (SAP PaPM Cloud)
   
   

SCENARIO 1: SAP PAPM UM Consuming Data from SAC through SAC Model Connection

Following the help portal documentation on the inbound integration steps with SAC Model. let’s proceed:

a. Create BTP Destination. As guidance, refer to the steps we did from previously released blogpost.

Bear in mind that additional properties such as requestHeaders is not mandatory anymore.
In addition, SAC Oauth Client created in SAC Administration > App Integration should have both Data Import (Writing back to SAC) and Data Export (Reading from SAC) Service Access.

b. Prepare an UM Environment containing an explicit field serving as Default Key Field. It can be String or UUID type.

In addition, SAC Model containing sample data sets for data consumption purposes should be available.

c. Create SAC Model Connection. For more info of what each attribute means, see help portal documentation.

d. Once connection is created, go on Edit Mode and add the field to the Model you want to make use of. In this case, I’d like to only have FactData Model therefore I will unselect the other Models.

e. Choose Sync Model for the FactData to appear in the list of Functions as a Model Entity derived from SAC Model Connection. Create a Reader on top of Model Entity to buffer the data from the source SAC Model. Please note that in the reader function, you need to explicitly add the fields you want to have data of. Else, it will not be populated. 

f. Activate the Environment, Run the Reader and verify data in Model Entity.

Success! Data can now be used for further processing in UM.

SCENARIO 2: SAP PAPM UM Writing Data to SAC through SAC Model Connection

Assuming that you have performed already some processing in UM e.g. Calculations, and you want to write data back to SAC Model. It should be possible by following the steps below:

a. If you need another SAC Model to write onto, you need to reperform SCENARIO 1 to create a Model Entity which will now serve as an output table. I named it differently, created from another connection, to distinguish it as Outbound (OB) FactData.

b. Perform additional processing of Initial FactData as needed. In this case, dummy calculations has been performed e.g. multiply dividend based on some factor.

c. Create a writer function and map the fields.
     Note: You may use other writer types depending on your use case.


d. Once done, Activate the Environment, Run the Writer and verify data in SAC Model.

Data has now been written back to SAC Model.

SCENARIO 3: SAC consuming data from SAP PaPM UM through Odata Connection (Z-Artifacts)

Universal Model API’s are laid out already in the Business Accelerator Hub which everyone can make use of. In this scenario though, we will make use of Universal Model’s Z Artifacts using Activity API as starting point serving as a viable alternative option as data source for SAC.   

The steps doesn’t differ much with how it was written in Odata Connection section of How SAP Analytics Cloud (SAC) pulls data from SAP Profitability and Performance Management Cloud (SAP PaPM Cloud)

Notable adjustments are with:
a. UM relevant Authorities for API Access which is equivalent to the Application Roles. As a hint those with “.ace” are for UM and needs to be added as part of Service Instance Creation. Example JSON is already added which you can make use of. Security-wise, you may decide to include all or only specific roles here signifying what your service key credential user can only do.

b. Universal Model already offers Activity Data URL,  see Data URL , which contains Odata Endpoint of the Model Entity function used within an Activity. This endpoint would contain then the path to which the data are stored as odata.

The above representation is important to know where the root of Data Service URL endpoint for Universal Model comes from.
In the end, your to be Data Service URL would be:

Once Odata Connection is setup, Dataset from a datasource can now be checked where you will find the UM’s Z-Artifact relevant equivalent data.

That's about it. Hope you gained some more knowledge today on the basic integration setup of SAP PaPM UM with SAP Analytics Cloud. Try it out, tweak it and make it your own. Best of luck!

SAP CPQ (Configure Price Quote) is a software solution that allows customers to configure products and services, set up pricing and discounts, generate accurate quotes, and create custom proposals. While offering a great deal of functionality out-of-the-box, SAP CPQ can also be easily extended and customized, to support custom, and often unique, business processes and procedures.

One way in which SAP CPQ can be extended is by developing an external extension application that is integrated with SAP CPQ using standard integration mechanisms (REST APIs, events, webhook notifications etc.). This approach, also known as side-by-side extensibility, has several distinctive benefits: increased flexibility in terms of technological choice, possibility of using dedicated resources, better performance due to limited scope and many more.

This series of blog posts will explore several ways for building and deploying side-by-side extensions of SAP CPQ, using the SAP BTP (Business Technology Platform) and various tools offered by that platform.

• Building Low-code/No-code SAP CPQ extension using SAP Build Process Automation (Part 1)
• Building Low-code/No-code SAP CPQ extension using SAP Build Process Automation (Part 2) - this post

Overview of the solution

SAP Build Process Automation is a low-code/no-code solution that enables you to automate workflow processes without writing a single line of code, just by using a graphical, drag-and-drop editor. It is an ideal solution for developing both simple extensions, as well as complex business process applications. To learn more about SAP Build Process Automation, please check the official documentation.

Overview of the solution (including Part 1 and Part 2)

In the first blog post, we have described how you can invoke SAP Build Process Automation process from SAP CPQ. In this second post, we will demonstrate how to invoke SAP CPQ API from SAP Build Process Automation project using the concept of SAP Build Actions. Actions encapsulate the details of a call to an external API, including the endpoint location, input and output parameters.

For the Action to be able to call, in our case, SAP CPQ API, it needs the information about the location of the SAP CPQ instance, as well as details about the authentication employed (authentication mechanism, credentials, etc.). This information is defined in an SAP BTP Destination, and used in the runtime by the Action when invoking an API.

Example SAP Build Process Automation process used in this blog post series

As an example extension application that we want to integrate with SAP CPQ, we are going to use a simple business process involving legal check of created quotes. The process triggers manual check based on the market associated with the quote, and allows the responsible persons to decide whether quote should be accepted or rejected from the legal perspective. The decision then triggers invocation of appropriate custom CPQ action, something that is described in this blog process.

Please note that, in this blog post, I assume that you are familiar with the basics of using SAP Build Process Automation. If that is not the case, please check the excellent "Creating Processes and Automations with SAP Build Process Automation" learning journey at SAP Learning.

Defining a CPQ Action project in SAP Build

To define a new Action project for invoking SAP CPQ API, navigate your SAP Build Process Automation instance and select SAP Build Lobby -> Connectors -> Actions -> Create.

The easiest way to consume an SAP CPQ API is to use the SAP Business Accelerator Hub, which contains API definitions for many SAP applications, including the SAP CPQ. Select API Specification -> SAP Business Accelerator Hub.

Enter the keyword identifying the SAP CPQ API that you want to consume (for example, if you are interested in Quotes API, enter the quote keyword). Select the SAP CPQ API that you want to consume.

Next screen contains the list of actions available in the selected SAP CPQ API. Click Next.

Here, you can customize Action project name and description or use the defaults. Click Create.

In the next screen, you are presented with the list of all available actions in the selected SAP CPQ API. Select the desired actions and click Add.

Before being able to use the selected actions in your SAP Build Process Automation project, you need to release and publish the Action project. First, click on Release button, optionally enter the description and click Release again. After that, select Publish -> Publish.

Calling the CPQ API from SAP Build Process Automation project

After publishing the Action project, you can use selected SAP CPQ API actions in your SAP Build Process Automation project, for example, as a new step in the process. To do so, click on the + button (Add Process Step) at the place in the process where you want to invoke an SAP CPQ API.

Then select Action -> Browse All Actions and select the desired action (from previously created and published Action project). Then click Add button.

Next, click on Destination Variable -> Create Destination Variable and specify an Identifier and Description of the variable that will hold a reference to the SAP BTP Destination pointing to your SAP CPQ instance (created and explained later in this blog post). Once you are ready to publish and deploy your SAP Build Process Automaton project, you will associate this variable with the concrete SAP BTP Destination (also explained later). For now, you can specify any value as an Identifier, preferable the one that makes it easy to understand its purpose (for example: CpqDestination). You can reuse the same variable for all the SAP CPQ actions that you use in your project.

Most of the SAP CPQ API actions define a set of input values (required and optional input parameters) and an output value (result of the API call). If the action you are planning to use has the required inputs, you can specify them by selecting the Inputs tab and choosing the input value (for each input) from the list of potential values (for example, an output from one of the previous steps) in the Process Content pane.

You can consume the output of the SAP CPQ API actions in the same way as you would consume output of any other process step in the project: you can display it on the form, use it as input parameter for other actions etc.  In our example, a form is the step in the process that needs the information from the output, so we can use action's output fields as the values of the input fields of that form by selecting them in the Process Content pane (under the Process Inputs section). These fields (and the represented structure of the output) correspond to the response of the call to the related SAP CPQ API endpoint.

Before being able to deploy your SAP Build Process Automation project, you first need to define an SAP BTP Destination pointing to the SAP CPQ instance of your choice.

Defining a destination in SAP BTP

To connect SAP Build Process Automation instance with an SAP CPQ instance, it is necessary to define a new Destination in the SAP BTP subaccount where the SAP Build Process Automation instance is located. As a first step, a new Trusted Application (OAuth 2.0 client application) in SAP CPQ should be created. To add a new Trusted Application, in the SAP CPQ setup go to Security -> Trusted Applications, then click on Add New -> Add new Trusted Application:

• Specify a descriptive Name for this trusted application (client)
• Note the Client ID and Client Secret that you will use in the next step
• Enable Client Credentials Grant and
• Specify a (preferably technical) user that will be used when accessing the instance.

It is also possible to use other OAuth 2.0 grant types in this case - for more information, please check SAP CPQ documentation and SAP BTP Connectivity documentation (for example, if you want to use the principle propagation option when accessing the SAP CPQ API, you can use SAML 2.0 assertion grant type, as described in SAP CPQ documentation, SAP BTP Connectivity documentation, and in this blog post). Please note that it is generally recommended to define a separate Trusted Application per client application (application accessing the SAP CPQ API), and to enable only required OAuth grant types.

After configuring Trusted Application in SAP CPQ setup, a new Destination needs to be created in the SAP BTP subaccount where the SAP Build Process Automation instance is located. To do so, go to the subaccount, select Connectivity -> Destinations, and click on Create -> From Scratch -> Create:

• Specify a descriptive Name for this destination
• Specify base URL of your SAP CPQ instance
• Select OAuth2ClientCredentials as an Authentication method (if you enabled Client Credentials Grant in the previous step; if not, please consult the documentation)
• In the Client ID and Client Secret fields, paste the value generated in the previous step (in the configuration of the Trusted Application in your SAP CPQ instance)
• Specify Token Service URL by using the base URL of your SAP CPQ instance and adding the /oauth2/token suffix (or consult the documentation)
• Select Use Basic credentials for Token Service
• For the Token Service User field, use the same value as for the Client ID field
• For the Token Service Password field, use the same value as for the Client Secret field

Importing destination into SAP Build

After creating Destination in SAP BTP subaccount, it needs to be imported into SAP Build environment. Navigate your SAP Build Process Automation instance, and select SAP Build Lobby -> Control Tower -> Backend Configuration -> Destinations -> Add. Select the Destination you have created in the previous step and click Next.

On the next screen, select the SAP Build environment to which you want to associate new Destination and click Add Destination.

Deploying SAP Build Process Automation project

After creating and importing SAP BTP Destination for an SAP CPQ instance, you can deploy your SAP Build Process Automation project on a desired environment (before doing that, please make sure that you have released a version of your project, as described in documentation).

The process of deploying SAP Build Process Automation project is described in detail in official documentation.  What is important to note here is that you will be asked to specify a Destination for the Destination Variable you have previously defined and used for the SAP CPQ API actions. When asked to do so, please select the Destination you have imported in the previous step.

That's it!

Conclusion

In this blog post, we have demonstrated how to build side-by-side extensions of SAP CPQ using SAP Build Process Automation, a low-code/no-code platform that seamlessly integrates with SAP CPQ, and the rest of the SAP ecosystem. Side-by-side extensions can help you in customizing SAP CPQ to support your concrete business processes and requirements. In the following blog posts, we will talk about other SAP BTP (Business Technology Platform) tools and services that can help you in developing side-by-side extensions for SAP CPQ.

Resources

• "Creating Processes and Automations with SAP Build Process Automation" learning journey at SAP Learning
• API specification

Since Christmas is not far away, I think I would grant you your secret wish: get an early preview of what’s coming in SAP Global Trade Services, edition for SAP HANA 2025.

As per the Product Availability Matrix, this release is planned for this quarter so the Help Portal will be updated accordingly in time, but, if you read this blog, it’s because Santa’s helpers – here more likely Volker Mohr from Product Management and Torsten Stolz from Engineering, have provided a sneak preview of what you can expect in this release. 

🚀Revolutionize Your Financial Strategy with Central Finance in the SAP Sovereign Cloud!

SAP has transitioned SAP S/4HANA Cloud for Customer Payments into maintenance mode and removed it from the price list.  Customers are encouraged to transition to the new API-based approach in SAP S/4HANA Cloud and On-Premise/Private Cloud.

The payments landscape is rapidly changing and in Australia the New Payments Platform ("NPP") is providing new infrastructure and capabilities.

Our customers want to understand more about what the NPP offers and how SAP is enabling the adoption of the new innovations, as well as the implications for data and payment processes.

This Blog series is the result of close collaboration between SAP and the Australian Payments Plus team, who are responsible for the NPP. It is a combined effort with the SAP ANZ localization team, notably my colleague @Bino_Philip  who has done much of the heavy lifting in defining the SAP response. Any errors are mine alone.

This is an evolving topic and whilst we’ll try to keep it current, please ensure you check the latest SAP documentation. Also bear in mind that until we publish a Development Roadmap, any comments on plans, intentions or other forward looking statements are personal views and not the official SAP position.

The series is planned as:

1. Unlocking the NPP: SAP Capabilities for Faster, Smarter Payments
2. Unlocking the NPP: Payments overview
3. Unlocking the NPP: PayID
4. Unlocking the NPP: PayTo

When will SAP be NPP ready?

This is the number one question we get on this topic, with a mass of confusion on the changes required for NPP and opportunities it presents.

The simple answer is that SAP is already NPP capable with many customers benefiting from real time payments and the additional capabilities available now.

However, to understand the full picture of what is available in SAP across the range of NPP capabilities, how we are delivering innovation and plans for the future, please read on.

So what is the NPP?

The New Payments Platform is:

• Infrastructure which enables real time payments across Australia
• Additional capabilities to improve security and simplify payments
• Operated by Australian Payments Plus, whose members include the largest Banks, payment processors and businesses in Australia
• The eventual replacement for the Bulk Electronic Clearing System (“BECS”) overseen by the Reserve Bank of Australia which will be decommissioned by June 2030

There is a mass of additional information at https://www.auspayplus.com.au/, including technical documentation and file mapping guidance.

The NPP is particularly relevant for payments where Payer and Payee use different Banks and the funds need to be transferred between them, for example from a Westpac account to an NAB account. The current BECS cross bank clearing is a periodic batch process on business days only whereas NPP is a real-time process available 24/7.

The NPP is already available and is being widely used for personal banking. NPP is the technology behind the Osko brand which enables real time payments using the PayID function, removing the need to share Bank details (BSB and Account number).

Note that NPP is currently only relevant to payments within Australia where the Sending and Receiving Banks and other Financial Institutions are connected to the NPP. They can connect directly as an “NPP Participants” which requires them to meet strict criteria and is largely limited to major Financial Institutions. Other entities who wish to provide NPP services (“Identified Institutions”) cannot connect directly and must have an agreement with a sponsoring NPP Participant. Where the Payer and Payee use the same Bank, the additional capabilities of NPP such as PayID, PayTo (see below) are still relevant, even though clearing of payments is handled within the Bank.

Architecture

Individuals and Corporates will continue to transact though their Bank which for simplicity we will assume is connected directly to the NPP as a “Participant”.

The role of SAP does not change: it will create the payment instructions, receive status updates and bank statements and enable the Bank integration. Additional message types such as for intraday bank statements and APIs may also be relevant.

We do not currently envisage any requirement for SAP systems to connect directly to the NPP.

NPP capabilities

The NPP is not just a change in technology or a new platform. It is designed and built to deliver significant business benefits and opportunities to innovate new business models. By sending payments using the NPP, SAP customers can start to leverage these current capabilities and investigate the benefits and opportunities they provide:

• Real time payment clearing. This means that funds reach the payee in seconds not hours or days, improving cash flow. This has benefits in scenarios such as Public Sector benefits payments where recipients may have an urgent need, for example Bush fire related Disaster Recovery Payments. Similarly real time payments and their related status messages enable immediate execution of follow-on processes such as order credit unblock, sales order processing or delivery release with confidence that the funds have transferred.
• Real time payment status messages. This means errors can be corrected faster and more payments reach the Payee on time.
• 24/7 operations, 365 days a year. This provides additional flexibility in payment processing, from processing urgent payments to making payments precisely on the due date, even where this falls on a public holiday. It also assists with meeting compliance obligations, especially around payroll and superannuation.
• PayID enables payments to be made using the Payee’s email, phone number, ABN or other identifier, without requiring their BSB and Bank Account details
• PayTo agreements provide a greater degree of control and transparency for Direct Debit arrangements. The agreement or mandate is stored within the NPP and the Payer can approve, vary, end and define conditions (such as maximum amounts). The Payee needs to quote the agreement number rather than the BSB and Bank Account in the Direct Debit payment file.
• Confirmation of Payee. This service reduces fraud by checking the name on the Bank Account with the name of the intended Payee recipient.

NPP payment files

We will go into more detail in the next Blog on the requirements around making a payment using NPP. The main point to be aware of is that whilst the NPP has specific requirements for payment file format and field mapping, the Bank determines what is required from SAP.

Each Bank will provide documentation on:

• Payment file format - this is usually based on ISO20022 standard
• NPP relevant fields, i.e. what is required to ensure processing by NPP rather than BECS

Once the file is created with the required format and fields, it can be sent to the Bank for processing using standard integration. We’ll discuss integration impacts and the challenge for SAP to create a standard NPP compliant solution in the next Blog. 

SAP Approach for NPP

Whilst the official SAP Roadmap is still being developed internally, our general approach can be understood as:

• SAP solutions will be developed and delivered incrementally over future years, rather than as a single release.
• SAP solutions will be based around a single common standard, such as the ISO standard format and not numerous variations such as for Bank specific formats.
• SAP will focus on solutions for S/4HANA Cloud, both Public and Private Editions.

Staying compliant with Japan Consumption Tax (VAT) requirements in SAP S/4HANA Cloud Public Edition has evolved substantially over recent years. This central hub consolidates key resources, blogs, SAP Notes, Q&A, and help references into a single, continuously updated entry point.  We will update this blog periodically, so please bookmark this hub for your reference.

This blog post introduces the procedure of creating an advance notice to inform payers about future direct debit payment collection in SAP S/4HANA Cloud public edition. It is aim for the usage related to direct debit mandates in Contract Accounting.

What is Advance Notices?

Before the collection of the future direct debit payments, the payee can send an advance notice to inform the payer about the payment collection.

Prerequisites

Before creating direct debit advance notices, you must complete the following customizing activities:

1. Setting up the number ranges for advance notices
2. Activating the advance notice function
3. Setting up the lead days for the advance notices
4. Configuring the output of advance notices, including form templates, email templates and form template for correspondence
5. Maintaining the email address for the business partners that receives the advance notices

In the following activities, we introduce the procedure in SAP S/4HANA Cloud public edition.

Setting up the number ranges for advance notices

This activity allows you to set up a range of numbers within which the advance notices are valid.

1. In your configuration environment, find the Enter Number Ranges for Direct Debit Prenotifications (ID: 106939).
2. Create entries of numerical ranges between which the direct debit advance notices are valid.
   

Activating the Advance Notice Function and Setting up the lead days for the advance notices

In this activity you activate the direct debit advance notice function and setting up the lead days to determine the execution day for the payment collection.
You must complete the following activations in different configuration steps:

• Define General Settings (ID: 106087)
  Select the Activate Direct Debit Advance Notice checkbox.
  Choose a calendar ID and lead days. By doing so, you can set up the execution day for the direct debit payment collection.
  Note: Ensure that there is a minimum number of days between the notification of the upcoming direct debit and its collection day. 
• Define Payment Methods (ID: 101952)
  In this activity you activate the direct debit advance notice for the payment method by countries/regions.
  In the Payment Methods under Required master record specification group box, select the Direct Debit Prenotification checkbox.
  
• Define Specifications for Paying Company Code (ID: 101251)
  In this activity you activate the direct debit advance notice for the specific company code.
  Select your company code and double click.
  In the Specifications for SEPA Payments/Direct Debit Mandate group box, select the Direct Debit Pre-notification checkbox.

Output Management preparation

You have configured the output of the advance notices with the following steps.
Note: You have to activate the Output Management (1LQ) scope item.

• Maintain Form Template (app: F1434)
  In this app you can either use the SAP pre-defined template FIN_CA_DDM_ADVANCE_NOTICE for advance notices or you can copy the SAP delivered template, based on which create your own form template.

  Download the dunning notice template and open it in the LiveCycle Designer for the modification.
  Note: You can install Adobe LiveCycle Designer in Install Additional Software app.

  
• Assign Form Templates (ID: 102313)
  After you prepare your own form template and upload it, you must activate it in this configuration step.
  Assign the Application Object Type: FKC_DDM_ADVANCE_NOTICE and the Output Type: DDM_ADVANCE_NOTICE to your form template.
  

   

  
• Assign Email Templates (ID: 101945)
  In this activity, you can assign the email template that you have configured the texts and branding according to your needs. For more information about how to configure your own email template, see Configuring Email Templates.
  Assign the Application Object Type: FKC_DDM_ADVANCE_NOTICE and the Output Type: DDM_ADVANCE_NOTICE to your email template.
  
• Define Form Template for Correspondence (ID: 102223)
  In this activity assign the form template and the email template to a correspondence type in Contract Accounting. You can determine which correspondence is included when generating and printing documents.
  Select 0048 - Direct Debit Pre-Notification as your correspondence type and assign your form template and email template IDs.

Procedure of Creating Direct Debit Advance Notices in Contract Accounting

If you activate advance notice for a payment method, you cannot generate payment through the Payment Run/Debit Memo Run app for this payment method unless the advance notice for this payment has been created. To create an advance notice for the payment, see the following steps.

1. Use the Prenotify Direct Debits app to create advance notices.
2. Use the Payment Run / Debit Memo Run app to post documents of direct debit payments.
   You must complete the following action to include the open items in payments:
   • Select the Pre-notified Items checkbox
   • Fill in the "Execution Date" field

Optional: Adjust Number of Days between Notification and Direct Debit Payment Collection

If the number of days between the advance notice and the payment collection date are insufficient, those pre-notified items can be skipped when running the payment runs in this app.
In the following section, SAP provides the Cloud Business Add-In (BAdI) implementation for this scenario.
As a key user, you can use the cloud business add-in (BAdI) to implement your own logic. Before using the cloud BAdI, ensure that you have assigned the business role SAP_BR_EXTENSIBILITY_SPEC.
Note: Regarding of extensibility options for developers, go to Business Accelerator Hub and search for Adjust Payment Data (for Customer).

1. Open Custom Logic app.
2. Select “Create” and select FKK_EVENT_0610.
3. Enter the Implementation Description.
4. Publish.
5. Open Code Editor.
6. Select edit and enter your own logic.

You can reuse the following coding and adjust based on your business requirements.

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