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

Tue Jun 6 13:32:07 EDT 2006

Hi Mark,

My solution works the way you describe it (all users with level 2). It is
standard.
Depending on BBP_WFL_SECURITY value the main workflow is restarted or not (I
think it as well check starts conditions) if shopping cart "changed",
"Changed" here means, changes according to SRM (I believe) hard-coded
criterias which are more or less related to line item values. Main workflow
restarted means re-processing previously processed approval levels. It
doesn't directly influence if shopping cart is sent to requester and which
type of changes should send it to requestor to accept changes.
If you are planning to use first approval level for completion it means that
the price and/or the vendor will be missing (standard understanding of SRM
for incomplete shopping carts). Adding the price will send the SC to the
requester. The problem will be that adding a vendor does not send SC to
requester (pay attention to the distention between "vendor" and "preferred
vendor", usually approvers cannot add "vendors").
I would have a look at shopping cart change documents settings: maybe it
influences the way SRM sees a shopping cart being changed.
You could maybe increase the value of the line item by one cent if the
vendor is changed/added, via a BADI and then remove it. (I already regret
what I have just writen!!)
You could maybe use the BADI for BBP_WFL_SECURITY, and change it's value
depending on the user role and approval index.
etc...
But before going this way you could maybe explain what are your client
requirements that make the standard completion workflow not usable.

Cheers.

___________________________________________________________________________
Miguel Adao-Cruz | Capgemini | London
Technology Services
SAP Application Architect

T.+44-870-238-2927 | Int.700 2927 | www.capgemini.com
<file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft
\Signatures\www.capgemini.com,DanaInfo=OWA.UKI.CAPGEMINI.COM+> 

Join the Collaborative Business Experience
___________________________________________________________________________

________________________________

From: sap-wug-bounces at mit.edu on behalf of Mark Pyc
Sent: Mon 05/06/2006 18:08
To: WUG
Subject: SRM 4.0 (EBP 5.0) - Logic of LIA BADI so requestor approves
allchanges

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8667 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20060606/7a12a68d/attachment.bin
-------------- next part --------------
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.