SRM 4.0 (EBP 5.0) - Logic of LIA BADI so requestor approves all changes

[Mark Pyc]

G'day all,

More questions from me on the line-item approval of Shopping carts I'm
afraid.

Within my required solution the first level approvers needs the ability to
change carts but the requester should be given the opportunity to review
these changes.

Access to change the cart is controlled via Personalisation Level
BBP_WFL_SECURITY. I figured that a value of 2 would be appropriate as this
is described as "Low - Workflow is always restarted when changes are made".
However with this setting if the Approver actually "Accepts/Approves" a line
and changes it, the only time the requester is informed is if the value of
the item changes. At this point the requester receives a Workitem based on
TS14508045 (from within WS14500013) to accept.

No other changes produce this behaviour. Rather the changes are simply made
and the cart approval continues. Changes to Free Text description (in the
case of Describe Requirement items), Prod.Cat, UoM, Delivery Date, Delivery
Address, Price & Qty (such that the value of the item doesn't change)
or even changing the name of the cart do not seemed to be considered
'significant' as the requester is not informed. Only if the value of the
item changes.

What I'd like is for any and all of these changes to result in the Cart
being sent back to the requester. It seems very strange that the value of
the item is the only important change. The requester doesn't necessarily
care if the value changes as long as it's approved, but a change to the text
of a free text item has to be considered crucial!?!

As an alternate concept I thought about simply using the BAdI to set
the requester as an approver for any changed items, but they would then need
to reject any items they weren't happy with and then accept their own
rejections (not very nice at all). Moving in this direction I set
the Approvers value for BBP_WFL_SECURITY to 4 (which is described as "High -
workflow is never restarted when changes are made" but this seemed to be no
different to a value of 2. Changes that change the line item value are sent
back for Requester review. This is messy as it means that my concept of
Requester as Approver will not be consistent as value changes will result in
the TS14508045 Workitems.


Is there a way to force any and all changes back to the Requester for
review?

I have read note 777133 about handling restarts, but as best I can tell this
restarts the approvals, but does not invoke a Requester review.

In reading the archives I saw a posting by Miguel Adao-Cruz that included
the statement:
>* I am not using "restart based on history tables" as **my client
wants **rejections
to be approved by requestors.
***
It sounds like you were doing what I'm hoping for Miguel. Can you provide
any insight? I'm hoping to use the first level of approval as a means of
line-item based completion (thanks for your previous responses).

I hope someone can help.

Have fun,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060605/87be9e57/attachment.htm