Dunning by Dunning Procedure in FSCD


There are cases when a Policy holder fails to pay his/ her premium on time. How does the Insurance company know when to contact/alert them and initiate reminders from gentle reminders (correspondence) to notices indicating policy cancellation, followed by follow up phone calls, and contacting external collection agencies to ensure the collection of accounts receivable and so on, and at a certain point of time.

FSCD can help using Dunning functionality.

This process of reminding a customer ( or a vendor) who has failed to meet his/her premium (for a vendor any payment liabilities) and taking certain regulated actions / authorized steps is known as Dunning ( Dun – demand payment of a debt).

Dunning functionality in FSCD used for this purpose where a Business Partner is mainly dunned for;

1) Overdue receivables – for e.g. insurance premium, overdue installments posted from VYSPA (Posting run)  transaction

2) Additional receivables – for e.g.late payment fees / charges

3) To alert the Insurance company / collection agency as well.

Dunning in FSCD is made up of the following layers and it is very important to understand the hierarchy of these layers.


A dunning procedure is made up of individual dunning levels.


We can make a number of specifications for each dunning level, including the minimum amount of an overdue item and the number of days in arrears to be reached in order for the item (over due payment liability) to reach the next dunning level.


Dunning activities are triggered such as first friendly telephone contact, another dunning notice is generated in the second dunning level and the receivables due for dunning are transferred to an external collection agency in subsequent dunning levels. One of the most frequently used dunning activities is the creation of a dunning notice (correspondence), or a phone call  etc. Other examples of dunning activities are posting interest and charges, processing a note for an agent, or starting a work-flow, triggering a function module etc.


Usually the dunning process (DP – > DL -> DA) follows these steps in FSCD

(1) OPEN ITEM  -> (2a) DP Run (also read the Dunning History from master data) -> (2b) Item due (if no payment (item) is present then proceed to the next DL) -> (3a) DA Run -> (3b) Trigger Activities -> (4) Entry in Dunning History for current DP -> (5) Proceed to step 2a if there is no action from policyholder else proceed to next step -> (6a) Entry in Dunning History for current DP -> (6b) Dunning run end

1) An Open item is due for dunning ( due date for net payment + days in arrears defined in the implementation guide is less than the date of issue for the dunning run) and if no dunning lock is entered in the master data / open item.

2) The DP run delivers the input for the DL run .

3) The DA run executes the activities for an insurance policy that is suitable for dunning and calculate charges and interest.

4) All dunning relevant data from a DP is stored in the insurance dunning history.

5) If the policy holder does not react to reminders or dunning notice , the item due for dunning is taken from the DP run and moves to the next DL after the days between two dunning levels have expired as defined in the dunning frequency (dunning frequency is a parameter in customizing which we shall see later).

6) A dunning procedure is ended by the dunning end run after payment receipt or after a change to master data with respect to change in incoming payment. The result may even be creation of installment plan, manual entry in Dunning History.

The Dunning run (program) is divided into two runs.

1) Transaction VPVA  – A dunning proposal is created in the first run. DP determines the open items due for dunning and group them .

Note: You can use transaction FPVA Create batch job for dunning proposal. A DP consists of the items from a dunning proposal run that have been grouped together for dunning. Every dunning notice refers to a DP. You can specify the selection of items to be dunned using the parameters from the dunning proposal run. A successfully completed dunning proposal run is, therefore, prerequisite for dunning activities (DAs).

2) Transaction VPVB – In the second run, dunning activities in particular, printing of the dunning notice are carried out on the basis of the dunning proposal. This run executes the dunning activities defined for the determined dunning levels. The DA run is the second sub-process and is executed after a DP has been created.

The dunning run activity determines and executes the DAs defined in the dunning procedure and the dunning level. A dunning activity run refers to one DP run. If all the dunning activities for a dunning notice are executed successfully, the dunning activity run enters the print date in the dunning proposal.

The dunning proposal then becomes dunning history.

Note: You can use transaction FPVB Create batch job for dunning activity.


The “DP” is the most important layer for initiating dunning. You can define different DLs for each DP. These “DLs” determine the dunning frequency, the calculation method by which the dunning charges are determined, and how interest is calculated and posted. For each DL you can also define currency-specific minimum amounts and “dunning activities”. You should select “Always dunn. notice” for the last DL so that items at this level are not skipped. The dunning proposal run evaluates the execution variants at event 300. It only makes sense to specify an execution variant if you have defined an event. The dunning proposal can be processed up to before printing of the dunning notice.


Dunning activity run is initiated in much the same way as a dunning proposal run. First the necessary parameters is given as input and then the program run is scheduled.  If the correct settings in Customizing are done, the date entered in the issue date field will appear on the dunning letter. It will also be displayed in the dunning history as the dunning execution date (MDRKD).

The DLs and appropriate dunning activities are determined based on the dunning groupings and items for dunning.

Dunning activities consist of a function module (such as FKK_SAMPLE_0350_CCC) and a correspondence form (optional).

It is a key representing an activity that is carried out in connection with the execution of a dunning run. Unlike a proposal run you cannot delete a dunning activity run after its execution, even if the intended action was not executed. Instead you must reverse the dunning run (transaction VPVC) or cancel the dunning for certain items.

In FSCD Choose Environment → Dunning History → Overview → Cancel (the button with the red arrow).

In the dunning history you can see dunning activities (charge documents and interest documents). On the selection screen you can specify (Selection by Print Date) whether you want to display dunning notices that have been executed or not executed. This allows you, for example, to specify that only dunnings without print date are to be selected. In the dunning history, you can display a text for the business partner. To do this you must set the Read Business Partner Details indicator. In this case, the system runs event 0391. As standard, a text appears with the name and address of the business partner. With a customer-specific function module defined in event 4700, you can adjust this text to meet your/client specific requirements.

The following events are used in conjunction with  the printing of the dunning notice/dunning activity run:

– 310 (Called within Event 1797) Before the first process interval in the dunning activity run (set application-specific data)

– 320 (Called within Event 1798) After the first process interval in the dunning activity run (reorganize or delete application-specific data)

– 330 Event before processing a new dunning header

– 340 Once all data on a dunning header has been read, you can modify it prior to final processing

– 360/361/362 Calculation of charges and structuring of charges documents

– 370 Calculation of interest and structuring of interest document

You can assign any number of dunning activities to various DLs.

E.g :

1) Print dunning form with different recipients (legal department of Insurance Co and so on)

2) Start workflow

3) Send note to agent/ clerk

4) Deactivate Installment Plan

You can define your own function modules for standard activities.

Configuration for Dunning can be done in IMG Implementation Guide -> SAP Insurance – > Collections/Disbursements-> Business Transactions -> Dunning

There are some attributes to control the dunning program and these attributes are configured according to the needs of the company.

1) Dunning procedure

2) Dunning level – > Dunning Activities

3) Dunning areas

To create a new dunning procedure (DP), you must perform the following activities:

1) Define dunning procedure (DP)

2) Define dunning levels (DL) for dunning procedure (DP)

3) Specify minimum/maximum amounts for the dunning levels (DLs)

4) Specify the desired dunning activities (DAs) for the dunning levels (DLs)

Important Tables – Configuration which can be maintained by transaction SM30 as well

TFK047A – Dunning Procedure

TFK047B – Dunning levels

TFK047C – Minimum amounts for Dunning

TFK047E/I/H – Charges

TFK047M – Dunning Activities

Important database tables related to Dunning

FKKMAKO – Dunning History Header data

FKKMAZE – Dunning History by Line iem

FKKMAKT – Dunning Activities

VVKKTRIMA – Dunning Status

Some FMs which can be used in Dunning;

1) Using Telephone dunning Function module FKK_SAMPLE_0350_TEL_ITEM allows to implement a new dunning activity in which the dunned business partner is included in a telephone list. A clerk then calls this business partner and works through the list. A list like this that has been generated by the dunning activity run can be forwarded to an external system (for example, a call center in mySAP CRM) automatically at event 1799, using function module FKK_TRANSFER_CALL_LIST_1799, or manually using report RFKKMADUTLTRANF. SAP provides function module FKK_CALLLIST_CRM_9010 as an example.

2) Dispute Management: The dunning proposal run also takes into account the dunning reductions resulting from clarification cases in Dispute Management (using function module FKK_SAMPLE_0335_DISPUTE). At event 0335 the dunning groups (I_FKKMAGRP) and dunning lines (I_FKKMAVS) are also transferred. The allocated dunning reduction amounts are also returned in the C_FKKMARED table.

Hope this will help you to understand the concept & configuration of Dunning by DP in FSCD and please feel free to rectify in case of any discrepancies.

This article bears no reference to any copyrighted material nor has any reference been taken from the same.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

Leave a Reply