Dunning & Correspondence in Central Finance

former_member621998 · ‎09-18-2020

Overview – Central Payments

The Central Payment capability of Central Finance allows the business to execute most of your financial operations in the newly created SAP S/4HANA landscape while keeping your source system active. Central Finance provides businesses with the ability to drive transformation beyond just a centralized reporting system. Central Finance has evolved from financial harmonization and consolidation to add additional tangible benefits for businesses including central payments, centralized receivable management, and much more using Central Payments.

Central payment in Central Finance 1909 allows businesses to make payments centrally and perform centralized clearing in the S/4HANA CFIN system instead of at the source systems. From SAP S/4HANA 1809 version, the source system open item when replicated, gets technically cleared and the payment is executed from the CFIN system. The central payment functionality can be activated by company code, and the invoices posted for those active company codes are cleared technically and replicated to the CFIN system. Once Central Payment is activated for a company code, all subsequent processes based on open item management must take place in the Central Finance System. For example:

Dunning

FX Revaluation

Customer / Vendor correspondence

Inter-Company Reconciliation process

Collection/Credit & Dispute Management

Month-end reporting e.g. Open Item lists, etc.

In this blog, we will be focusing on how to migrate the Dunning process & Customer correspondence from existing running source systems to Central Finance. The intention of this blog is to learn about the dunning customizing & options in Central Finance when Central Payments is activated. This blog does not feature the general dunning configuration in S/4HANA in detail.

Dunning process - Quick Recap

The dunning process is like sending a reminder notice to business partners (mostly customers) for their overdue/open items or outstanding balances. Dunning letter summarizes overdue invoices record and asks for payment to be made. We configure dunning program for accounts receivable (and sometimes accounts payable). Dunning Program includes following configuration steps:

Dunning Procedure: Dunning procedure controls the path of dunning to the customer and vendor through the system. We can define our own dunning procedure as per our convenience. Transaction code: FBMP.

Dunning Level: Dunning level defines dunning text; maximum nine dunning levels are available. As the dunning level increases, text will also change as consistent to make payment.

Dunning Area: Dunning area means the client/company/company code in which we are working on dunning program. If we don’t want to run dunning program at company code level then we can also run dunning program at organizational level like, sales organization.

Dunning Procedure config (T. code: FBMP)

There are additional functions in dunning like dunning charges to customer or vendors. We can also do changes in dunning program like dunning level, dunning data, and dunning area. A dunning block facility for special customers can also be configured.

Configuration in Central Finance

The configuration of dunning in Central Finance depends on the source systems. There could be three possibilities for configuring dunning based on source system(s):

One to one: In this approach, we map the dunning related configuration (dunning procedures, dunning levels, dunning areas, dunning blocks, etc.) one to one as it is from the source system(s). The advantage of this approach is that it is easier and quicker to implement. The dunning related fields should be mapped as ‘Keep Data’ and everything works in Central Finance system as it was in the source. However, a major disadvantage in this approach is in case of multiple source systems, there could be similar dunning related data in two or more source systems which would get duplicated in the Central Finance system. Another disadvantage would be in case there are two dunning procedures with the same ID in two different source systems (the configuration for these procedures could be same or different), in Central Finance system it would not be possible to replicate those dunning procedures one to one. In the below table, we can see the source dunning procedures DP01 to DP06 are replicated as it is in the Target (Central Finance) system:

Source System	Source DP	Target DP
SS1	DP01	DP01
SS1	DP02	DP02
SS2	DP03	DP03
SS2	DP04	DP04
SS3	DP05	DP05
SS4	DP06	DP06

Harmonization: To avoid the duplication and unharmonized data as in the above scenario, one of the solutions is to do a harmonization of the source system data. Harmonization is a process of a cleaning up by eliminating duplicates and undesirable entries. A data profiling is done across all source systems and the duplicate, undesirable and obsolete entries are disregarded. Thus, in the Central Finance system we have a clean data with no duplicates. The only disadvantage in this case is the additional effort required for data profiling and harmonization. This is the recommended approach for SAP source systems. In the below table, we can see that DP01 and DP02 are harmonized as DP01 in the target (Central Finance) system whereas some procedures are kept as it is.

Source System	Source DP	Target DP
SS1	DP01	DP01
SS1	DP02	DP01
SS2	DP03	DP03
SS2	DP04	DP04
SS3	DP05	DP04
SS4	DP06	DP06

Standard: In this approach, the configuration of dunning in central finance does not depend on the source system dunning configuration. Here, we create two or three standard dunning procedures (with different levels) in Central Finance and map (force-fit) all the source dunning procedures in the source system(s) into these two-three dunning procedures. An advantage of this approach is we have clean data in central finance, there is no requirement for an additional effort for data profiling. A drawback here is the force fitting could not work for all dunning scenarios in source systems especially for large organizations with multiple dunning procedures for specific business needs. This approach is recommended when the source system(s) are third party (non-SAP) ERP systems. In the below table, we can see that all dunning procedures (DP01-DP06) in source are forced mapped into D001 or D002 (two dunning procedures in target system).

Source System	Source DP	Target DP
SS1	DP01	D001
SS1	DP02
SS2	DP03
SS2	DP04	D002
SS3	DP05
SS4	DP06

Managing Master Data & Mapping

Master Data management in Central Finance plays a vital role in the project. A prerequisite for dunning is that the customer master data (in ECC system or any other third-party system) are created in Central Finance system as Business Partners. The key fields required for dunning process in customer master data are:

code: BP (role FI customer)– Company Code Data – Correspondence:

Dunning fields in Business Partner Master Data

Mandatory Fields:

Dunning Procedure (KNB5 – MAHNA)

If customer is already dunned in source system:
- Dunning Level (KNB5 – MAHNS)
- Last Dunned (KNB5 – MADAT)

Optional Fields:

Dunning Block (KNB5 – MANSP)

Dunning Recipient (KNB5 – KNRMA)

Legal Dunning procedure (KNB5 -GMVDT)

Dunning clerk (KNB5 – BUSAB)

If the master data load is being done through DEBMAS idocs, these fields are active in the E1KNB5M segment:

T. code WE30 idoc: DEBMAS

DEBMAS KNB5 segments

Besides the master data fields, dunning level and last dunned date in the invoice (transactional data) are important for dunning process in Central Finance.

Mapping

Mapping can be optional or mandatory depending upon the type of configuration (as mentioned in the above section). If mapping is required, mapping can be applied to dunning procedure, dunning area and dunning blocks. The dunning procedure mapping is the most critical mapping for this process.

For one to one configuration, the mapping action to be selected is Keep Data. If there is a case of multiple dunning procedures with same name in different source systems, and there is a requirement to rename one of the dunning procedures, then a mapping list must be uploaded with mapping action Mapping mandatory.

In case of harmonization of dunning procedures, the mapping action should be Mapping mandatory (recommended) or map if possible, in cases where the ID of dunning procedures remains same from source to target.

In case of standard configuration, the mapping action for dunning procedures should be Mapping mandatory.

The mapping for dunning block and dunning areas can be done, however this is optional and the mapping, mapping actions are designed as per business requirements.

Dunning Process Flow

There are two options for dunning once the prerequisites are met:

To reset all dunning data from source system and perform dunning from scratch in the Central Finance system (not recommended)

To carry over data from source to Central Finance and continue dunning operations as explained below:

Central Dunning Process Flow

The dunning process from source to central finance can be explained using the below scenario:

A customer invoice is posted in source system. The customer does not make the payment for the required invoice and the customer is dunned up to dunning level 2 in the source system.

At this juncture, Central Payments is activated, and the same invoice is transferred through to Central Finance system in the Real Time Replication.

The payment is still due and the date for next dunning level has arrived.

When the user runs dunning in Central Finance system, the system identifies the last dunning level based on the line item & dunning procedure based on the customer master data and then the customer is dunned for the next appropriate level accordingly.

Therefore, in our example, for the next dunning run would be level 3 for the invoice.

There is no further processing in the source system. As soon as central payments are activated, all the customers are ‘blocked for dunning’ in source system to avoid duplicate dunning runs from the source system.

Customer Correspondence in Central Finance

The customer correspondence includes:

Dunning Letters: The dunning letters in Central Finance system can be created using SAP script, SAP smart forms or Adobe forms. The format of the dunning letters can be derived from the source systems.

Customer statements: Correspondence can be sent to customer/ vendor in various formats like email, and fax. Correspondence are letters sent from SAP to vendors or customers. Correspondence can be created individually or collectively, ad-hoc or via automated batch job. Mostly, the standard correspondence types are enough for covering the business requirements. In case there are custom correspondence types created in source system, a profiling is required to check if the same is required in the Central Finance system.

Sending dunning letters and correspondence via email

In case the business requirement is to send the dunning letters via email, there are below possible options to maintain the email address for correspondence:

In the Business Partner – General Data – Email.

Assign accounting clerk to customer and email address is present in the accounting clerk user ID.

Email ID can be assigned in the Contact Person tab in the Business Partner Master Data.

There could be some business requirements when the dunning letters and customer statements are required to be sent to different email addresses. In this case, we can use both the above cases for different purposes (example, business partner email ID for customer statements and dunning clerk (accounting clerk) email for dunning).

Another complex scenario in this case is the possibility to send multiple emails. In this case we can add multiple email addresses in Master data followed by space or create multiple address versions with different email addresses and refer the same from the ADRC tables.

Multiple email address

Conclusion

To conclude, dunning process can be performed in Central Finance once Central Payment is activated, the pre-requisites is the load of master data with relevant fields and the configurations steps (as mentioned above).

Further Reads & References

Dunning in SAP: https://blogs.sap.com/2013/05/03/sap-fi-dunning-procedure-for-customer-outstanding-invoices/

To learn more about Central Payments : https://blogs.sap.com/2020/08/06/central-payments-in-sap-s-4hana-central-finance