Business Transaction Events → Process Interface (Info-systems Process)
→ To refer detailed discussion on BTE and a scenario on printing of dunning notice refer my Wiki,
→ Dunning -
It is a process by which reminders are sent to the customers requesting them to pay their dues for their respective 'Open items'. These reminders are automatically sent based on the 'Dunning procedure', 'dunning area' and 'dunning level' mainly which are maintained in the 'Customized settings'.
Also, the form (notice) to be printed based on the logic of 'dunning level' is assigned in the customized settings.
If the customer fails to pay the requested amount within the due dates, firstly the customer loses the opportunities to avail some discount schemes as well as when the final gentle notice a
'Legal notice' is sent to the customer with some surcharge based on certain calculations.
These settings are performed by the FI consultant, but just to show the standard form maintained observe the entry, 'Financial Accounting' - 'Accounts Receivable and Accounts Payable' -
'Business transactions' - 'Dunning' - 'Printout' - 'Assign dunning forms'.
Another way to do that is 'Dunning' - 'Dunning Procedure' - 'Dunning Texts'.
Here, this scenario deals with the 'Process Interface' for event '00001060' (OPEN_FI_PERFORM_00001060_P) which as per SAP documentation says,
"This process makes it possible to overwrite the fields that indicate whether the item is to be dunned. This means that you can include just the items you require on the dunning notice, and exclude those you do not wish to appear on the dunning notice. Unlike process 00001061, however, the item remains in the table and is processed according to the indicator assigned to it".
→ Consider a business scenario in which a customer may have an 'Incoming payment' method active (say) 'AU' - 'Bankabbuchung' and 'Überweisung' respectively.
→ In such a case dunning is not possible and to print a dunning notice.
→ But, in business aspects irrespective of the incoming payment method active the dunning notice has to be sent to the customer as that will impact the business.
→ So, we have a BTE which will allows printing the dunning notice inspite of an 'Incoming payment' method active without changing the method or the indicator.
→ Also, this BTE can block the entire customer to be dunned, although in the customer master shows 'Free for dunning' indicator (that is space).
→ To start with we observe the standard process,
→ Go to transaction 'F150' for dunning and maintain the parameters first.
→ Make a dunning scheduling run and give the printing instructions.
→ After the run, observe the 'Dunning log', due the 'incoming payment' method there is no 'scheduling' and 'printing' of dunning notice.
→ Now, to make it possible to send a reminder about the over-due items of the customer to be paid we need to send it irrespective of any incoming payment method, BTE comes for the rescue.
→ Go to the BTE transaction 'FIBF'.
→ Execute the transaction and select the desired BTE for the requirement.
→ First after reading the documentation, analyze the sample function module.
→ Make a copy of the standard function module under 'customer' namespace.
→ Write the code as per requirement. Here, just to measure the extent of functionality to be achieved I have enabled or disabled certain interface parameters available in this function module.
→ I have passed the value 'Space' to the parameter 'C_XZALB' which is 'Indicator: items payable (not to be dunned)?'
→ When there is a payment method 'Incoming' especially active then the value of the parameter 'C_XZALB' or 'MHND-XZALB' becomes 'X' and the dunning notice does not get printed.
→ To observe the overriding of the parameter 'MHND-XZALB' without actually changing the value in the master table, debug the application.
→ First, go to transaction 'F150' - Dunning and fill in the necessary parameters,
→ Then schedule the dunning run.
→ After scheduling confirm that the run and the print is complete,
→ Also, confirm the log and the desired functionality has been achieved inspite of an incoming payment method.
→ I would suggest going for background debugging for understanding the complete process and the functionality enhancement.
→ See the desired BTE process is in the list and as there is some active customer/partner product registered the value 'EMPTY' is not 'X'.
→ At last things must go perfect when you see an entry of our function module in the table (customer table) 'APCUSTAB', check this out.
→ Before our customer enhancement code is encountered the status of the original functionality is 'Dunning notice not to be printed', confirm it this way.
→ Observe the parameters 'C_XFAEL', 'C_XZALB' and 'C_MANSP' respectively.
→ Now, when our functionality is triggered, observe the change. The parameter 'C_XZALB' has been changed to (Space).
→ Observe the notice which gets printed inspite of 'incoming payment' method.
→ Here to utilize the functionality of BTE 00001060 process interface, we consider another scenario in the case when a customer has to be blocked temporarily without changing the master data. Then this BTE can make a difference.
→ Note: I would suggest you to follow the same process for scheduling a dunning run and printing as demonstrated before.
→ In the customer master the 'Dunning block' is not active or the status is 'Freed for dunning'. Which means the customer can be dunned and notice can be printed.
→ In order to block the customer without changing the customer master, creating our own customer implementation will make this possible.
→ So, here the same process is followed,
→ Transaction 'FIBF' - Process Interface - Event 00001060 (Check MHND) - sample function module (with documentation)
→ Copy the standard sample function module to customer name space and observe the parameters set.
→ Here the parameter 'C_MANSP' indicates the dunning block. If this indicator is set 'X', then the customer status is set as 'blocked'.
→ Now, after dunning run is processed view the log to check the status.
→ As the customer is blocked the dunning notice will not be printed.