Dear SAPers,
Here is a new post that focuses on the innovations in the dunning process, which were introduced by Fiori in SAP S/4HANA landscape. The post is based on the SAP S/4HANA 2022 (on-premise) product version.
Dunning is the process to manage accounts receivable in SAP. It allows you to track overdue receivables, generate dunning notices & send them to your customers. Dunning is considered a reactive type of receivables management. It is reactive management because we deal essentially with those items that are already overdue. SAP offers more advanced types of receivables management, in particular Collections Management which allows the company to proactively evaluate, identify & prioritize business partners in accordance with the defined collection strategy and collection rules. For those interested in the topics, I’d recommend an excellent blog post on the topic. Now let's go back to the original topic of the dunning.
Fiori app F2435 “My Dunning Proposals” is the app that replaces the GUI transaction F150 in Fiori landscape. Before diving deep into the functionality of the app and main user flows, it is worth exploring an important topic, which is the use of accounting clerks. The first thing you might notice, when you open this Fiori app is the error message “The user is not defined as an accounting clerk in the system”:
Accounting clerk is a master data attribute that is used to denote an employee and assign it as a responsible person to a business partner on a company code level. Afterwards, you can use your clerk ID as a filter characteristic for a variety of standard reports & transactions. Accounting clerk is not something new in SAP S/4 HANA. The earliest OSS notes referencing issues around accounting clerks date back to 1996.
What is new: if you want to use dunning in Fiori, you must fully embrace the concept of accounting clerks. Earlier use of accounting clerks for the purposes of the dunning was optional.
From my previous experience of over 10 years, I can say that most of the companies (countries) use dunning in SAP (except for those countries, where dunning notices are not part of the established business practice e.g., Ukraine). But not all companies that use the dunning in SAP use accounting clerks the way it was intended to be used. My experience might not be fully representative, but that’s beside the point.
This change is described in a KBA-note 2779976 “Unable to open the app "My Dunning Proposal”. Essentially, you need to define a clerk ID for your company code and assign it to SAP user. This can be managed in Fiori app F1009 “Define Accounting Clerks”. See the screenshot below:
Alternatively, accounting clerk IDs can be defined via GUI transaction OB05, which offers the same capabilities as Fiori app.
Once you have a clerk ID, make sure that it is assigned to a business partner representing the customer. Assignment should be done on a tab “Customer: Correspondence” under company code data. The change can be done via GUI transaction BP or via Fiori app “Maintain Business Partner”. I attach a screenshot from GUI transaction because it is more compact than respective Fiori app:
If you want to send dunning notices via e-mail, it is a best practice to maintain the recipient's e-mail in the field "Clerk's internet address" (KNB1-INTAD). But you can use other fields in the customer's master data (e.g. under Address / Communication section) to maintain the e-mail for this purpose.
This concludes the master data requirements for dunning.
Once the master data issues have been sorted out, you’ll see an empty report screen like the one provided below:
There is an additional toolbar at the bottom of the screen. Press the button with respective name to create a dunning proposal:
When you trigger the creation of the dunning proposal, the program creates a background job. One background job is created for each company code, where your user is defined as accounting clerk. The naming of the background job includes concatenation of your clerk ID + company code ID.
Once the processing is completed, you’ll see the list of dunning notices that were prepared as a proposal (screenshot below). Just in case: the Fiori app offers a wide range of filtering options, but these options apply only to the dunning notices resulting from the dunning proposal. You cannot use them to limit the selection of the data for dunning to certain customers or even a company code. Whenever you create a proposal, it always includes all your customers from all company codes.
The dunning proposal that you see in Fiori app is also available in GUI transaction F150. See the example below. So far, the dunning is in the proposal stage. I’d like to point out some interesting observations.
As you can see, the dunning run is created for each company code separately and there is no filter per customer i.e., each time you run the dunning proposal, you run it essentially for all customers that you manage as accounting clerk.
Dunning proposal created out of Fiori app automatically sets the filter per accounting clerk via the free selection interface. That is the mechanism that ensures that the Fiori app does not process all customers from the company code, only those assigned to you via accounting clerk.
Herein lies the biggest limitation of the Fiori app, at least in my opinion. If you don’t want to include certain line items into dunning runs, you no longer can leverage the filtering via “Free selection” as it was possible in GUI transaction F150. This is a big disadvantage, because lots of the companies were using these “Free selections” to limit the selection of open items for dunning.
Once the proposal is ready, there is not much you can see or do with it in Fiori. When you select the line item, you can one of the following:
When you send dunning notices for printing, a dialog window will appear asking you to provide a printer name. Carefully read the note on the window. Essentially, if you decided to print dunning notice for one customer, the program will automatically trigger printing / sending of dunning notices for all your customers / company codes at the same time.
This automation might look nice on the first glace, but when you consider big international companies with centralized accounting functions, it might be necessary to send the dunning notices in one company code to one physical printer, whereas in another company code to another one. The Fiori app robs you of this flexibility.
You still can create dunning proposals in GUI via F150 and these proposals will be visible in the Fiori apps. SAP documentation on the topic states the following: “… dunning proposals initiated from outside the app should create separate dunning runs for each dunning clerk. Dunning runs for multiple clerks cannot be processed and will remain in the app.”. Practically, if you create a dunning proposal in F150 and do not limit the selection of items to you clerk ID, you’ll be able to access via Fiori App only those customers who belong to your clerk ID. To access other customers, you need to press the following button in the report:
This action opens the pop-up window with the list of accounting clerk. By selecting the clerk name, you’ll navigate to the report showing his/her dunning proposals:
Notes on e-mailing of dunning notices
There is no dedicated option (i.e. button) for e-mail sending as such. When you press the button "Send Dunning Notices", the system's default behavior is to print the notices. However, if you implemented the user exit associated with the BTE 1040, the program will generate an e-mail and send it to the customer. The enhancement logic for e-mail sending in this area is well described and there is nothing new I can add on this topic.
Another innovation is Fiori app F2328 “Display Dunning History”. This report shows the history of dunning runs with all necessary details. The information is provided per customer (i.e., and dunning run) and you can immediately display the PDF-layout for dunning notice or navigate to the report with the list of dunned items.
Dunning details are presented as a report in the following format:
When comparing the Fiori App with a legacy GUI transaction, I can say that the former provides much better user experience. The user flow for dunning in Fiori is very simple, you must press just a few buttons to get the desired results. Besides, I would even venture to say that the simplification that is introduced by Fiori in this domain can significantly reduce the training cost for onboarding of new employees or re-training of existing ones.
GUI transaction F150 looks more complicated (or sophisticated) and requires more attention (and training) from the user. But it offers more instruments and flexibility for power users who know their way around the system. The following advantages of GUI are not yet available in Fiori:
The simplification of the functionality around dunning (in Fiori) forces you to rethink your processes. You should streamline the dunning process in such a way that you no longer need additional filters. For example, you can implement a set of accounting substitution rules that will set the dunning block for those items that should be excluded from the dunning.
I’ve opened my fair share of OSS incidents covering the issues of missing functionality in Fiori. This applies to various functionalities which were part of standard SAP for decades, but now suddenly are not available in Fiori. You can meet these issues in every domain in SAP. In most cases, SAP support consultants agree about the fact that something is missing but point out that “it is not the aim of SAP to fully replicate legacy GUI functionality to Fiori”. They usually also add something along the lines of “we strive to provide seamless and simplified user experience based on modern UI technology”.
So, what do you think about the new Fiori apps for dunning? Are they a worthy replacement for the legacy GUI transactions? Do they provide better user experience ? I’d be happy to hear your thoughts in the comments section.
Regards,
Bohdan
Here is a new post that focuses on the innovations in the dunning process, which were introduced by Fiori in SAP S/4HANA landscape. The post is based on the SAP S/4HANA 2022 (on-premise) product version.
Introduction
Dunning is the process to manage accounts receivable in SAP. It allows you to track overdue receivables, generate dunning notices & send them to your customers. Dunning is considered a reactive type of receivables management. It is reactive management because we deal essentially with those items that are already overdue. SAP offers more advanced types of receivables management, in particular Collections Management which allows the company to proactively evaluate, identify & prioritize business partners in accordance with the defined collection strategy and collection rules. For those interested in the topics, I’d recommend an excellent blog post on the topic. Now let's go back to the original topic of the dunning.
Use of accounting clerks
Fiori app F2435 “My Dunning Proposals” is the app that replaces the GUI transaction F150 in Fiori landscape. Before diving deep into the functionality of the app and main user flows, it is worth exploring an important topic, which is the use of accounting clerks. The first thing you might notice, when you open this Fiori app is the error message “The user is not defined as an accounting clerk in the system”:
Accounting clerk is a master data attribute that is used to denote an employee and assign it as a responsible person to a business partner on a company code level. Afterwards, you can use your clerk ID as a filter characteristic for a variety of standard reports & transactions. Accounting clerk is not something new in SAP S/4 HANA. The earliest OSS notes referencing issues around accounting clerks date back to 1996.
What is new: if you want to use dunning in Fiori, you must fully embrace the concept of accounting clerks. Earlier use of accounting clerks for the purposes of the dunning was optional.
From my previous experience of over 10 years, I can say that most of the companies (countries) use dunning in SAP (except for those countries, where dunning notices are not part of the established business practice e.g., Ukraine). But not all companies that use the dunning in SAP use accounting clerks the way it was intended to be used. My experience might not be fully representative, but that’s beside the point.
This change is described in a KBA-note 2779976 “Unable to open the app "My Dunning Proposal”. Essentially, you need to define a clerk ID for your company code and assign it to SAP user. This can be managed in Fiori app F1009 “Define Accounting Clerks”. See the screenshot below:
Alternatively, accounting clerk IDs can be defined via GUI transaction OB05, which offers the same capabilities as Fiori app.
Once you have a clerk ID, make sure that it is assigned to a business partner representing the customer. Assignment should be done on a tab “Customer: Correspondence” under company code data. The change can be done via GUI transaction BP or via Fiori app “Maintain Business Partner”. I attach a screenshot from GUI transaction because it is more compact than respective Fiori app:
If you want to send dunning notices via e-mail, it is a best practice to maintain the recipient's e-mail in the field "Clerk's internet address" (KNB1-INTAD). But you can use other fields in the customer's master data (e.g. under Address / Communication section) to maintain the e-mail for this purpose.
This concludes the master data requirements for dunning.
Basic dunning process
Once the master data issues have been sorted out, you’ll see an empty report screen like the one provided below:
There is an additional toolbar at the bottom of the screen. Press the button with respective name to create a dunning proposal:
When you trigger the creation of the dunning proposal, the program creates a background job. One background job is created for each company code, where your user is defined as accounting clerk. The naming of the background job includes concatenation of your clerk ID + company code ID.
Once the processing is completed, you’ll see the list of dunning notices that were prepared as a proposal (screenshot below). Just in case: the Fiori app offers a wide range of filtering options, but these options apply only to the dunning notices resulting from the dunning proposal. You cannot use them to limit the selection of the data for dunning to certain customers or even a company code. Whenever you create a proposal, it always includes all your customers from all company codes.
The dunning proposal that you see in Fiori app is also available in GUI transaction F150. See the example below. So far, the dunning is in the proposal stage. I’d like to point out some interesting observations.
As you can see, the dunning run is created for each company code separately and there is no filter per customer i.e., each time you run the dunning proposal, you run it essentially for all customers that you manage as accounting clerk.
Dunning proposal created out of Fiori app automatically sets the filter per accounting clerk via the free selection interface. That is the mechanism that ensures that the Fiori app does not process all customers from the company code, only those assigned to you via accounting clerk.
Herein lies the biggest limitation of the Fiori app, at least in my opinion. If you don’t want to include certain line items into dunning runs, you no longer can leverage the filtering via “Free selection” as it was possible in GUI transaction F150. This is a big disadvantage, because lots of the companies were using these “Free selections” to limit the selection of open items for dunning.
Once the proposal is ready, there is not much you can see or do with it in Fiori. When you select the line item, you can one of the following:
- Set the dunning block to exclude item from dunning.
- Preview / save the PDF-layout before printing / e-mailing.
- Send the dunning notices for printing.
When you send dunning notices for printing, a dialog window will appear asking you to provide a printer name. Carefully read the note on the window. Essentially, if you decided to print dunning notice for one customer, the program will automatically trigger printing / sending of dunning notices for all your customers / company codes at the same time.
This automation might look nice on the first glace, but when you consider big international companies with centralized accounting functions, it might be necessary to send the dunning notices in one company code to one physical printer, whereas in another company code to another one. The Fiori app robs you of this flexibility.
You still can create dunning proposals in GUI via F150 and these proposals will be visible in the Fiori apps. SAP documentation on the topic states the following: “… dunning proposals initiated from outside the app should create separate dunning runs for each dunning clerk. Dunning runs for multiple clerks cannot be processed and will remain in the app.”. Practically, if you create a dunning proposal in F150 and do not limit the selection of items to you clerk ID, you’ll be able to access via Fiori App only those customers who belong to your clerk ID. To access other customers, you need to press the following button in the report:
This action opens the pop-up window with the list of accounting clerk. By selecting the clerk name, you’ll navigate to the report showing his/her dunning proposals:
Notes on e-mailing of dunning notices
There is no dedicated option (i.e. button) for e-mail sending as such. When you press the button "Send Dunning Notices", the system's default behavior is to print the notices. However, if you implemented the user exit associated with the BTE 1040, the program will generate an e-mail and send it to the customer. The enhancement logic for e-mail sending in this area is well described and there is nothing new I can add on this topic.
Dunning history
Another innovation is Fiori app F2328 “Display Dunning History”. This report shows the history of dunning runs with all necessary details. The information is provided per customer (i.e., and dunning run) and you can immediately display the PDF-layout for dunning notice or navigate to the report with the list of dunned items.
Dunning details are presented as a report in the following format:
Concluding notes
When comparing the Fiori App with a legacy GUI transaction, I can say that the former provides much better user experience. The user flow for dunning in Fiori is very simple, you must press just a few buttons to get the desired results. Besides, I would even venture to say that the simplification that is introduced by Fiori in this domain can significantly reduce the training cost for onboarding of new employees or re-training of existing ones.
GUI transaction F150 looks more complicated (or sophisticated) and requires more attention (and training) from the user. But it offers more instruments and flexibility for power users who know their way around the system. The following advantages of GUI are not yet available in Fiori:
- Advanced filter options, including “Free selections”.
- Application logs which can simplify troubleshooting.
The simplification of the functionality around dunning (in Fiori) forces you to rethink your processes. You should streamline the dunning process in such a way that you no longer need additional filters. For example, you can implement a set of accounting substitution rules that will set the dunning block for those items that should be excluded from the dunning.
I’ve opened my fair share of OSS incidents covering the issues of missing functionality in Fiori. This applies to various functionalities which were part of standard SAP for decades, but now suddenly are not available in Fiori. You can meet these issues in every domain in SAP. In most cases, SAP support consultants agree about the fact that something is missing but point out that “it is not the aim of SAP to fully replicate legacy GUI functionality to Fiori”. They usually also add something along the lines of “we strive to provide seamless and simplified user experience based on modern UI technology”.
So, what do you think about the new Fiori apps for dunning? Are they a worthy replacement for the legacy GUI transactions? Do they provide better user experience ? I’d be happy to hear your thoughts in the comments section.
Regards,
Bohdan
- SAP Managed Tags:
4 Comments
