<div>G'day all,</div>
<div> </div>
<div>More questions from me on the line-item approval of Shopping carts I'm afraid.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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!?!
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div> </div>
<div>Is there a way to force any and all changes back to the Requester for review?</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>In reading the archives I saw a posting by Miguel Adao-Cruz that included the statement:</div>
<div>><i> I am not using "restart based on history tables" as </i><i>my client wants </i><i>rejections to be approved by requestors.<br></i><i></i></div>
<div>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).</div>
<div> </div>
<div>I hope someone can help.</div>
<div> </div>
<div>Have fun,</div>
<div>Mark</div>