Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

SRM Process Controlled Workflow:    n step Financial Approval Redetermination after completion step without restart.

In new process controlled workflow in SRM, we have option to configure n level ( for ex. SL approver) steps in the /SAPSRM/BD_WF_PROCESS_CONFIG badi. The badi gets called during shopping cart creation or when a restart has taken place. Hence after completion step if you want to have approval redetermination of your n levels, it is not possible until you trigger a restart. The approval determination may be necessary since during completion step shopping data could be changed(such as account assignment) which should result in new approvers.  The SAP recommendation in this case is to use the restart badi (SAP Note 1700677). However a restart will do a complete restart and this may not be a suitable solution for all the customers.

We have developed an alternative way of implementing N levels. This does approval redetermination all the time, so in every approval and completion steps without the need of restart.

The solution can be described below:

     1) Create a  Z table (similar to standard table /SAPSRM/D_WF_016) to store the approvers. In our case the table has below structure:

     2) Assume a maximum number of n steps(we assumed 10) and add them using /SAPSRM/BD_WF_PROCESS_CONFIG badi.

Append the 10 levels to z table. Approval determination will not take place here. Hence the records appended will be appended to z table without approvers. The level index will be stored in the z table against the level guid.

     3) For the mentioned n level step customized in workflow customizing, create an evaluation ID with an expression which calls a method of a class.

     4) In the Evaluation method(attached to BRF expression for evaluation id) we will do the approval determination. The evaluation method will be called many times depending on number of levels. But we want to do approval determination only once, hence we will use a static attribute GV_REDETERMINE to check that approval determination takes place only once.

In the method fin_appr_redetermin we do the actual approval redetermination.

When the last customized level has reached then we can set the static attribute GV_REDETERMINE. The level index can be read from the level guid from the z table.

     5) In the approval determination we update the approvers in the z table with actual approvers.

If for current level or later levels, if we find the approvers in z table then expression method should return as true (meaning the level will be executed) otherwise false.

     6) In the BADI /SAPSRM/BD_WF_RESP_RESOLVER Method /SAPSRM/IF_EX_WF_RESP_RESOLVER~GET_AREA_TO_ITEM_MAP store the LEVEL_GUID as leading object id during area instance creation.

        lo_area = /sapsrm/cl_wf_area=>/sapsrm/if_wf_area~create_instance(
iv_area_type        
= gc_area_type
iv_leading_object_id
= is_current_process_level-level_guid
).

     7) In the badi /SAPSRM/BD_WF_RESP_RESOLVER method /SAPSRM/IF_EX_WF_RESP_RESOLVER~GET_APPROVERS_BY_AREA_GUID read the z table again for the same level guid and add the approvers.

     😎 When the shopping cart is completely approved the z table can be cleared in order to keep the system clean. The table can be cleared in BBP_DOC_SAVE_BADI.

2 Comments