Dear SAPers!
With my blog post “Enhancements in EBS – BADI FIEB_CHANGE_BS_DATA” I’ve started a series of posts around enhancements in electronic bank statement processing. This post is a continuation of this series. Please check out my previous post for a deep dive into the topic.
This post describes a small utility tool for BADI FIEB_CHANGE_BS_DATA. Let me explain the context. I implemented this BADI on several projects and after the initial implementation I had to debug the interface often to analyze the feasibility for new requirements and/or troubleshoot existing issues. Some typical use cases:
As I mentioned in my original post, we can trigger the BADI implementing class and debug the code via GUI transaction FEB_BSPROC (i.e., by pressing the button “Scan”). But if you want to do so, the user must identify & report the issue in a timely manner and leave the item of the bank statement without further processing. That would be an ideal situation. However, more often the users report the issues after they manually processed the item. In this case, you no longer will be able to debug the BADI.
There is another typical issue which might complicate the analysis of this BADI. GUI transaction FEB_BSPROC is used for processing of bank statement and generates accounting postings. Therefore, a best practice for SAP production environments is to restrict the access of SAP support consultants to this transaction.
I’ve developed a simple program that addresses both challenges. Source code for this program is provided below:
The program provides a simple selection screen, where you can provide the reference to company code, bank statement key (FEBKO-KUKEY) and bank statement line item (FEBEP-ESNUM). The program selects the entries from tables FEBKO, FEBEP & FEBRE and saves them into local variables. Afterwards, the program creates an instance of the BADI implementing class, passes the variables to it and calls the interface method IF_EX_FIEB_CHANGE_BS_DATA~CHANGE_DATA.
Screenshot below shows you the interface of the debugger for this BADI:
You can use this tool to debug the BADI interface for bank statement items which were already (manually) processed / posted as well as for those that remain open. If you have the authorization for editing of the variables in debug mode, you can safely adjust the values via this tool. It will help you with the analysis but will not have any impact on the actual transactional data in the system. That assumes of course that you did not implement any logic that generates any commits to the database in the BADI.
Concluding notes
Some might say that the ideal way to approach the analysis of the issue would be to re-create it in the test and / or a development system. I agree with that in principle. But sometimes you might not even have a good understanding why the issue occurs and how to re-create a test data in the first place. In some cases, it might be very difficult to re-create the test data. I encountered a situation like this once and it took our team around a month to understand the issue and properly recreate it. All due to very complicated setup of authorization roles (GRC team did not want to grant the authorization for a transaction, which they considered very sensitive one).
This tool represents a useful and secure way to analyze / troubleshoot the interface of the BADI without any changes of actual transactional data in the system. Main drawback of this solution is that at the time, when you call this BADI, some of the values might be adjusted by the user. For example, the user might have provided the customer number manually during the post-processing. You will need to take that into account and make necessary adjustments during debugging.
Regards,
Bohdan
With my blog post “Enhancements in EBS – BADI FIEB_CHANGE_BS_DATA” I’ve started a series of posts around enhancements in electronic bank statement processing. This post is a continuation of this series. Please check out my previous post for a deep dive into the topic.
This post describes a small utility tool for BADI FIEB_CHANGE_BS_DATA. Let me explain the context. I implemented this BADI on several projects and after the initial implementation I had to debug the interface often to analyze the feasibility for new requirements and/or troubleshoot existing issues. Some typical use cases:
- The logic to search for open items does not work in some cases,
- The logic to search for a business partner could not identify the customer / vendor based on bank details etc.
As I mentioned in my original post, we can trigger the BADI implementing class and debug the code via GUI transaction FEB_BSPROC (i.e., by pressing the button “Scan”). But if you want to do so, the user must identify & report the issue in a timely manner and leave the item of the bank statement without further processing. That would be an ideal situation. However, more often the users report the issues after they manually processed the item. In this case, you no longer will be able to debug the BADI.
There is another typical issue which might complicate the analysis of this BADI. GUI transaction FEB_BSPROC is used for processing of bank statement and generates accounting postings. Therefore, a best practice for SAP production environments is to restrict the access of SAP support consultants to this transaction.
I’ve developed a simple program that addresses both challenges. Source code for this program is provided below:
*&---------------------------------------------------------------------*
*& Troubleshooting tool for BADI FIEB_CHANGE_BS_DATA
*&---------------------------------------------------------------------*
report zfi_fieb_change_bs_data_tool.
selection-screen begin of block a1 with frame title text-001.
parameters: p_bukrs type t001-bukrs obligatory default 'UA10'.
parameters: p_kukey type febep-kukey obligatory.
parameters: p_esnum type febep-esnum obligatory.
selection-screen end of block a1.
form start_badi_analysis.
" Select bank statement header line
data ls_febko type febko.
select single *
from febko
into corresponding fields of ls_febko
where bukrs = p_bukrs
and kukey = p_kukey.
" Select bank statement line
data ls_febep type febep.
select single *
from febep
into corresponding fields of ls_febep
where kukey = p_kukey
and esnum = p_esnum.
" Select note to payee data
data lt_febre type standard table of febre.
select *
from febre
into corresponding fields of table lt_febre
where kukey = p_kukey
and esnum = p_esnum.
" Empty FEBCL-table
data lt_febcl type standard table of febcl.
" Create an instance of the BADI for debugging purposes
data lo_badi type ref to zcl_im_fieb_change_bs_data.
create object lo_badi.
lo_badi->if_ex_fieb_change_bs_data~change_data(
exporting
i_testrun = abap_true
t_febre = lt_febre
changing
c_febko = ls_febko
c_febep = ls_febep
t_febcl = lt_febcl ).
endform.
start-of-selection.
perform start_badi_analysis.The program provides a simple selection screen, where you can provide the reference to company code, bank statement key (FEBKO-KUKEY) and bank statement line item (FEBEP-ESNUM). The program selects the entries from tables FEBKO, FEBEP & FEBRE and saves them into local variables. Afterwards, the program creates an instance of the BADI implementing class, passes the variables to it and calls the interface method IF_EX_FIEB_CHANGE_BS_DATA~CHANGE_DATA.
Screenshot below shows you the interface of the debugger for this BADI:
You can use this tool to debug the BADI interface for bank statement items which were already (manually) processed / posted as well as for those that remain open. If you have the authorization for editing of the variables in debug mode, you can safely adjust the values via this tool. It will help you with the analysis but will not have any impact on the actual transactional data in the system. That assumes of course that you did not implement any logic that generates any commits to the database in the BADI.
Concluding notes
Some might say that the ideal way to approach the analysis of the issue would be to re-create it in the test and / or a development system. I agree with that in principle. But sometimes you might not even have a good understanding why the issue occurs and how to re-create a test data in the first place. In some cases, it might be very difficult to re-create the test data. I encountered a situation like this once and it took our team around a month to understand the issue and properly recreate it. All due to very complicated setup of authorization roles (GRC team did not want to grant the authorization for a transaction, which they considered very sensitive one).
This tool represents a useful and secure way to analyze / troubleshoot the interface of the BADI without any changes of actual transactional data in the system. Main drawback of this solution is that at the time, when you call this BADI, some of the values might be adjusted by the user. For example, the user might have provided the customer number manually during the post-processing. You will need to take that into account and make necessary adjustments during debugging.
Regards,
Bohdan
- SAP Managed Tags:
