<div>G'day all,</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>However now comes the next hurdle....</div>
<div> </div>
<div>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).
</div>
<div> </div>
<div><strong>When an incomplete item is added to the cart during line item approval does the Completion WF get invoked again?</strong></div>
<div><strong></strong> </div>
<div>I believe it should. OSS are telling me it shouldn't. </div>
<div> </div>
<div>Thanks,<br>Mark</div>
<div> </div>
<div><br><br> </div>
<div><span class="gmail_quote">On 6/6/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 Mark,<br><br>My solution works the way you describe it (all users with level 2). It is<br>standard.<br>
Depending on BBP_WFL_SECURITY value the main workflow is restarted or not (I<br>think it as well check starts conditions) if shopping cart "changed",<br>"Changed" here means, changes according to SRM (I believe) hard-coded
<br>criterias which are more or less related to line item values. Main workflow<br>restarted means re-processing previously processed approval levels. It<br>doesn't directly influence if shopping cart is sent to requester and 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 means that<br>the price and/or the vendor will be missing (standard understanding of SRM
<br>for incomplete shopping carts). Adding the price will send the SC to the<br>requester. The problem will be that adding a vendor does not send SC to<br>requester (pay attention to the distention between "vendor" and "preferred
<br>vendor", usually approvers cannot add "vendors").<br>I would have a look at shopping cart change documents settings: 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 the
<br>vendor is changed/added, via a BADI and then remove it. (I already regret<br>what I have just writen!!)<br>You could maybe use the BADI for BBP_WFL_SECURITY, and change it's 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 client<br>requirements that make the standard completion workflow not usable.<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,DanaInfo=OWA.UKI.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: 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>allchanges<br><br><br>G'day all,<br><br>More questions from me on the line-item approval of Shopping carts I'm<br>afraid.<br><br>Within my required solution the first level approvers needs the ability to<br>change carts but the requester should be given the opportunity to 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 as this<br>is described as "Low - Workflow is always restarted when changes are made".
<br>However with this setting if the Approver actually "Accepts/Approves" a line<br>and changes it, the only time the requester is informed is if the value of<br>the item changes. At this point the requester receives a Workitem based on
<br>TS14508045 (from within WS14500013) to accept.<br><br>No other changes produce this behaviour. Rather the changes are simply made<br>and the cart approval continues. Changes to Free Text description (in the<br>case of Describe Requirement items),
Prod.Cat, UoM, Delivery Date, Delivery<br>Address, Price & Qty (such that the value of the item doesn't 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 the
<br>item changes.<br><br>What I'd like is for any and all of these changes to result in the Cart<br>being sent back to the requester. It seems very strange that the value of<br>the item is the only important change. The requester doesn't necessarily
<br>care if the value changes as long as it's approved, but a change to 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 the<br>requester as an approver for any changed items, but they would then 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 the<br>Approvers value for BBP_WFL_SECURITY to 4 (which is described as "High -
<br>workflow is never restarted when changes are made" but this seemed to be no<br>different to a value of 2. Changes that change the line item value are sent<br>back for Requester review. This is messy as it means that my concept of
<br>Requester as Approver will not be consistent as value changes will result in<br>the TS14508045 Workitems.<br><br><br>Is there a way to force any and all changes back to the Requester for<br>review?<br><br>I have read note 777133 about handling restarts, but as best I can 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 included<br>the statement:<br>> I am not using "restart based on history tables" as my client wants
<br>rejections to be approved by requestors.<br><br>It sounds like you were doing what I'm hoping for Miguel. Can you provide<br>any insight? I'm hoping to use the first level of approval as a 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></blockquote></div><br>