<DIV>Hi Jocelyn,</DIV>
<DIV> </DIV>
<DIV>I can see that approval workflow restart when we change A/c assignment details or product category....This is happening as new shopping cart(new entries /v EBP2.0) has been creating in system for above changes.</DIV>
<DIV> </DIV>
<DIV>Cheers</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><BR><B><I>"Dart, Jocelyn" <jocelyn.dart@sap.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">No really you're ok Sue - the standard whole shopping cart BADI approval<BR>workflow restarts as normal based on workflow security and what changes<BR>were made. You shouldn't have to raise any special events for approvers<BR>restarting based on rejection or change. <BR><BR>The only event you may want to keep is your Profit Center event - the<BR>trick with that however is it won't be enough to re-evaluate rules on<BR>active work items - you also need to rerun the BADI to recalculate the<BR>approvers and fill the workflow container appropriately. Otherwise your<BR>new approvers may not be able to action the shopping cart correctly. <BR><BR>You might have to create a parallel workflow as well as using<BR>re-evaluate rules. <BR><BR><BR>Regards,<BR>Jocelyn Dart<BR>Senior Consultant<BR>SAP Australia Pty Ltd.<BR>Level 1/168 Walker St.<BR>North Sydney <BR>NSW, 2060<BR>Australia<BR>T!
+61 412
390 267<BR>M + 61 412 390 267<BR>E jocelyn.dart@sap.com<BR>http://www.sap.com<BR><BR>The information contained in or attached to this electronic transmission<BR>is confidential and may be legally privileged. It is intended only for<BR>the person or entity to which it is addressed. If you are not the<BR>intended recipient, you are hereby notified that any distribution,<BR>copying, review, retransmission, dissemination or other use of this<BR>electronic transmission or the information contained in it is strictly<BR>prohibited. If you have received this electronic transmission in error,<BR>please immediately contact the sender to arrange for the return of the<BR>original documents. <BR>Electronic transmission cannot be guaranteed to be secure and<BR>accordingly, the sender does not accept liability for any such data<BR>corruption, interception, unauthorized amendment, viruses, delays or the<BR>consequences thereof.<BR>Any views expressed in this electronic transmission are tho!
se of
the<BR>individual sender, except where the message states otherwise and the<BR>sender is authorized to state them to be the views of SAP AG or any of<BR>its subsidiaries. SAP AG, its subsidiaries, and their directors,<BR>officers and employees make no representation nor accept any liability<BR>for the accuracy or completeness of the views or information contained<BR>herein. Please be aware that the furnishing of any pricing information/<BR>business proposal herein is indicative only, is subject to change and<BR>shall not be construed as an offer or as constituting a binding<BR>agreement on the part of SAP AG or any of its subsidiaries to enter into<BR>any relationship, unless otherwise expressly stated. <BR><BR><BR>-----Original Message-----<BR>From: sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On Behalf<BR>Of Sue Keohan<BR>Sent: Wednesday, 02 November 2005 1:02 PM<BR>To: SAP Workflow Users' Group<BR>Subject: Re: SRM BAdi-n step for Shopping Carts<BR><BR>Hi
Jocelyn,<BR><BR>I was thinking to raise custom events when master data on the R/3 side <BR>changes, for example, Profit Center, which usually means a re-org, and <BR>in that case, new approvers. The Events under the workflow header, <BR>version dependent tab, would seem to be able to do this 'Reevaluate <BR>Rules of Active Workitems', but of course, seeing is believing.<BR><BR>I am interested in whole Shopping Cart Approvals via the BAdi, not Item <BR>Approval. So, for that part at least, pheww! As for the BAdi, it may <BR>prove challenging, as our business process calls for certain approvers <BR>(at 'level 1') to be able to 'restart' approvals at the point where the <BR>last rejection occurred, or 'begin anew'. The BAdi would need to take <BR>this into consideration. Looks like I have my work cut out for me.<BR><BR>Best regards,<BR>Sue<BR><BR><BR>Dart, Jocelyn wrote:<BR><BR>>Hi Sue, <BR>>You don't need to raise any special events to restart when the user<BR>>chang!
es it.
<BR>>The standard code will work out what happens next and whether to remove<BR>>approval tasks from certain users based on what you send out in the<BR>>BADI. <BR>>So you just need to concentrate on getting your BADI code correct -<BR>i.e.<BR>>to say "who does it go to next". <BR>><BR>>By the way, are you just looking at whole ShopCart BADI approval or the<BR>>ShopCart Item approval?<BR>>It's a lot more complicated for ShopCart Item approval but I've just<BR>>done it at a customer with a hideously<BR>>complex business scenario, so should be able to answer any questions. <BR>><BR>>Regards,<BR>>Jocelyn Dart<BR>>Senior Consultant<BR>>SAP Australia Pty Ltd.<BR>>Level 1/168 Walker St.<BR>>North Sydney <BR>>NSW, 2060<BR>>Australia<BR>>T +61 412 390 267<BR>>M + 61 412 390 267<BR>>E jocelyn.dart@sap.com<BR>>http://www.sap.com<BR>><BR>>The information contained in or attached to this
electronic<BR>transmission<BR>>is confidential and may be legally privileged. It is intended only for<BR>>the person or entity to which it is addressed. If you are not the<BR>>intended recipient, you are hereby notified that any distribution,<BR>>copying, review, retransmission, dissemination or other use of this<BR>>electronic transmission or the information contained in it is strictly<BR>>prohibited. If you have received this electronic transmission in error,<BR>>please immediately contact the sender to arrange for the return of the<BR>>original documents. <BR>>Electronic transmission cannot be guaranteed to be secure and<BR>>accordingly, the sender does not accept liability for any such data<BR>>corruption, interception, unauthorized amendment, viruses, delays or<BR>the<BR>>consequences thereof.<BR>>Any views expressed in this electronic transmission are those of the<BR>>individual sender, except where the message states otherwis!
e and
the<BR>>sender is authorized to state them to be the views of SAP AG or any of<BR>>its subsidiaries. SAP AG, its subsidiaries, and their directors,<BR>>officers and employees make no representation nor accept any liability<BR>>for the accuracy or completeness of the views or information contained<BR>>herein. Please be aware that the furnishing of any pricing information/<BR>>business proposal herein is indicative only, is subject to change and<BR>>shall not be construed as an offer or as constituting a binding<BR>>agreement on the part of SAP AG or any of its subsidiaries to enter<BR>into<BR>>any relationship, unless otherwise expressly stated. <BR>><BR>><BR>>-----Original Message-----<BR>>From: sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On<BR>Behalf<BR>>Of Baunach, Natasha R<BR>>Sent: Wednesday, 02 November 2005 8:01 AM<BR>>To: SAP Workflow Users' Group<BR>>Subject: RE: SRM BAdi-n step for Shopping
Carts<BR>><BR>>Sue,<BR>><BR>>You are correct that the value in BBP_WFL_SECURITY is the key to<BR>>allowing/prohibiting changes to shopping carts during approvals (even<BR>>though they all use the same task). Please keep in mind that if the<BR>>value is set to 'not defined', SAP has added the code in the BADI<BR>>BBP_WFL_SECUR_BADI, implementation BBP_WFL_SECUR_BADI_S to change it to<BR>>4 (I think it comes in as activated) which is equivalent to no changes<BR>>are allowed.<BR>><BR>> if scenario is initial .<BR>> call function 'BBP_PDH_WFL_SECLEVEL_DB_GET'<BR>> exporting<BR>> iv_user = actual_user<BR>> importing<BR>> ev_sec_level = new_sec_level.<BR>><BR>> if new_sec_level is initial.<BR>> new_sec_level = 4.<BR>> endif.<BR>> endif.<BR>> endif.<BR>><BR>>I have never used Events to recalculate agents for active tasks. In<BR>our<BR>>current production system, the security level is set to "Low -
workflow<BR>>is always restarted when changes are made". So, if the requestor makes<BR>>any changes to the workflow, it is restarted so agents are<BR>recalculated.<BR>>I will look into Events during our upgrade and will leverage off<BR>>Ginger's presentations.<BR>><BR>>Regards,<BR>>Natasha<BR>><BR>><BR>>-----Original Message-----<BR>>From: sap-wug-bounces@mit.edu [mailto:sap-wug-bounces@mit.edu] On<BR>Behalf<BR>>Of Susan R. Keohan<BR>>Sent: Tuesday, November 01, 2005 12:41 PM<BR>>To: SAP Workflow Users' Group<BR>>Subject: Re: SRM BAdi-n step for Shopping Carts<BR>><BR>>Hi Natasha,<BR>><BR>>Thanks so much for all the info. Our current process does not call<BR>for<BR>>ad-hoc approvers, but I am <BR>>still hoping to take advantage of this functionality.<BR>><BR>>Am I correct that the value in BBP_WFL_SECURITY (currently set to 'not<BR>>defined') would be the key to <BR>>allowing/prohibiting changes to S!
hopping
Carts, all using the same task<BR>>? Just re-stating in my own <BR>>words what I thought you said...<BR>><BR>>Have you used Events to cause the recalculation of agents for active<BR>>tasks ? This could solve a lot <BR>>of our problems, where the Shopping Cart changes during the approval<BR>>process, and the wrong <BR>>approvers still have the 'old' approval task...(Ginger Gatling<BR>delivered<BR>>a great presentation on <BR>>this topic at the recent TechEd in Boston).<BR>><BR>>Many thanks,<BR>>Sue<BR>><BR>>Baunach, Natasha R wrote:<BR>><BR>> <BR>><BR>>>Hi Sue,<BR>>><BR>>>I have implemented BBP_WFL_APPROV_BADI in our SRM 4.0 sandbox with<BR>>>different level of approvals and certain line items going to different<BR>>>approvers. Hopefully, I can answer some of your questions.<BR>>><BR>>>1. Yes, approval index must be incremented by 1. You can still have<BR>>>your ad-hoc appro!
val steps
between pre-defined approval steps assuming<BR>>>that you allow for ad-hoc approvers (you can disable this<BR>>> <BR>>><BR>>functionality<BR>> <BR>><BR>>>via BADI 'Allow Changes to Approvers' BBP_CHNG_AGNT_ALLOW.<BR>>><BR>>>2. It is the same task that is used for approvals in all shopping cart<BR>>>approval workflows available in SRM 4.0. The task is TS10008126.<BR>>>Whether or not an approver can change the cart during approval process<BR>>>is determined by the settings at the role level. Go to transaction<BR>>>PFCG, input your role, hit display. Then go to Personalization tab<BR>>> <BR>>><BR>>and<BR>> <BR>><BR>>>look for personalization object key 'BBP_WFL_SECURITY'. During<BR>>> <BR>>><BR>>runtime,<BR>> <BR>><BR>>>this default can be overwritten in the BADI 'Authorization to Change<BR>>>During Approval' BBP_WFL_SECUR_BADI. So basically, if your
approvers<BR>>> <BR>>><BR>>at<BR>> <BR>><BR>>>different levels have different roles, you should be able to control<BR>>>change ability via this setting at the role level. If it is more<BR>>>complicated than that, then you will need to place your more<BR>>> <BR>>><BR>>complicated<BR>> <BR>><BR>>>logic in the BADI. <BR>>><BR>>>BTW, I think that you can also use a different BADI to allow only<BR>>>certain fields to be changed. It could be applicable only to CUF's.<BR>>> <BR>>><BR>>I<BR>> <BR>><BR>>>have this requirement and will be looking into it shortly -- if a user<BR>>>has finance approver profile, only allow them to change GL account<BR>>>assignment and nothing else; no changes are allowed for other<BR>>> <BR>>><BR>>approver.<BR>> <BR>><BR>>>I hope this helps.
<BR>>><BR>>>Natasha<BR>>><BR>>><BR>>>-----Original Message-----<BR>>>From: sap-wug-bounces@MIT.EDU [mailto:sap-wug-bounces@MIT.EDU] On<BR>>> <BR>>><BR>>Behalf<BR>> <BR>><BR>>>Of Susan R. Keohan<BR>>>Sent: Tuesday, November 01, 2005 6:56 AM<BR>>>To: SAP Workflow Users' Group<BR>>>Subject: SRM BAdi-n step for Shopping Carts<BR>>><BR>>>Hi all,<BR>>><BR>>>I am trying to embark on the implementation of BBP_WFL_APPROV_BADI<BR>>> <BR>>><BR>>(SRM<BR>> <BR>><BR>>>4.0). Have looked at all <BR>>>the notes, docu, sample implementations, etc.<BR>>>1) The docu for this BAdi says 'Note that there must be absolutely no<BR>>>gaps in the approval steps and <BR>>>that approvers must be defined for every step.' I assume this means<BR>>>that the ApprovalIndex must be <BR>>>incremented from 0 by 1 with no gaps in it. Am I correct !
? Or
does<BR>>>this mean that there can be no <BR>>>intervening steps *between* approval steps ?<BR>>><BR>>>2) Is it possible to pass an approver an approval task, which also<BR>>>allows them to change the cart ? <BR>>> But other approvers (different approval levels) can only approve or<BR>>>reject? Can I determine <BR>>>which tasks the approvers can get and set that in the BAdi ?<BR>>><BR>>>Obviously, I am an SRM novice and a BAdi novice as well, so any help<BR>>> <BR>>><BR>>is<BR>> <BR>><BR>>>greatly appreciated.<BR>>>Happy WF-ing,<BR>>>Sue<BR>>> <BR>>><BR>><BR>> <BR>><BR>_______________________________________________<BR>SAP-WUG mailing list<BR>SAP-WUG@mit.edu<BR>http://mailman.mit.edu/mailman/listinfo/sap-wug<BR><BR>_______________________________________________<BR>SAP-WUG mailing
list<BR>SAP-WUG@mit.edu<BR>http://mailman.mit.edu/mailman/listinfo/sap-wug<BR></BLOCKQUOTE><p>
<hr size=1> <a href="http://us.lrd.yahoo.com/_ylc=X3oDMTFqODRtdXQ4BF9TAzMyOTc1MDIEX3MDOTY2ODgxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=110oav78o/**http%3a//farechase.yahoo.com/">Yahoo! FareChase - Search multiple travel sites in one click.</a>