SRM 4.0 (EBP 5.0) - Line Item SC approval, Completion required for new Line

Mark Pyc mark.pyc at gmail.com
Wed Jul 19 04:01:16 EDT 2006


G'day all,

Firstly thanks Miguel for your response. I've been distracted for a while
and have since been testing alternative concepts. I agree with you that
using standard completion (well modified std as you've described) does seem
the best option and I've gone through some redesign with the business to
make this a possible solution.

However now comes the next hurdle....

Can anyone confirm if they are using the Completion Workflow WS14000044 (or
modified copy) and the Line Item approval Workflow WS14500015? (Miguel I
wasn't sure if from the answer below you were using Line Item or just the
BAdI cart level).

*When an incomplete item is added to the cart during line item approval does
the Completion WF get invoked again?*
**
I believe it should. OSS are telling me it shouldn't.

Thanks,
Mark




On 6/6/06, Adao-Cruz, Miguel <miguel.adao-cruz at capgemini.com> wrote:
>
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060719/f438bf6b/attachment.htm


More information about the SAP-WUG mailing list