PR approval workflow: Prevent workflow re-triggering for total PR value decrease after approval

[#1]

Hi All,

We have implemented a purchase requisition approval workflow in our organisation, where all new PR's created are subject to approval before release & conversion to PO.

The workflow is set up to identify release strategy based on a number of characteristics for example: total PR value.

Approval levels & approver names are identified depending on the release strategy triggered.

The current functionality is set up to re-trigger the workflow if total PR value is changed after approval at any level.

e.g. a PR with three approval levels will re-trigger workflow if approved at level 1 and then the total value is changed; therefore a new release strategy will be determined.

A 2% tolerance limit has been set before the workflow re-triggers only if PR total value increases; with changeability value of: 4 (changeable, new release in case of new strat. or val. change).

The workflow is required to re-trigger if the total PR value has been increased after approval at any level, which is currently working correctly as desired.

Is it possible to prevent the workflow from re-triggering if the total PR value is decreased after approval at any level?

Any advice would be much appreciated.

Regards,

ZA

[Former Member]

Hello,

"The current functionality is set up to re-trigger the workflow if total PR value is changed after approval at any level."

How is that done? If it's a specific piece of ABAP code then (of course) you just have to adjust that.

Otherwise, is it the case that any significant change will do this? Is it done by creating an event?

regards

Rick Bakker

Hanabi

[zuber_ahmed]

Hi Rick,

'' How is that done? If it's a specific piece of ABAP code then (of course) you just have to adjust that.

Otherwise, is it the case that any significant change will do this? Is it done by creating an event? ''

This is not a triggered by piece of ABAP code or an event.

This is a configuration where a 2% tolerance limit has been set before the workflow re-triggers only if PR total value increases; with changeability value of: 4 (changeable, new release in case of new strat. or val. change).

Is it possible to prevent the workflow from re-triggering if the total PR value is decreased after approval at any level via the configuration?

Regards,

ZA

[Former Member]

hi,

In PO release limit you specify in customizing the lower and the upper limit of changes.

So in your case just put 100% as lower, this should only retrigger the approval process when the value is changed for more than 100%.

Kind regards, Rob Dielemans

[Former Member]

Hi Rob,

that for PR's -- and there's no such option like you have with the PO's.

Hi Rick,

the reset of the release code(s) of the PR is done during the check of the release strategy within the SAP Standard processing of ME5xN.

Hi Murali,

if the Standard has created such an event, there's no healing way to turn the requisition back to approved, if you avoided the event by check function. It's way too late.

Hi Zuber,

as you now know, it's not part of the SAP Standard to check for a lower limit rather than for a variance of the total value. However, there is a way to do so, as I've already implemented that customer requirement.

But before I explain that, let me tell you, that the similar process for PO's is also resetting all the releases, once a different release strategy would match. So this is a hard lower limit, regardless of the 2% (high/low) setting and such. My quick solution on that is not taking that detail into account: Regardless of how low you set it, there's no other release strategy chosen. If you wish so, you need to have a smarter algorithm. That's possible, too, but its not the right place here in such a post to describe that.

So here it goes:

• I anticipate that you're using PR Overall release strategy. If you're using item-based release, you need to adjust the following solution accordingly, and using the item-based user exit instead of the one for the overall release. It's ZXM06U13.
• You make use of the user exit M06B0005 (component ZXM06U31) for determination of the release strategy. Within that exit you can modify the values of the CEBAN structure that is used to determine the strategies. You've come across that structure already, as you've maintained the characteristics of the class (type 032) that you used for your classification values to assign the strategies.
• You don't need an additional field in that structure, but you could choose so. In the latter case create a new field ZZGFWRT, having the similar technical types as with the CEBAN-GFWRT.
• Within the user exit, you need to check, if the current requisition is being created (where you basically have to do nothing), or if the requisition has been created already (where you have to do a bit). Do this, by checking for the requisition number, which is transferred in the c_eban table, like...

FIELD-SYMBOLS: <ls_eban> TYPE EBAN.

READ TABLE c_eban ASSIGNING <ls_eban> INDEX 1.

IF sy-subrc <> 0.

   EXIT. "No requisition, no calculation

ENDIF.

SELECT COUNT( * ) FROM eban WHERE banfn = <ls_eban>-banfn.

IF sy-dbnct = 0. EXIT. ENDIF. "Nothing to do, at the moment

• If that check has passed, you need to now the total value of the requisition before the change. The field CEBAN-GFWRT is already having the new total value (after user change) assigned, so you need to calculate that by yourself to compare the both. I'd advice to use exactly the same coding part as the SAP standard calculates it, so avoid differences. This can be found in function group EBND, where the function module ME_REL_GENERAL_STRATEGY_EBAN calls form routine ceban_aufbauen_gesamtfrg of INCLUDE LEBNDF01. This is the basic algorithm for it, and you should adapt this to your needs:

DATA: lt_eban TYPE STANDARD TABLE OF EBAN.

"Read the previous state of the requisition from the database.

"You may reference the global table of YEBAN, if you feel safe to access it without

"breaching good programmer's guidelines.

SELECT * FROM EBAN INTO TABLE lt_eban WHERE banfn = <ls_eban>-banfn.

"Calculate the previous total net value.  (Use lines 706-710 of LEBNDF01 for full impl.)

DATA: lv_old_gfwrt TYPE CEBAN-GFWRT.

LOOP AT mt_eban ASSIGNING <ls_eban> WHERE loekz = SPACE.

  lv_old_gfwrt = lv_old_gfwrt + ( <ls_eban>-menge * <ls_eban>-preis / ls_eban-peinh / 1000 ).

  IF lv_old_gfwrt > 999999999999 OR lv_old_gfwrt < -999999999999.

     lv_old_gfwrt = 999999999999.

     EXIT. "No need to worry about further eban entries, once you've reached the max

  ENDIF.

ENDLOOP.

IF sy-subrc <> 0.

   "Somehwat strange, having an empty requisition at that stage... so it's better to

   EXIT.

ENDIF.

"Now, we got the old total value ready for comparison

IF ceban-gfwrt < lv_old_gfwrt.

   ceban-gfwrt = lv_old_gfwrt.  "Avoid changing release strategy, when new total is lower...

ENDIF.

• There're certainly other implementation options, too, like using the database field EBAN-RLWRT for comparison, or create a full black-/whitelist on field level, where you have a small expression editor that provides further customizing functionality. I did so once in a project and it's pretty nice to be more flexible. But for a first approach, I'd advice to keep the things more simple.
  

With the very best wishes

   Florin

[Former Member]

Hi Zuber,

Try in this way, create a check function module for the workflow with the condition (comparing b/w) of PR's old value and new value.

Regards,

Murali Krishna.

Message was edited by: Murali Krishna