<div>Thanks Miguel, although not what I wanted to hear really. It is possible to add incomplete items to a cart in process, so I guess I'll have to prevent it via BBP_DOC_CHECK_BADI. </div>
<div> </div>
<div>On a side note has anyone made use of the BAdI <strong>BBP_WFL_EMPL_WI_BADI</strong>? It doesn't come with any doco and I can't find a reference to it anywhere (WUG, SDN, OSS, Google). It does however seem to answer my original question about how to send all changes back to the Requestor.
</div>
<div> </div>
<div>Have fun,</div>
<div>Mark</div><br><br>
<div><span class="gmail_quote">On 7/19/06, <b class="gmail_sendername">Adao-Cruz, Miguel</b> <<a href="mailto:miguel.adao-cruz@capgemini.com">miguel.adao-cruz@capgemini.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi All,<br><br>Mark, OSS is right in saying it shouldn't, at least according to their<br>design. Business/process side it could be disputed but SAP cannot provide
<br>scenarios for all options (it is already quite complicated this way ;-).<br>In my last two implementations I used the shopping cart Line Item approval<br>workflow. You could try to make it work this way but I can already garantee
<br>you weeks of pain!<br>Because:<br>- The line item workflow is hard coded in the SAP standard code.<br>- Sometimes it is directly triggered by a WAPI function.<br>-->That's why it is not possible to create a Z copy of this template and
<br>used it (-->deadlines cannot be created the standard way)<br>- I don't have a system to check, but I dont' think that while in approval<br>process the system will allow you to add incomplete items --> you would need
<br>to at least use BADI for the check function<br>- I don't think you can start a completion workflow for a shopping cart in<br>approval process because of the internal status management (I don't even<br>think about trying to change this!)
<br>- The approval preview pane would be a mess with a shopping cart going for<br>completion, then approval, then completion again, then approval again!!<br>- Your time from shopping cart creation to PO output could become weeks.
<br>- ....<br><br>I heard that others implementations (not done by me) in some clients, to<br>comply with EU directives about tenders, run the completion workflow<br>(again?) after the approval. But, I never investigated it and anyway that's
<br>maybe not good for your client neither.<br><br>I would simply recommend:<br>- Approver to reject/delete shopping cart with a note to the creator<br>explaining why and the creator to recreate a new shopping cart with the
<br>additional incomplete line(s) (copying from the initial shopping cart).<br>- The approver to create another shopping cart with the additional<br>incomplete items (or ask the creator to create it) while the first shopping
<br>cart follows its approval process.<br><br>Hope it will help.<br><br>Cheers<br><br>___________________________________________________________________________<br>Miguel Adao-Cruz | Capgemini | London<br>Technology Services
<br>SAP Application Architect<br><br>T.+44-870-238-2927 | Int.700 2927 | <a href="http://www.capgemini.com">www.capgemini.com</a><br><<a href="file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft">
file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft</a><br>\Signatures\www.capgemini.com><br><br>Join the Collaborative Business Experience<br>___________________________________________________________________________
<br><br>________________________________<br><br>From: <a href="mailto:sap-wug-bounces@mit.edu">sap-wug-bounces@mit.edu</a> on behalf of Mark Pyc<br>Sent: Wed 19/07/2006 09:01<br>To: SAP Workflow Users' Group<br>Subject: SRM
4.0 (EBP 5.0) - Line Item SC approval,Completion required for<br>new Line<br><br><br>G'day all,<br><br>Firstly thanks Miguel for your response. I've been distracted for a while<br>and have since been testing alternative concepts. I agree with you that
<br>using standard completion (well modified std as you've described) does seem<br>the best option and I've gone through some redesign with the business to<br>make this a possible solution.<br><br>However now comes the next hurdle....
<br><br>Can anyone confirm if they are using the Completion Workflow WS14000044 (or<br>modified copy) and the Line Item approval Workflow WS14500015? (Miguel I<br>wasn't sure if from the answer below you were using Line Item or just the
<br>BAdI cart level).<br><br>When an incomplete item is added to the cart during line item approval does<br>the Completion WF get invoked again?<br><br>I believe it should. OSS are telling me it shouldn't.<br><br>Thanks,<br>
Mark<br><br><br><br><br>On 6/6/06, Adao-Cruz, Miguel <<a href="mailto:miguel.adao-cruz@capgemini.com">miguel.adao-cruz@capgemini.com</a>> wrote:<br><br> Hi Mark,<br><br> My solution works the way you describe it (all users with level 2).
<br>It is<br> standard.<br> Depending on BBP_WFL_SECURITY value the main workflow is restarted<br>or not (I<br> think it as well check starts conditions) if shopping cart<br>"changed",<br> "Changed" here means, changes according to SRM (I believe)
<br>hard-coded<br> criterias which are more or less related to line item values. Main<br>workflow<br> restarted means re-processing previously processed approval levels.<br>It<br> doesn't directly influence if shopping cart is sent to requester and
<br>which<br> type of changes should send it to requestor to accept changes.<br> If you are planning to use first approval level for completion it<br>means that<br> the price and/or the vendor will be missing (standard understanding
<br>of SRM<br> for incomplete shopping carts). Adding the price will send the SC to<br>the<br> requester. The problem will be that adding a vendor does not send SC<br>to<br> requester (pay attention to the distention between "vendor" and
<br>"preferred<br> vendor", usually approvers cannot add "vendors").<br> I would have a look at shopping cart change documents settings:<br>maybe it<br> influences the way SRM sees a shopping cart being changed.
<br> You could maybe increase the value of the line item by one cent if<br>the<br> vendor is changed/added, via a BADI and then remove it. (I already<br>regret<br> what I have just writen!!)<br> You could maybe use the BADI for BBP_WFL_SECURITY, and change it's
<br>value<br> depending on the user role and approval index.<br> etc...<br> But before going this way you could maybe explain what are your<br>client<br> requirements that make the standard completion workflow not usable.
<br><br> Cheers.<br><br><br>___________________________________________________________________________<br> Miguel Adao-Cruz | Capgemini | London<br> Technology Services<br> SAP Application Architect
<br><br> T.+44-870-238-2927 | Int.700 2927 | <a href="http://www.capgemini.com">www.capgemini.com</a><br><<a href="http://www.capgemini.com/">http://www.capgemini.com/</a>><br> <<br><a href="file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft">
file:///C:\Documents%20and%20Settings\madaocru\Application%20Data\Microsoft</a><br><file:///,DanaInfo=owa+C:\Documents%20and%20Settings\madaocru\Application%20<br>Data\Microsoft><br> \Signatures\www.capgemini.com,DanaInfo=
OWA.UKI.CAPGEMINI.COM+><br><br> Join the Collaborative Business Experience<br><br>___________________________________________________________________________<br><br> ________________________________<br><br>
From: <a href="mailto:sap-wug-bounces@mit.edu">sap-wug-bounces@mit.edu</a> on behalf of Mark Pyc<br> Sent: Mon 05/06/2006 18:08<br> To: WUG<br> Subject: SRM 4.0 (EBP 5.0) - Logic of LIA BADI so requestor approves
<br><br> allchanges<br><br><br> G'day all,<br><br> More questions from me on the line-item approval of Shopping carts<br>I'm<br> afraid.<br><br> Within my required solution the first level approvers needs the
<br>ability to<br> change carts but the requester should be given the opportunity to<br>review<br> these changes.<br><br> Access to change the cart is controlled via Personalisation Level<br> BBP_WFL_SECURITY. I figured that a value of 2 would be appropriate
<br>as this<br> is described as "Low - Workflow is always restarted when changes are<br>made".<br> However with this setting if the Approver actually<br>"Accepts/Approves" a line<br> and changes it, the only time the requester is informed is if the
<br>value of<br> the item changes. At this point the requester receives a Workitem<br>based on<br> TS14508045 (from within WS14500013) to accept.<br><br> No other changes produce this behaviour. Rather the changes are
<br>simply made<br> and the cart approval continues. Changes to Free Text description<br>(in the<br> case of Describe Requirement items), Prod.Cat, UoM, Delivery Date,<br>Delivery<br> Address, Price & Qty (such that the value of the item doesn't
<br>change) or<br> even changing the name of the cart do not seemed to be considered<br> 'significant' as the requester is not informed. Only if the value of<br>the<br> item changes.<br><br> What I'd like is for any and all of these changes to result in the
<br>Cart<br> being sent back to the requester. It seems very strange that the<br>value of<br> the item is the only important change. The requester doesn't<br>necessarily<br> care if the value changes as long as it's approved, but a change to
<br>the text<br> of a free text item has to be considered crucial!?!<br><br> As an alternate concept I thought about simply using the BAdI to set<br>the<br> requester as an approver for any changed items, but they would then
<br>need to<br> reject any items they weren't happy with and then accept their own<br> rejections (not very nice at all). Moving in this direction I set<br>the<br> Approvers value for BBP_WFL_SECURITY to 4 (which is described as
<br>"High -<br> workflow is never restarted when changes are made" but this seemed<br>to be no<br> different to a value of 2. Changes that change the line item value<br>are sent<br> back for Requester review. This is messy as it means that my concept
<br>of<br> Requester as Approver will not be consistent as value changes will<br>result in<br> the TS14508045 Workitems.<br><br><br> Is there a way to force any and all changes back to the Requester<br>for
<br> review?<br><br> I have read note 777133 about handling restarts, but as best I can<br>tell this<br> restarts the approvals, but does not invoke a Requester review.<br><br> In reading the archives I saw a posting by Miguel Adao-Cruz that
<br>included<br> the statement:<br> > I am not using "restart based on history tables" as my client<br>wants<br> rejections to be approved by requestors.<br><br> It sounds like you were doing what I'm hoping for Miguel. Can you
<br>provide<br> any insight? I'm hoping to use the first level of approval as a<br>means of<br> line-item based completion (thanks for your previous responses).<br><br> I hope someone can help.<br><br> Have fun,
<br> Mark<br><br> _______________________________________________<br> SAP-WUG mailing list<br> <a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug">
http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br><br><br><br><br><br><br>_______________________________________________<br>SAP-WUG mailing list<br><a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug">
http://mailman.mit.edu/mailman/listinfo/sap-wug</a><br><br><br></blockquote></div><br>