Q1. What do I do if errors occurred in the dunning activity run and if the system therefore executed only part of the dunning notices of the dunning proposal?
After you have corrected the cause of the error, you can start another dunning activity run which refers to the same dunning proposal run. This dunning activity run will only select dunning notices which have not received a print date (= execution date). If a lot of time has passed, it might be useful to manually cancel the dunning notices which have not been executed from the dunning history or to cancel them in mass run FPVC and then to start a new dunning proposal run.
Q2: My dunning activity run generates correspondence container entries which I print with the mass run for the correspondence print (FPCOPARA). How can I avoid printing dunning notices which have already been cancelled?
Always print immediately after the dunning activity run and see 526624.
Q3: How do I define event 0350 (Dunning activities)?
You should not store a customer-specific function module for event 0350 (in Customizing with the customer-specific program enhancements). Instead, define the dunning activities in Customizing under:
-> Dunning
-> Contract accounts receivable and payable
-> Business transactions
-> Dunning
-> Configure dunning activities
Enter the dunning activities for the desired dunning level into the dunning procedures. In this context see 487357.
Q4: Why do the "Free selections" not function as expected with the proposal run?
This is because the free selections refer to fields of the table of the items (DFKKOP) ONLY. Examples:
The dunning procedure (DFKKOP-MAHNV) is generally in the contract account and not in the item. Therefore, you cannot use it in order to select.
The dunning block indicator field (DFKKOP-MAHNSP) is no longer used. The locks are in table DFKKLOCKS.
Q5: What do I have to consider with the "Dunning control of other procedures" indicator?
Read the F1 Help for the field. If the flag is NOT activated, the system includes dunnings from other dunning procedures. Therefore, dunning procedures to which an item can change (Relocation dunning procedure) must at least have as many levels as the other dunning procedures.
Q6: With the "Print all items" function, the system also prints items on the dunning notice which are not due for dunning. How can I then print the total of all printed items?
You can do this by carrying out the totaling in your dunning form in the "user exit during loop" of the "OPEN_ITEM" level and by then printing the total. Do NOT forget to reset this total in the "user exit after loop".
Q7: The dunning run does not lead to the result which I expect but I do not know why.
Delete or cancel the dunning run. Start a new run with the same parameters and select "Additional information" in the application log and analyze the messages of the log after the run.
Q8: To which contract, and to which contract account does the system post dunning charges?
The dunning charges are posted like they are defined in events 360, 361 and 362. Event 363 (as of Release 4.62) determines the contract account and/or the contract onto which the charge is posted. If these events are not defined, the system posts the charges according to the first dunning line.
Q9: The system displays an item as a line in the FPM3 dunning history, but there is no dunning history in the account balance or in the document display.
In the account balance - (FPL9) and document display (FPE3), the system displays the dunning history only if the dunning activity has been executed and if the item has not been included as informing item in the dunning notice.
Q10: The minimum/maximum amount is not reached although the dunning balance is higher than the minimum/maximum amount.
The amounts of the items with the highest dunning level within the dunning grouping are added. The system compares this amount with the minimum/maximum amount. If the minimum/maximum is not reached, the system adds the amounts of the items with the next-lowest dunning level to this total. Then the system compares this new total to the minimum/maximum amount of this dunning level and so on until the minimum/maximum amount is reached. Then the system duns in the level the minimum/maximum amount of which has been reached.
Q11: How can I accelerate the dunning run?
As for all mass activities, the following applies: Use intervals and use several jobs if several computers are available. You should find the optimum by performing your own tests.
Use large, connected selection intervals if possible. If possible, you should use neither single selections nor "free selections". Check all events which you have defined for performance. Check the performance of your dunning activities. With large, productive routine runs, switch the application log to a lower problem class.
Q12: Which form do I use for the dunning?
You should definitely use a form from the correct form class. These are:
FI_CA_DUNNING generally for open item accounting (FI_CA_DUNNING_NEW from ERP 2005)
FMCA_DUNNING for IS-PS-CA (FI_CA_DUNNING_NEW from ERP 2005)
IS_U_CA_DUNNING for IS-U and IS-T
ISM_CA_DUNNING for IS-M
You can continue to use FI_CA_DUNNING and FMCA_DUNNING also as of ERP 2005. However, there will be no enhancement of the levels for new developments. Therefore, FI_CA_DUNNING_NEW is recommended.
When you print the account information from within the dunning activity the system prints a form of the IS_U_CA_ACCTINFO class. See 628840.
Q13: Why does the system not reverse all dunning activities with the dunning reversal?
It is not possible to reverse all dunning activities (for example, dunning notice printout, see 526624). The system deactivates the lock document generated by the dunning notice in IS-U. The reversal of dunning activities occurs in event 0395. Search for function modules with character string "_0395".
Q14: In the F4 Help for the dunning identification, the system displays an identification twice.
You used a very long selection with the general accruals/deferrals of this dunning run. This mainly occurs a text file is uploaded. This is not an error. You can select the first of both entries. Long single selections, however, increase the runtime. Instead, use dunning locks in the contract accounts which are limited with regard to time.
Q15: How can I find the correct event?
See 429810.
Q16: After you have manually implemented a correction for the dunning forms, you cannot see any effect.
Regenerate the forms for the form class. Even after the import of Add-On Support Packages you have to recreate the forms.
Q17: Why does the system reduce the dunning level of an item?
This is because the minimum/maximum amount for the higher dunning level has no longer been achieved. The item was partially cleared (371026) or other items which ensured the achievement of the minimum/maximum amount before, were cleared or the items were grouped elsewhere.
In this case, note the "Do not reduce dunning levels" indicator in the dunning procedure.
Q18: Why did the system not increase the dunning level of a dunned item?
- Because the "always dun" indicator is active in the dunning level.
- Because the "print all items" indicator is active and the item is not due for dunning.
- Because you manually activated the "new dunning level" for the old dunning level.
- Because new receivables became dunnable. On this subject see 187816.
Q19: How can I change the dunning grouping?
You can do this by activating the required fields in Customizing. If this does not meet your requirements, you can define event 304.
Q20: How can I prevent repeated dunning on the same level?
As of Release 4.64, there is an indicator for a rule for additional receivables with the description "Consideration with the dunning level of the creating reminder notices." Define a rule for additional receivables with this indicator and store this rule for the subtransactions with which the dunning charges and dunning interests are posted. Additional information is available in 597489.
Q21: Which fields must exist in all dunning grouping types?
Industries, which do not use the general recipient control for the dunning but which can enter an alternative dunning recipient (FKKVKP-ABWMA) and a corresponding address (FKKVKP-ADRMA) in the contract account (IS-U and IS-T, but not IS-PS-CA), must enter the fields ABWMA and ADRMA and all grouping categories. For cross-contract account dunning, field MGRUP should exist in the grouping category.
Field OPBUK is implicitly a grouping field, even if you do not specify it in the grouping category.
Ensure that a dunning group type SPACE also exists.
Q22: Is it possible to group by dunning level?
You have to differentiate whether you want to group by the existing dunning level or by the dunning level to be newly assigned.
As of Release 4.64 you can use fields MAHNN (new dunning level) and MSTNN (new dunning level category) for the grouping.
For a grouping by the existing dunning level see 403244.
Q23: In the contract account, a payment lock and an incoming payment method is active. In spite of that, the system displays the message "Incoming payment method exists" in the application log and the system does not dun.
The contract account is paid via another contract account. This, however, does not contain any payment lock.
584562 changes the function in such a way that the system considers payment locks of both contract accounts involved.
Q24: Why does an item achieve a dunning level whose dunning rhythm has not been achieved?
The system compares with the dunning rhythm of the dunning level of the entire dunning notice. Therefore the dunning rhythm should increase with the dunning level or remain the same, but it should not decrease.
Q25: The dunning run locks many business partners for a long time.
The dunning run always locks the interval which is currently processed as all mass activities do. You should therefore use smaller intervals.
If you have specified company codes in the dunning proposal run, the system locks the business partners only for the respective company codes during the corresponding dunning activity run.
Read Here for More SAP BASIS Transaction Codes.
Q26: Why do I receive several dunning notices when I expect only one?
This is because the dunned items have been divided into several groups. Check:
- The dunning grouping fields in Customizing.
- The dunning procedure of the individual items. The dunning procedure can exist in the contract account, in the contract (possibly as relocation procedure) or in the item (relocation procedure or manually).
- Whether an alternative installment plan dunning procedure has been maintained for the dunning procedure.
Q27: Can I dun items with different transaction currencies together?
Yes, WAERS does not have to be a dunning grouping field. In this case, the balances and thus the comparison with the minimum/maximum amounts as well are defined in the local currency of the company code. You cannot dun items together that have a different transaction currency and local currency.
Q28: How do I move dunning runs?
In Transactions FPVA or FPVB, you can manually copy the parameter records of dunning proposal runs and dunning activity runs to another run ID with offset data.
In addition you can use report RFKK_MASS_ACT_PARAMETER for that purpose.
Q29: How can I change the current dunning level of an item?
You cannot change the current dunning level of an item. In the dunning history you can set the next dunning level of an item manually. The item will get this dunning level only after the next dunning notice.
Q30: Why does the system print in a simulated mass activity run?
This is because the dunning notice printout is mostly tested with the simulation of the activity run.
Q31: If I often simulate an activity run with which the system prints with the correspondence container, does the system then fill the correspondence container every time?
If you print after the first simulation run (FPCOPARA), the system writes again into the correspondence container during the second simulation. You can print again. However, if you do not print between two simulation runs, you can print only once afterwards.
Q32: What does the "Print date" field in the dunning history mean?
It is the date of the execution of the dunning notice, that means the (not simulated) dunning activity run. The name originates in the fact that the print is the most important dunning activity. If you print via the correspondence container, the system sets the print date already during the generation of the correspondence container, which means before the dunning notice is printed on paper.
Q33: How can I fill additional, own fields in the dunning history?
You do this by defining event 0308. It is available as of Release 4.64.
Q34: Why does the billing not generate a dunning notice, even though this is set to do so in Customizing?
Check the "Set dunning level" (TFK047B-XEXTM) indicator in the Customizing of the dunning level. Consider the F1 help in this context.
Q35: Why does the system not execute any dunning activities after the dunning in the billing?
Because the system executes the dunning in the billing in order to be able to print the dunning information onto the invoice during the invoice printout. Thus, the dunning activities maintained in the dunning Customizing become superfluous. During the invoice printout, the system sets the print date (FKKMAKO-MDRKD) into the dunning letter header.
Q36: Why do the balanced items not transfer the dunning level of the item after a partial clearing?
The items themselves do not have dunning levels. A dunning history is written. The information is then: Item 4711 was dunned on 01.01.2002 because then 1000 # were outstanding. After a partial clearing, the cleared sub-item does not inherit any dunning information because it also has not been dunned. The dunned amount in the dunning history thus refers to the previously dunned amount.
Q37: Why are the amount of an item and the dunned amount of the last dunning notice for this item not equal?
This is because the item has been partially cleared in the meantime.
Q38: How does the factory calendar work with the dunning?
Let us assume for the dunning procedure in the dunning Customizing, you set the "Factory calendar" indicator, maintained the "Factory calendar ID", and in the factory calendar itself Saturday and Sunday are maintained as public holidays. Let us assume a receivable is due on Friday. In this case, the following days in arrears apply to this receivable: On Friday 0, on Saturday 1, on Sunday 1, on Monday 1 and only on Tuesday 2. Thus, if you dun on a public holiday (date of issue) the system calculates the days in arrears for the next working day.
Q39: How does the system calculate the payment target?
The payment target (FKKMAKO-FRDAT) defines the day on which a customer is supposed to settle the receivables. The payment target corresponds to the date of issue (FKKMAKO-AUSDT) of the dunning notice plus the number of days which are set as the payment deadline (TFK047B-FRIST). You can maintain the payment deadline in the Customizing of the dunning level. The system uses the payment deadline of the dunning level (FKKMAKO-MAHNS) to calculate the payment target and not the dunning level of the dunning lines (FKKMAZE-MAHNS). The calculation of the payment target depends on the Customizing of the factory calendar. If you defined a factory calendar ID, the dunning program sets the payment target to the first working day after the payment deadline. Otherwise, the payment target might also be on a public holiday. Thus, public holidays between the date of issue and the payment target are not subtracted. The "Factory calendar" TFK047A-XMFAC indicator does not have any effect here.
Q40: In the dunning activity run, you deactivate the installment plan. Why does the source receivable get no dunning history? Why does the system dun the source receivable on the first dunning level during the next dunning run?
There is no dunning history for the source receivable, because the source receivable was not dunned. The installments were dunned. After the deactivation of the installment plan the source receivable is open again and can be dunned, however, as of the dunning level that it had before the creation of the installment plan.
After the deactivation of the installment plan, the installments do not exist any longer as open items. Therefore, they are neither available anymore in a form that works with level OPEN_ITEM. These items can be printed if you use a form for the installment dunning procedure with form level DUNN_ITEM. In this case, the system uses the items from the dunning rows.
Q41: The dunning activities (Shift+F2) from dunning history FPM3 are not displayed in the language expected.
On this subject, see 645984.
Q42: In the standard module for the charge posting (callup point 360/ 361/ 362) the current date is copied to the charges document as the document date and the posting date. However, the issue date should be used.
You can change the document date and the posting date by creating an installation-specific module that calls the standard module. C_FKKKO-BLDAT, C_FKKKO-BUDAT, T_FKKOP-BLDAT and T_FKKOP-BUDAT can then be changed.
Q43: An incoming payment method is defined in the contract account. Normally the items are not dunned for this contract account. However, I nevertheless need to dun certain items (for example, dependent on the incoming payment method).
Define an installation-specific function module for the 0365 event. If the E_XCASH parameter is set to 'X,' the item currently processed is not dunned.