Ever wondered how to link your sub-ledger accounting with an operative service system? My blog article will show you how to use the Disconnection and Reconnection of Services function in SAP S/4HANA Cloud (also available in on-premise versions) and how to configure it to your own solution!
Content:
- Understand the feature
- Understand the process
- Master data
- Disconnection of services
- Reconnection of services
- Transfer disconnection and reconnection requests
- Monitoring of disconnection and reconnection requests
- Understand the configuration
- Conclusion
- Appendix
Understand the feature
Contract Accounting allows you to block or disconnect services consumed by your customers, if the customers are having open receivables which are relevant for dunning. This means you can establish a connection between your open item management system and an external, technical system which is responsible to provide the service to you customer.The feature is embedded in the Contract Accounting dunning process and is flanked by operational and analytical apps.
A disconnection request for the end-customer’s service is generated from the dunning process based on the customizing settings in your system. The disconnection requests are transferred from the financial system to the operational, technical service system. This system disconnects the service for further usage. If the customer clears the corresponding open item, a reconnection request is created. This request is also transferred from SAP S/4HANA to the operational service system to reconnect the service for the customer. Individual services – e.g. in the healthcare sector – can be excluded from this mechanism.
Understand the process
The process steps:
- A dunning activity creates one to many disconnection requests, based on your configuration.
- The disconnection requests are transferred to the external system, this system will execute the disconnection requests created in step 1.
- Based on incoming payments, Contract Accounting analyzes if the service can be connected again, a reconnection request is created.
- The reconnection requests are sent to the external system, this system will connect the service, the end customer can continue to consume the service.
Master Data
A service is represented in Contract Accounting by the provider contract object with one to many provider contract items.
Without this object you can not use the Disconnection and Reconnection of Services feature.
If your business case contains services which should be excluded from the disconnection, you can set the indicator “Disconnection of service not permitted” (XDISCOEXEMPT) on the level of the provider contract item.
You can find the flag on tab Items: Dunning.
Disconnection of services
The disconnection request is created during the dunning process. In your dunning procedure, a corresponding activity is needed (020 – Service Disconnection Request;function module name in on-premise systems FKK_DISCOPROPOSAL_CREATE_0350). As soon as this dunning activity is executed and the criteria are met, the disconnection request is created. Regardless of whether the dunning procedure is assigned to the contract account, the provider contract or the open item itself. Additionally, the field “Reconnection Status” (DFKKOP.RCSTA) is set to true on the open item.
From experience, it is recommended to send a proper correspondence to you customer in order to ensure a clear and fair communication.
For the on-premise users who like to dig through the tables of Contact Accounting, I would like to give some hints about the attribute RCSTA (Reconnection Status) in table DFKKOP.
This field contains the status of an open item regarding the service disconnection or reconnection.
Value:
- Space – Item is not part of a disconnection request.
- X – Item belongs to a disconnection request.
- 1 – An incoming payment was posted. The reconnection can be analyzed, but it’s pending.
- 2 – Reconnection analyzed: The incoming total payment was greater then the defined threshold.
- 3 – Reconnection analyzed: The incoming total payment was smaller then the defined threshold.
Status changes:
- Space to X : Set by dunning activity.
- X to 1 : Set by incoming payment.
- 1 to 2 : Set by analysis of incoming payment; payment was higher than the defined threshold.
- 1 to 3 : Set by analysis of incoming payment; payment was smaller than the defined threshold.
- 2 to 1 : Set, if the payment was reversed or in the case of a clearing reset.
- 3 to 1 : Set, if the payment was reversed or in the case of a clearing reset.
Reconnection of services
In order to reconnect the service for the customer, exactly these open items must have been cleared, who have triggered the disconnection request. No matter which process in Contract Accounting has posted the incoming payment.
The analysis, if incoming payment do met the criteria to reconnect a service, has to be scheduled as a separate job. In the case, that all requirements are fulfilled, a reconnection request is created.
This process step is called “Analyze and create reconnection requests” and has two tasks:
- Check, if incoming payments are good enough to reconnect a service
- If yes, create the reconnection request
The ID of the app is F4654 – Create reconnection requests (on-premise transaction FKK_DISCPROP_ANALYZE).
Transfer disconnection and reconnection requests
It makes sense to transfer the disconnection and reconnection requests on a regular basis (e.g. once a day) from your finance system running Contract Accounting to your operational, technical system.
You can use for this purpose app F4658 – Send Disconnection/Reconnection Request (on-premise transaction FKK_DISCOPROP_SEND).
The status of the disconnection and reconnection requests can be changed if you reverse dunning activities or reset clearings.
This list shows the possible status of a request and explains from where it derives:
- Valid: just a valid disconnection and reconnection request.
- Obsolete – disconnection request: The disconnection request was not sent to the external system; status change due to dunning reversal.
- Invalid – disconnection request: The disconnection request was already sent to the external system; status change due to dunning reversal.
- Obsolete – reconnection request: A payment was reversed; status change due to clearing reset.
The disconnection and reconnection requests are transferred by two separate, asynchronous interfaces from Contract Accounting to the external system.
Your external, operative system needs to implement these interfaces in order to process the incoming requests.
Both interfaces are based on a SOAP API provided by SAP.
For the cloud edition you configure in the Communication Arrangements app the scenario SAP_COM_0579 (Finance – Contract Accounting Service Disconnection and Reconnection).
Monitoring of disconnection and reconnection requests
The requests for disconnection and reconnection requests created out of dunning and payment processes, can be easily monitored with the Fiori app F4943 – Monitor Disconnection Requests.
This app groups and visualizing all the requests based on their status (valid, invalid or obsolete).
You can use different criteria for selection of data, e.g. the company code or the contract account number.
In the detail view of a disconnection request you can see:
- General information like the dunning amount and company code
- The dunned business partner items
- A reconnection request, if applicable
The example screenshot shows a sent disconnection request with a corresponding reconnection request.
Understand the configuration
You can find the configuration for Disconnection and Reconnection of Services easily in the Configure your Solution app.
Each request has its own number, therefore a number range interval must be defined for the object FKK_DISCO (my most favorite number range name).
The settings are depend on the company code.
A currency can be specified for thresholds, Contract Accounting will convert the currency if needed.
The most important thing is to set the thresholds correctly, as described in the following section.
Minimum open amount
During the dunning process, Contract Accounting checks whether the dunned amount exceeds this threshold. If yes, a new disconnection request is created.
In our example shown in the screenshot, a dunning amounting to 90 Euros will not lead to a disconnection request, but a dunning amounting to 150 Euros does.
It is also important to consider the minimum amount that is assigned to the dunning level. If the dunning activity is not fired for the dunning level, the disconnection request will not be created.
Maximum open amount
Incoming payments are compared with the Maximum open amount configured. In the case that the total amount is smaller than the configured maximum open amount, Contract Accounting will create a reconnection request.
If 0 Euros are defined as maximum open amount, the reconnection request is created only, if all items belonging to a disconnection request were cleared.
Max. percentage
There is also the option to work with the Maximum percentage. Let‘s assume that 1% is defined as maximum percentage, Contract Accounting will then create the reconnection request only if 99% of the open items were cleared.
