How to send the different Finance outputs via email ?

A typical Business requirement now a days in today's world is to send certain Finance Outputs via email automatically from SAP as soon as you generate them. In S/4 HANA on-premise (and ECC as well), to be able to achieve this you need to deal with a little bit of custom code that needs to be added and managed in BTE's (Business Transaction Events). These ones are similar to any other User Exit.

As you might know already, there are different automatic processes in SAP that trigger outputs and when these are created, these BTEs will be called and eventually the generated outputs will be sent via email by SAP automatically if you put the appropriate code on them.

I will be talking in these post about 4 different important and key Finance Outputs:

• Vendor Payment Advice
• Customer Statement
• Dunning Notice
• Interest 

In this post I will NOT explain you how to execute the programs that generate them, what options and/or values to put in the screens. As a Consultant you should know how to run these "user" steps already. There are plenty of content about this on the Internet already. This Blog post is not for that, is to explain you the technical side of what you need to do to achieve sending these Outputs via email.

Each one of these Outputs have at least 1 (some even 2) Function Modules that need to be coded to be able to control if the output goes to the Spool, Email / Internet or Fax (nobody uses a Fax anymore). Other things that you can control too are the Sender email, Recipient email, email Subject and email body text. All of these can be managed as part of your custom code.

These FMs get assigned in Tcode FIBF and are based on a Transaction Event number that corresponds to each one of these different outputs. You cannot reuse the same code for all of them, but the idea and logic can be replicated for all of them.

1st you need to start by "registering" your Product / Output for the ones you will be dealing with. In my case, ZDUN, ZPADV_EM, ZPADV_SJ. But you can put any Product name / code that you want, then you need to flag the "Active" field as well; otherwise it will not be called.

Then once you have your Function Modules with your Custom code, you need to enter the FMs.

You go into Process Modules -> of a customer to assign them.

You make entries in this table to assign here the FMs that you have coded to manage the different options like (sender / receiver email, subject and body text). As you can see, the Process numbers represent the individual outputs.

Payment Advice

Payment Advice has 2 processes 2040 and 2050. 

Process 2040, allows you to manage Sender email address, Recipient email address, Mail Body Text and the type of Transmission Method 

• c_finaa-nacha = '1'  - Spool
• c_finaa-nacha = 'I'  - Internet / Email

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00002040. 

Process 2050, allows you to manage email Subject

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00002050. 

Customer Statement

Process 2310. This one allows you to manage Transmission method, Format (PDF), Mail Body, Mail Subject, Sender and Recipient email address.

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00002310. 

Dunning Letter

Process 1040. This one allows you to manage Transmission method, Format (PDF), Mail Body, Mail Subject, Sender and Recipient email address.

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00001040.

Interest Output

For the Interest Calculation done out of FINT Tcode, I will refer you to the below Blog post where it explains Badi FI_INT_CUS01 that needs to be implemented to manage all the same things that we did for the other Outputs. 

http://sapabapcentral.blogspot.com/2018/12/sending-email-from-fint.html

By the way, excellent Blog this one for Abap resources. 

The specific Abap code of each one of these Function Modules need to be done based on your particular case. I am not providing you the code in this Posting. Maybe this will be the subject of a subsequent Post.

** Note: This process applies to S/4 HANA On-Premise (ECC as well) only. For S/4 HANA Cloud the solution is completely different and based on the new Output Management Solution that works with BRF+ technology. I am not aware that this has changed for S/4 HANA 2020 version either. If you know, please let me know ...

Some Reference OSS Notes:

◈ Payment Advice: OSS 1033893, 836169
◈ Dunning: OSS 1042992
◈ Customer correspondence (Ex. Statement): OSS 1360070

◈ Interest : OSS 956981

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

Payments Advice in S/4 HANA (On-premise)

In a recent post, I was talking about how to do physical checks payments the right way in S/4. Now in this one, I will show you how to generate Payment Advices in S/4 HANA. If you read my previous post, if not you should, you will know that the Tab "printout / data medium" has been removed and it just does not exists in the Fiori App "Manage Automatic Payments" which replaces Tcode F110. So another drawback of this, is the lack of possibility to select your Program Variant to issue your Payment Advice.

But ... there is no PMW (Payment Medium Workbench) solution for this as we have for Checks. In this case SAP has "hardcoded" it (literally) in the Fiori App "Manage Automatic Payments" to look for a specific Variant Name under program RFFOAVIS_FPAYM. If you do not have this Variant in your system, no matter what you do and try, your Payment Advices will not be generated.

Up until version 1809 FPS01, you needed to create this Program Variant manually. Now they woke up and they included it out-of-the-box. So if you are working on 1610, 1709 or initial 1809 chances are that you were (or are) missing this Variant. If you have it, it might mean that someone created it already.

Variant name required and "hardcoded" is: PAYM_LC

There is even an OSS Note (2690678 - Manage Automatic Payments: Cannot Print or Send Payment Advices) that SAP released that explains the issue and what you have to do.

Reference OSS Note:

2690678 - Manage Automatic Payments: Cannot Print or Send Payment Advices

https://launchpad.support.sap.com/#/notes/2690678

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

Testing Vendor Payment Advices (easy & quick)

A few weeks ago, I posted a way to test the creation of Electronic Payment files for Vendor Payments in a way that you do not need to regenerate the whole Payment Run over and over every time you need to re-test.

Today I will show you a way to retest the creation of Vendor Payment Advices in a similar way to my previous post.

In this case, this technique is really useful whenever you are developing your Vendor Payment Advice Form and you have your Abap developer asking you for the steps to generate the form. In this case, it will be hard for him to generate data for Vendor Invoices, do a Payment Proposal, pay it and trigger the Advice from it. That without mentioning that the Business Partner - Vendor needs to be properly setup and that he does not get any errors while generating the Payment Proposal (which it is quite common). That is to much for an Abaper !!! Not that they cannot do it, but imagine that this is not the only area / module that they work on. They cannot know how to do everything in the system. Even some Finance consultants that are not that experienced have issues doing this ...

Now, considering that you have a previously created and completed Payment Run for which the system should have triggered a Payment Advice Form, you will follow my steps and be able to continuously use the same one over & over.

Go to SE38 and execute program RFFOAVIS_FPAYM

Now that we have entered into the Payment Advice Program, you will enter the "Program run date" and the "Identification feature" (Ex. 20200305 and AD001) of your previously executed Payment Run that already triggered a Payment Advice.

This will trigger the creation of the Payment Advice again and you or your Abap developer will be able to see the changes that he did in the Form. 

The Payment Advice will be generated and sent to your Spool or via email depending if you have in place the necessary development to trigger it via email. (not part of this explanation).

If he needs to do more changes, he will just go back to the Form, adjust it and then re-execute this procedure. 

With this, you or him does not need to re-generate a whole set of new data and transactions every time he needs to do some testing or adjustments.

** Note: The Paying Company Code and the payment method are not needed, you can leave it blank if you need. They were part of a previous capture that I had.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com