2016 Mar 14 2:38 AM
Hi gurus,
I am facing the following situation, we are not in a utility industry, but we use FICA as the AR system. Dunning is taking extremely long, and according to the performance traces FKKMAKO and FKKMAZE have a big impact on this performance. We are considering deleting entries from these tables (due to budget constraints we cant go thru the whole archiving process), what are the risks that we should consider if we take this path?
By the way, we dont trigger disconnection documents from dunning, but we trigger actions and calculate dunning charges. We will exclude the entries that have dunning charges still open.
Thanks for the advice.
Mario.
2016 Mar 14 2:57 PM
Hi Mario,
Deleting table entries is not a solution to solve performance issues.
As Dunning tables are tightly integrated with DFKKOP, so it will lead to System inconsistencies, if you go and delete the Dunning table entries.
Moreover, you will not be able to get the Dunning history for the delete items.
Have you identified whether its at the Proposal level or at the activity level.?
.
As next steps, check the following SAP notes, which talks about solving the performance issues for Dunning, depending on the SAP System version, that you are in
(a) Note 2129902
(b) Note 2105592
(c) Note 2000205
(d) Note 1997485
Check the Dunning events to see, if there is any customisation, which is having an impact on the performance. The important events to be checked are 1708,1712,0300,0302,0304,0311 etc
If the above options don't work, then raise an OSS with SAP and seek their advice on the same.
Hope it helps..
Thanks,
Amlan
2016 Mar 14 10:14 AM
Hi Mario,
Ideally I cannot recommend you to delete entries directly from Dunning table FKKMAKO and FKKMAZE as these entries will have dependencies on other FI-CA functions like Collections, Write-offs, Account Balance etc.
As you have already mentioned that your performance traces shows FKKMAKO and FKKMAZE have impact on performance, I would recommend you to check for any standard SAP Notes/KBAs first.
Please have a look at the below KBA:
2006250 - FPVA performance problems due to SEPA mandat check
SAP Notes:
2269280 - Performance issue in FKK_READ_DUNNING_HISTORY
2234724 - FI-CA: Schlussrunde in FPY1/FPMA/FPVB für gesperrte GPARTs
2216402 - FPM3: read from archive
2225483 - Long runtime in function module ISU_DB_GET_POS_DISC_RELEVANT
Also please go through the SAP SCN Wiki's which explains few aspects of Dunning and related performance issues:
https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=375621080
https://wiki.scn.sap.com/wiki/display/UIndustry/Dunning
Technically, try to introduce custom indexes to table if that helps.
After all these, if you really want to delete entries, then for each Contract Account get the current balance, check if its zero and also no related FI-CA Collection process are active and delete those entries, but this should be last option.
Hope this will help you in right direction.
Thanks,
Srini
2016 Mar 14 2:57 PM
Hi Mario,
Deleting table entries is not a solution to solve performance issues.
As Dunning tables are tightly integrated with DFKKOP, so it will lead to System inconsistencies, if you go and delete the Dunning table entries.
Moreover, you will not be able to get the Dunning history for the delete items.
Have you identified whether its at the Proposal level or at the activity level.?
.
As next steps, check the following SAP notes, which talks about solving the performance issues for Dunning, depending on the SAP System version, that you are in
(a) Note 2129902
(b) Note 2105592
(c) Note 2000205
(d) Note 1997485
Check the Dunning events to see, if there is any customisation, which is having an impact on the performance. The important events to be checked are 1708,1712,0300,0302,0304,0311 etc
If the above options don't work, then raise an OSS with SAP and seek their advice on the same.
Hope it helps..
Thanks,
Amlan
2016 Mar 14 3:22 PM
Hi Amlan,
What are the dependencies that you see with DFKKOP?
Thanks,
M.
2016 Apr 18 4:41 PM
Hi Amlan,
Regarding note 2000205, do you know what this means: Oracle Histogram must be created before.
Is this a task that must be performed after implementing the note?
Thanks,
Mario.
2016 Mar 14 10:18 PM
Hi Mario,
Deleting records from these tables is definitely not an option.
And, completely agreeing with Amlan, you will end up with numerous discrepancies in your system as FKKMAZE are directly linked with DFKKOP (dunned documen number OPBEL).
There would be too many dowsnstream impacts on that.
Apart from that, with the dunning charge document (FKKMAKO-MG1BL) if you delete entry from there, in FPL9 account balance screen you will never be able to trace back that which dunning run posted such documents.
Also, have you conisdered about the fact that those dunning histories that have been flown through BI/BW? If you delete them in FICA, how would you be able to cater the discrepancies between FICA and BW?
Best way to tackle this situation is to, check any custom enhancement in the FQEVENTS which are triggered during dunning proposal and activity.
Usually proposal takes a bit more time than activity, still it is worth checking the FMs attached to dunning activity and FQEVENTS of dunning activity.
If you know the issue is coming due to anything from a standard code, best way is to consult with SAP by raising OSS note.
Hope it helps.
Regards,
Bodhisattwa
2016 Mar 15 3:18 PM
Hi Bodhisattwa,
Off course we will not delete all entries, we where thinking of excluding all the entries that have dunning charges assigned, or some other conditions (e.g. the dunned document is still open, among others.). It is clear that if we take this option we will lose the dunning history, specially at document level.
However, from a process perspective I still dont see what kind of inconsistencies could be generated on the downstream processes. Does anyone can give an specific example of a risk on a downstream process?
Mario
2016 Mar 16 6:14 AM
Mario,
First of all you'll lose the dunning history of the document. Apart from that any dunning activity such as dunning chagres, letter correspondence and dunning telephone list will lose information as what dunning run has initiated them. Anyways, it is always recommended to consult with SAP in this regard.
Regards.
2016 Mar 15 6:54 AM
Hi Mario,
As Amlan mentioned about FQEVENTS, please check coding of all the enhancement done. First you need to identify which one is taking longer time its dunning proposal or dunning activity. Follow below steps
1. Execute dunning proposal and dunning activity separately to analyse which one is taking longer time.
2. Take help of technical person to find all the enhancements implemented related to dunning.
3. explain process and get code review done some technical person.
At last deleting entries from standard table is not solution of performance issue. So please dont do it.
Regards,
Gulrez
2016 Apr 18 9:33 PM
Hi,
Perhaps you are triggering Function Modules via Dunning Activities that are accessing some tables using non-indexed fields.
For example, reading Dunning History using Contract Account is slow. Business Partner is much faster. Putting an index on Contract Account in FKKMAKO will speed up access.
Please ensure your table accesses are using Indexed fields.
I hope this helps.
Regards,
Ivor
2022 Nov 17 9:00 PM
Hi Mario,
I know that delete the entries from does tables is a bad thing, so if you still face the problem, let me tell you I have the same issue, right now I'm looking at FM FKK_READ_DUNNING_HISTORY (use in event 1708), because is at this point were the volume of data is given a performance issue. I notice there is a parameter fast_dunning that limit the selection to 60 days.
Regards and sorry for my english
Cristian