SRM 4.0 Starting event for Shopping Cart
Stéphane Bailleul
bailleul_s at hotmail.com
Thu Nov 10 04:22:10 EST 2005
Hi all
I have set up a new attribute in the Shopping cart business object, when I
go in transaction SWO1 with my object ZBUS2121 and test it the new attribute
is calculated without any problem.
I have now added this attributes to my starting condition, and I can see in
the trace for the event that the attributes is not calculated
(Check FM SWB_2_CHECK_FB_START_COND_EVAL, Operator 'EQ': The value of the
left operand cannot be determined)
The error is happening in the form evaluate_rule from the function
SWB_COND_EVAL.
But I can not determine why and how to solve it
Best regards
Stephane
>From: sap-wug-request at mit.edu
>Reply-To: sap-wug at mit.edu
>To: sap-wug at mit.edu
>Subject: SAP-WUG Digest, Vol 12, Issue 35
>Date: Thu, 10 Nov 2005 01:17:44 -0500
>
>Send SAP-WUG mailing list submissions to
> sap-wug at mit.edu
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>or, via email, send a message with subject or body 'help' to
> sap-wug-request at mit.edu
>
>You can reach the person managing the list at
> sap-wug-owner at mit.edu
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of SAP-WUG digest..."
>
>
>Today's Topics:
>
> 1. RE: Help regd. rule resolutions (Dart, Jocelyn)
> 2. RE: SRM BAdi-n step for Shopping Carts (Dart, Jocelyn)
>
>
>----------------------------------------------------------------------
>
>Date: Thu, 10 Nov 2005 14:15:45 +0800
>From: "Dart, Jocelyn" <jocelyn.dart at sap.com>
>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>Subject: RE: Help regd. rule resolutions
>Message-ID:
><EFB207BF0F7FAA47A800709C57D0523D01C5CBE8 at sgsine10.sin.sap.corp>
>Content-Type: text/plain;
> charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 8bit
>Precedence: list
>Reply-To: SAP Workflow Users' Group <sap-wug at mit.edu>
>Message: 1
>
>Vijay,
>Same deal, because mail recipients can be in many formats, not just
>agent format, rules are not appropriate.
>
>You're correct that's not just email addresses, you could say exactly
>the same thing about SAP user ids - i.e. I can pass a list of user ids
>as the recipients of a mail step, whereas a work item rule always passes
>back agents in agent format (i.e. for work items a user id has to be
>passed as US.
>
>So you calculate them in a prior step as Mike has described, and then
>pass the list to your mail step using a multiline container element.
>
>
>Regards,
>Jocelyn Dart
>Senior Consultant
>SAP Australia Pty Ltd.
>Level 1/168 Walker St.
>North Sydney
>NSW, 2060
>Australia
>T +61 412 390 267
>M + 61 412 390 267
>E jocelyn.dart at sap.com
>http://www.sap.com
>
>The information contained in or attached to this electronic transmission
>is confidential and may be legally privileged. It is intended only for
>the person or entity to which it is addressed. If you are not the
>intended recipient, you are hereby notified that any distribution,
>copying, review, retransmission, dissemination or other use of this
>electronic transmission or the information contained in it is strictly
>prohibited. If you have received this electronic transmission in error,
>please immediately contact the sender to arrange for the return of the
>original documents.
>Electronic transmission cannot be guaranteed to be secure and
>accordingly, the sender does not accept liability for any such data
>corruption, interception, unauthorized amendment, viruses, delays or the
>consequences thereof.
>Any views expressed in this electronic transmission are those of the
>individual sender, except where the message states otherwise and the
>sender is authorized to state them to be the views of SAP AG or any of
>its subsidiaries. SAP AG, its subsidiaries, and their directors,
>officers and employees make no representation nor accept any liability
>for the accuracy or completeness of the views or information contained
>herein. Please be aware that the furnishing of any pricing information/
>business proposal herein is indicative only, is subject to change and
>shall not be construed as an offer or as constituting a binding
>agreement on the part of SAP AG or any of its subsidiaries to enter into
>any relationship, unless otherwise expressly stated.
>
>
>-----Original Message-----
>From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
>Of vijay srikanth
>Sent: Thursday, 10 November 2005 3:21 PM
>To: sap-wug at mit.edu
>Subject: RE: Help regd. rule resolutions
>
>Hi Mike,
>
>I didn't mean email addresses. I meant SAP mail, (Send Mail Step) to
>user
>ids. The mail that goes into the unread documents of the SBWP, for a
>particular user.
>
>
>Regards,
>Vijay
>
>
> >From: "Mike Pokraka (WUG)" <wug.replies at workflowconnections.com>
> >Reply-To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> >To: "'SAP Workflow Users' Group'" <sap-wug at mit.edu>
> >Subject: RE: Help regd. rule resolutions
> >Date: Wed, 9 Nov 2005 22:43:40 +0200
> >
> >Hi Vijay,
> >It doesn't make sense to be able to use rules for emails. Rules return
>org
> >objects, but email addresses are pretty much free text fields. i.e. it
> >could
> >be customers or any mail address you pick off an order or whatever.
> >If you want to use a rule for agents' email addresses, you have to
>evaluate
> >the agents in code (FM RH_GET_ACTORS) and then get the email addresses
>for
> >each and send that to your mail step as a multline container.
> >
> >Cheers
> >Mike
> >
> >-----Original Message-----
> >From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
>Behalf Of
> >vijay srikanth
> >Sent: 09 November 2005 11:51
> >To: sap-wug at mit.edu
> >Subject: Help regd. rule resolutions
> >
> >Hi,
> >
> >While sending work items to inboxes of agents we can set rules in the
> >workflow step itself.
> >How do we set rules when we send SAP mail to agents. There is no option
>in
> >the workflow step itself for doing the same. Thanks for the help in
> >advance.
> >
> >
> >Regards,
> >Vijay
> >
> >
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
> >
> >
> >_______________________________________________
> >SAP-WUG mailing list
> >SAP-WUG at mit.edu
> >http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>------------------------------
>
>Date: Thu, 10 Nov 2005 14:17:36 +0800
>From: "Dart, Jocelyn" <jocelyn.dart at sap.com>
>To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>Subject: RE: SRM BAdi-n step for Shopping Carts
>Message-ID:
><EFB207BF0F7FAA47A800709C57D0523D01C5CBEF at sgsine10.sin.sap.corp>
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_001_01C5E5BE.714BA55B"
>MIME-Version: 1.0
>Precedence: list
>Reply-To: SAP Workflow Users' Group <sap-wug at mit.edu>
>Message: 2
>
>This is a multi-part message in MIME format.
>
>------_=_NextPart_001_01C5E5BE.714BA55B
>Content-Type: text/plain;
> charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
>Hi rang nat,=20
>1. EBP 2.0 - centuries ago! (well a couple of years at least) and
>doesn't have a BADI workflow
>2. Did you have a question?
>=20
>
>Regards,=20
>Jocelyn Dart=20
>Senior Consultant=20
>SAP Australia Pty Ltd.=20
>Level 1/168 Walker St.=20
>North Sydney=20
>NSW, 2060=20
>Australia=20
>T +61 412 390 267=20
>M + 61 412 390 267=20
>E jocelyn.dart at sap.com=20
>http://www.sap.com <http://www.sap.com/> =20
>
>The information contained in or attached to this electronic transmission
>is confidential and may be legally privileged. It is intended only for
>the person or entity to which it is addressed. If you are not the
>intended recipient, you are hereby notified that any distribution,
>copying, review, retransmission, dissemination or other use of this
>electronic transmission or the information contained in it is strictly
>prohibited. If you have received this electronic transmission in error,
>please immediately contact the sender to arrange for the return of the
>original documents.=20
>
>Electronic transmission cannot be guaranteed to be secure and
>accordingly, the sender does not accept liability for any such data
>corruption, interception, unauthorized amendment, viruses, delays or the
>consequences thereof.
>
>Any views expressed in this electronic transmission are those of the
>individual sender, except where the message states otherwise and the
>sender is authorized to state them to be the views of SAP AG or any of
>its subsidiaries. SAP AG, its subsidiaries, and their directors,
>officers and employees make no representation nor accept any liability
>for the accuracy or completeness of the views or information contained
>herein. Please be aware that the furnishing of any pricing information/
>business proposal herein is indicative only, is subject to change and
>shall not be construed as an offer or as constituting a binding
>agreement on the part of SAP AG or any of its subsidiaries to enter into
>any relationship, unless otherwise expressly stated.=20
>
>=20
>
>________________________________
>
>From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
>Of rang nat
>Sent: Thursday, 10 November 2005 5:06 PM
>To: SAP Workflow Users' Group
>Subject: RE: SRM BAdi-n step for Shopping Carts
>
>
>Hi Jocelyn,
>=20
>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.
>=20
>Cheers
>=20
>=20
>
>
>"Dart, Jocelyn" <jocelyn.dart at sap.com> wrote:
>
> No really you're ok Sue - the standard whole shopping cart BADI
>approval
> workflow restarts as normal based on workflow security and what
>changes
> were made. You shouldn't have to raise any special events for
>approvers
> restarting based on rejection or change.=20
>=09
> The only event you may want to keep is your Profit Center event
>- the
> trick with that however is it won't be enough to re-evaluate
>rules on
> active work items - you also need to rerun the BADI to
>recalculate the
> approvers and fill the workflow container appropriately.
>Otherwise your
> new approvers may not be able to action the shopping cart
>correctly.=20
>=09
> You might have to create a parallel workflow as well as using
> re-evaluate rules.=20
>=09
>=09
> Regards,
> Jocelyn Dart
> Senior Consultant
> SAP Australia Pty Ltd.
> Level 1/168 Walker St.
> North Sydney=20
> NSW, 2060
> Australia
> T! +61 412 390 267
> M + 61 412 390 267
> E jocelyn.dart at sap.com
> http://www.sap.com
>=09
> The information contained in or attached to this electronic
>transmission
> is confidential and may be legally privileged. It is intended
>only for
> the person or entity to which it is addressed. If you are not
>the
> intended recipient, you are hereby notified that any
>distribution,
> copying, review, retransmission, dissemination or other use of
>this
> electronic transmission or the information contained in it is
>strictly
> prohibited. If you have received this electronic transmission in
>error,
> please immediately contact the sender to arrange for the return
>of the
> original documents.=20
> Electronic transmission cannot be guaranteed to be secure and
> accordingly, the sender does not accept liability for any such
>data
> corruption, interception, unauthorized amendment, viruses,
>delays or the
> consequences thereof.
> Any views expressed in this electronic transmission are tho! se
>of the
> individual sender, except where the message states otherwise and
>the
> sender is authorized to state them to be the views of SAP AG or
>any of
> its subsidiaries. SAP AG, its subsidiaries, and their directors,
> officers and employees make no representation nor accept any
>liability
> for the accuracy or completeness of the views or information
>contained
> herein. Please be aware that the furnishing of any pricing
>information/
> business proposal herein is indicative only, is subject to
>change and
> shall not be construed as an offer or as constituting a binding
> agreement on the part of SAP AG or any of its subsidiaries to
>enter into
> any relationship, unless otherwise expressly stated.=20
>=09
>=09
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]
>On Behalf
> Of Sue Keohan
> Sent: Wednesday, 02 November 2005 1:02 PM
> To: SAP Workflow Users' Group
> Subject: Re: SRM BAdi-n step for Shopping Carts
>=09
> Hi Jocelyn,
>=09
> I was thinking to raise custom events when master data on the
>R/3 side=20
> changes, for example, Profit Center, which usually means a
>re-org, and=20
> in that case, new approvers. The Events under the workflow
>header,=20
> version dependent tab, would seem to be able to do this
>'Reevaluate=20
> Rules of Active Workitems', but of course, seeing is believing.
>=09
> I am interested in whole Shopping Cart Approvals via the BAdi,
>not Item=20
> Approval. So, for that part at least, pheww! As for the BAdi, it
>may=20
> prove challenging, as our business process calls for certain
>approvers=20
> (at 'level 1') to be able to 'restart' approvals at the point
>where the=20
> last rejection occurred, or 'begin anew'. The BAdi would need to
>take=20
> this into consideration. Looks like I have my work cut out for
>me.
>=09
> Best regards,
> Sue
>=09
>=09
> Dart, Jocelyn wrote:
>=09
> >Hi Sue,=20
> >You don't need to raise any special events to restart when the
>user
> >chang! es it.=20
> >The standard code will work out what happens next and whether
>to remove
> >approval tasks from certain users based on what you send out in
>the
> >BADI.=20
> >So you just need to concentrate on getting your BADI code
>correct -
> i.e.
> >to say "who does it go to next".=20
> >
> >By the way, are you just looking at whole ShopCart BADI
>approval or the
> >ShopCart Item approval?
> >It's a lot more complicated for ShopCart Item approval but I've
>just
> >done it at a customer with a hideously
> >complex business scenario, so should be able to answer any
>questions.=20
> >
> >Regards,
> >Jocelyn Dart
> >Senior Consultant
> >SAP Australia Pty Ltd.
> >Level 1/168 Walker St.
> >North Sydney=20
> >NSW, 2060
> >Australia
> >T +61 412 390 267
> >M + 61 412 390 267
> >E jocelyn.dart at sap.com
> >http://www.sap.com
> >
> >The information contained in or attached to this electronic
> transmission
> >is confidential and may be legally privileged. It is intended
>only for
> >the person or entity to which it is addressed. If you are not
>the
> >intended recipient, you are hereby notified that any
>distribution,
> >copying, review, retransmission, dissemination or other use of
>this
> >electronic transmission or the information contained in it is
>strictly
> >prohibited. If you have received this electronic transmission
>in error,
> >please immediately contact the sender to arrange for the return
>of the
> >original documents.=20
> >Electronic transmission cannot be guaranteed to be secure and
> >accordingly, the sender does not accept liability for any such
>data
> >corruption, interception, unauthorized amendment, viruses,
>delays or
> the
> >consequences thereof.
> >Any views expressed in this electronic transmission are those
>of the
> >individual sender, except where the message states otherwis! e
>and the
> >sender is authorized to state them to be the views of SAP AG or
>any of
> >its subsidiaries. SAP AG, its subsidiaries, and their
>directors,
> >officers and employees make no representation nor accept any
>liability
> >for the accuracy or completeness of the views or information
>contained
> >herein. Please be aware that the furnishing of any pricing
>information/
> >business proposal herein is indicative only, is subject to
>change and
> >shall not be construed as an offer or as constituting a binding
> >agreement on the part of SAP AG or any of its subsidiaries to
>enter
> into
> >any relationship, unless otherwise expressly stated.=20
> >
> >
> >-----Original Message-----
> >From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]
>On
> Behalf
> >Of Baunach, Natasha R
> >Sent: Wednesday, 02 November 2005 8:01 AM
> >To: SAP Workflow Users' Group
> >Subject: RE: SRM BAdi-n step for Shopping Carts
> >
> >Sue,
> >
> >You are correct that the value in BBP_WFL_SECURITY is the key
>to
> >allowing/prohibiting changes to shopping carts during approvals
>(even
> >though they all use the same task). Please keep in mind that if
>the
> >value is set to 'not defined', SAP has added the code in the
>BADI
> >BBP_WFL_SECUR_BADI, implementation BBP_WFL_SECUR_BADI_S to
>change it to
> >4 (I think it comes in as activated) which is equivalent to no
>changes
> >are allowed.
> >
> > if scenario is initial .
> > call function 'BBP_PDH_WFL_SECLEVEL_DB_GET'
> > exporting
> > iv_user =3D actual_user
> > importing
> > ev_sec_level =3D new_sec_level.
> >
> > if new_sec_level is initial.
> > new_sec_level =3D 4.
> > endif.
> > endif.
> > endif.
> >
> >I have never used Events to recalculate agents for active
>tasks. In
> our
> >current production system, the security level is set to "Low -
>workflow
> >is always restarted when changes are made". So, if the
>requestor makes
> >any changes to the workflow, it is restarted so agents are
> recalculated.
> >I will look into Events during our upgrade and will leverage
>off
> >Ginger's presentations.
> >
> >Regards,
> >Natasha
> >
> >
> >-----Original Message-----
> >From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]
>On
> Behalf
> >Of Susan R. Keohan
> >Sent: Tuesday, November 01, 2005 12:41 PM
> >To: SAP Workflow Users' Group
> >Subject: Re: SRM BAdi-n step for Shopping Carts
> >
> >Hi Natasha,
> >
> >Thanks so much for all the info. Our current process does not
>call
> for
> >ad-hoc approvers, but I am=20
> >still hoping to take advantage of this functionality.
> >
> >Am I correct that the value in BBP_WFL_SECURITY (currently set
>to 'not
> >defined') would be the key to=20
> >allowing/prohibiting changes to S! hopping Carts, all using the
>same task
> >? Just re-stating in my own=20
> >words what I thought you said...
> >
> >Have you used Events to cause the recalculation of agents for
>active
> >tasks ? This could solve a lot=20
> >of our problems, where the Shopping Cart changes during the
>approval
> >process, and the wrong=20
> >approvers still have the 'old' approval task...(Ginger Gatling
> delivered
> >a great presentation on=20
> >this topic at the recent TechEd in Boston).
> >
> >Many thanks,
> >Sue
> >
> >Baunach, Natasha R wrote:
> >
> >=20
> >
> >>Hi Sue,
> >>
> >>I have implemented BBP_WFL_APPROV_BADI in our SRM 4.0 sandbox
>with
> >>different level of approvals and certain line items going to
>different
> >>approvers. Hopefully, I can answer some of your questions.
> >>
> >>1. Yes, approval index must be incremented by 1. You can still
>have
> >>your ad-hoc appro! val steps between pre-defined approval
>steps assuming
> >>that you allow for ad-hoc approvers (you can disable this
> >>=20
> >>
> >functionality
> >=20
> >
> >>via BADI 'Allow Changes to Approvers' BBP_CHNG_AGNT_ALLOW.
> >>
> >>2. It is the same task that is used for approvals in all
>shopping cart
> >>approval workflows available in SRM 4.0. The task is
>TS10008126.
> >>Whether or not an approver can change the cart during approval
>process
> >>is determined by the settings at the role level. Go to
>transaction
> >>PFCG, input your role, hit display. Then go to Personalization
>tab
> >>=20
> >>
> >and
> >=20
> >
> >>look for personalization object key 'BBP_WFL_SECURITY'. During
> >>=20
> >>
> >runtime,
> >=20
> >
> >>this default can be overwritten in the BADI 'Authorization to
>Change
> >>During Approval' BBP_WFL_SECUR_BADI. So basically, if your
>approvers
> >>=20
> >>
> >at
> >=20
> >
> >>different levels have different roles, you should be able to
>control
> >>change ability via this setting at the role level. If it is
>more
> >>complicated than that, then you will need to place your more
> >>=20
> >>
> >complicated
> >=20
> >
> >>logic in the BADI.=20
> >>
> >>BTW, I think that you can also use a different BADI to allow
>only
> >>certain fields to be changed. It could be applicable only to
>CUF's.
> >>=20
> >>
> >I
> >=20
> >
> >>have this requirement and will be looking into it shortly --
>if a user
> >>has finance approver profile, only allow them to change GL
>account
> >>assignment and nothing else; no changes are allowed for other
> >>=20
> >>
> >approver.
> >=20
> >
> >>I hope this helps.=20
> >>
> >>Natasha
> >>
> >>
> >>-----Original Message-----
> >>From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU]
>On
> >>=20
> >>
> >Behalf
> >=20
> >
> >>Of Susan R. Keohan
> >>Sent: Tuesday, November 01, 2005 6:56 AM
> >>To: SAP Workflow Users' Group
> >>Subject: SRM BAdi-n step for Shopping Carts
> >>
> >>Hi all,
> >>
> >>I am trying to embark on the implementation of
>BBP_WFL_APPROV_BADI
> >>=20
> >>
> >(SRM
> >=20
> >
> >>4.0). Have looked at all=20
> >>the notes, docu, sample implementations, etc.
> >>1) The docu for this BAdi says 'Note that there must be
>absolutely no
> >>gaps in the approval steps and=20
> >>that approvers must be defined for every step.' I assume this
>means
> >>that the ApprovalIndex must be=20
> >>incremented from 0 by 1 with no gaps in it. Am I correct ! ?
>Or does
> >>this mean that there can be no=20
> >>intervening steps *between* approval steps ?
> >>
> >>2) Is it possible to pass an approver an approval task, which
>also
> >>allows them to change the cart ?=20
> >> But other approvers (different approval levels) can only
>approve or
> >>reject? Can I determine=20
> >>which tasks the approvers can get and set that in the BAdi ?
> >>
> >>Obviously, I am an SRM novice and a BAdi novice as well, so
>any help
> >>=20
> >>
> >is
> >=20
> >
> >>greatly appreciated.
> >>Happy WF-ing,
> >>Sue
> >>=20
> >>
> >
> >=20
> >
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>=09
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>=09
>
>________________________________
>
>Yahoo! FareChase - Search multiple travel sites in one click.
><http://us.lrd.yahoo.com/_ylc=3DX3oDMTFqODRtdXQ4BF9TAzMyOTc1MDIEX3MDOTY2O=
>D
>gxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=3D110oav78o/**http%3a/=
>/
>farechase.yahoo.com/> =20
>
>------_=_NextPart_001_01C5E5BE.714BA55B
>Content-Type: text/html;
> charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML><HEAD>
><META http-equiv=3DContent-Type content=3D"text/html; =
>charset=3Dus-ascii">
><META content=3D"MSHTML 6.00.2800.1522" name=3DGENERATOR></HEAD>
><BODY>
><DIV dir=3Dltr align=3Dleft><SPAN class=3D656421606-10112005><FONT =
>face=3DArial=20
>color=3D#0000ff size=3D2>Hi rang nat, </FONT></SPAN></DIV>
><DIV dir=3Dltr align=3Dleft><SPAN class=3D656421606-10112005><FONT =
>face=3DArial=20
>color=3D#0000ff size=3D2>1. EBP 2.0 - centuries ago! (well a couple =
>of years at=20
>least) and doesn't have a BADI workflow</FONT></SPAN></DIV>
><DIV dir=3Dltr align=3Dleft><SPAN class=3D656421606-10112005><FONT =
>face=3DArial=20
>color=3D#0000ff size=3D2>2. Did you have a question?</FONT></SPAN></DIV>
><DIV> </DIV><!-- Converted from text/rtf format -->
><P><SPAN lang=3Den-us><FONT face=3DArial size=3D1>Regards,</FONT></SPAN> =
><BR><SPAN=20
>lang=3Den-us><B><FONT face=3DArial color=3D#000080 size=3D1>Jocelyn=20
>Dart</FONT></B></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
>color=3D#808080=20
>size=3D1>Senior Consultant</FONT></SPAN> <BR><SPAN lang=3Den-us><B><FONT =
>face=3DArial=20
>color=3D#808080 size=3D1>SAP Australia Pty Ltd.</FONT></B></SPAN> =
><BR><SPAN=20
>lang=3Den-us><FONT face=3DArial color=3D#808080 size=3D1>Level 1/168 =
>Walker=20
>St.</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
>color=3D#808080=20
>size=3D1>North Sydney </FONT></SPAN><BR><SPAN lang=3Den-us><FONT =
>face=3DArial=20
>color=3D#808080 size=3D1>NSW, 2060</FONT></SPAN> <BR><SPAN =
>lang=3Den-us><FONT=20
>face=3DArial color=3D#808080 size=3D1>Australia</FONT></SPAN> <BR><SPAN=20
>lang=3Den-us><FONT face=3DArial color=3D#808080 size=3D1>T =
>+61 412 390=20
>267</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
>color=3D#808080=20
>size=3D1>M + 61 412 390 267</FONT></SPAN> <BR><SPAN =
>lang=3Den-us><FONT=20
>face=3DArial color=3D#808080 size=3D1>E =
>jocelyn.dart at sap.com</FONT></SPAN>=20
><BR><SPAN lang=3Den-us><FONT face=3DArial color=3D#808080 size=3D1><A=20
>href=3D"http://www.sap.com/">http://www.sap.com</A></FONT></SPAN> </P>
><P><SPAN lang=3Den-au><FONT face=3D"Times New Roman" color=3D#ff0000 =
>size=3D1>The=20
>information contained in or attached to this electronic transmission is=20
>confidential and may be legally privileged. It is intended only for the =
>person=20
>or entity to which it is addressed. If you are not the intended =
>recipient, you=20
>are hereby notified that any distribution, copying, review, =
>retransmission,=20
>dissemination or other use of this electronic transmission or the =
>information=20
>contained in it is strictly prohibited. If you have received this =
>electronic=20
>transmission in error, please immediately contact the sender to arrange =
>for the=20
>return of the original documents. </FONT></SPAN></P>
><P><SPAN lang=3Den-au><FONT face=3D"Times New Roman" color=3D#ff0000 =
>size=3D1>Electronic=20
>transmission cannot be guaranteed to be secure and accordingly, the =
>sender does=20
>not accept liability for any such data corruption, interception, =
>unauthorized=20
>amendment, viruses, delays or the consequences =
>thereof.</FONT></SPAN></P>
><P><SPAN lang=3Den-au><FONT face=3D"Times New Roman" color=3D#ff0000 =
>size=3D1>Any views=20
>expressed in this electronic transmission are those of the individual =
>sender,=20
>except where the message states otherwise and the sender is authorized =
>to state=20
>them to be the views of SAP AG or any of its subsidiaries. SAP AG, its=20
>subsidiaries, and their directors, officers and employees make no =
>representation=20
>nor accept any liability for the accuracy or completeness of the views =
>or=20
>information contained herein. Please be aware that the furnishing of any =
>pricing=20
>information/ business proposal herein is indicative only, is subject to =
>change=20
>and shall not be construed as an offer or as constituting a binding =
>agreement on=20
>the part of SAP AG or any of its subsidiaries to enter into any =
>relationship,=20
>unless otherwise expressly stated. </FONT></SPAN></P>
><DIV> </DIV><BR>
><DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
><HR tabIndex=3D-1>
><FONT face=3DTahoma size=3D2><B>From:</B> sap-wug-bounces at mit.edu=20
>[mailto:sap-wug-bounces at mit.edu] <B>On Behalf Of </B>rang =
>nat<BR><B>Sent:</B>=20
>Thursday, 10 November 2005 5:06 PM<BR><B>To:</B> SAP Workflow Users'=20
>Group<BR><B>Subject:</B> RE: SRM BAdi-n step for Shopping=20
>Carts<BR></FONT><BR></DIV>
><DIV></DIV>
><DIV>Hi Jocelyn,</DIV>
><DIV> </DIV>
><DIV>I can see that approval workflow restart when we change A/c =
>assignment=20
>details or product category....This is happening as new shopping =
>cart(new=20
>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 at sap.com></I></B>=20
>wrote:</DIV>
><BLOCKQUOTE class=3Dreplbq=20
>style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px =
>solid">No=20
> really you're ok Sue - the standard whole shopping cart BADI=20
> approval<BR>workflow restarts as normal based on workflow security and =
>what=20
> changes<BR>were made. You shouldn't have to raise any special events =
>for=20
> approvers<BR>restarting based on rejection or change. <BR><BR>The only =
>event=20
> you may want to keep is your Profit Center event - the<BR>trick with =
>that=20
> however is it won't be enough to re-evaluate rules on<BR>active work =
>items -=20
> you also need to rerun the BADI to recalculate the<BR>approvers and =
>fill the=20
> workflow container appropriately. Otherwise your<BR>new approvers may =
>not be=20
> able to action the shopping cart correctly. <BR><BR>You might have to =
>create a=20
> parallel workflow as well as using<BR>re-evaluate rules.=20
> <BR><BR><BR>Regards,<BR>Jocelyn Dart<BR>Senior Consultant<BR>SAP =
>Australia Pty=20
> Ltd.<BR>Level 1/168 Walker St.<BR>North Sydney <BR>NSW,=20
> 2060<BR>Australia<BR>T! +61 412 390 267<BR>M + 61 412 390 267<BR>E=20
> jocelyn.dart at sap.com<BR>http://www.sap.com<BR><BR>The information =
>contained in=20
> or attached to this electronic transmission<BR>is confidential and may =
>be=20
> legally privileged. It is intended only for<BR>the person or entity to =
>which=20
> it is addressed. If you are not the<BR>intended recipient, you are =
>hereby=20
> notified that any distribution,<BR>copying, review, retransmission,=20
> dissemination or other use of this<BR>electronic transmission or the=20
> information contained in it is strictly<BR>prohibited. If you have =
>received=20
> this electronic transmission in error,<BR>please immediately contact =
>the=20
> sender to arrange for the return of the<BR>original documents. =
><BR>Electronic=20
> transmission cannot be guaranteed to be secure and<BR>accordingly, the =
>sender=20
> does not accept liability for any such data<BR>corruption, =
>interception,=20
> unauthorized amendment, viruses, delays or the<BR>consequences =
>thereof.<BR>Any=20
> views expressed in this electronic transmission are tho! se of=20
> the<BR>individual sender, except where the message states otherwise =
>and=20
> the<BR>sender is authorized to state them to be the views of SAP AG or =
>any=20
> of<BR>its subsidiaries. SAP AG, its subsidiaries, and their=20
> directors,<BR>officers and employees make no representation nor accept =
>any=20
> liability<BR>for the accuracy or completeness of the views or =
>information=20
> contained<BR>herein. Please be aware that the furnishing of any =
>pricing=20
> information/<BR>business proposal herein is indicative only, is =
>subject to=20
> change and<BR>shall not be construed as an offer or as constituting a=20
> binding<BR>agreement on the part of SAP AG or any of its subsidiaries =
>to enter=20
> into<BR>any relationship, unless otherwise expressly stated.=20
> <BR><BR><BR>-----Original Message-----<BR>From: =
>sap-wug-bounces at mit.edu=20
> [mailto:sap-wug-bounces at mit.edu] On Behalf<BR>Of Sue Keohan<BR>Sent:=20
> Wednesday, 02 November 2005 1:02 PM<BR>To: SAP Workflow Users'=20
> Group<BR>Subject: Re: SRM BAdi-n step for Shopping Carts<BR><BR>Hi=20
> Jocelyn,<BR><BR>I was thinking to raise custom events when master data =
>on the=20
> R/3 side <BR>changes, for example, Profit Center, which usually means =
>a=20
> re-org, and <BR>in that case, new approvers. The Events under the =
>workflow=20
> header, <BR>version dependent tab, would seem to be able to do this=20
> 'Reevaluate <BR>Rules of Active Workitems', but of course, seeing is=20
> believing.<BR><BR>I am interested in whole Shopping Cart Approvals via =
>the=20
> BAdi, not Item <BR>Approval. So, for that part at least, pheww! As for =
>the=20
> BAdi, it may <BR>prove challenging, as our business process calls for =
>certain=20
> approvers <BR>(at 'level 1') to be able to 'restart' approvals at the =
>point=20
> where the <BR>last rejection occurred, or 'begin anew'. The BAdi would =
>need to=20
> take <BR>this into consideration. Looks like I have my work cut out =
>for=20
> me.<BR><BR>Best regards,<BR>Sue<BR><BR><BR>Dart, Jocelyn =
>wrote:<BR><BR>>Hi=20
> Sue, <BR>>You don't need to raise any special events to restart =
>when the=20
> user<BR>>chang! es it. <BR>>The standard code will work out what =
>happens=20
> next and whether to remove<BR>>approval tasks from certain users =
>based on=20
> what you send out in the<BR>>BADI. <BR>>So you just need to =
>concentrate=20
> on getting your BADI code correct -<BR>i.e.<BR>>to say "who does it =
>go to=20
> next". <BR>><BR>>By the way, are you just looking at whole =
>ShopCart BADI=20
> approval or the<BR>>ShopCart Item approval?<BR>>It's a lot more=20
> complicated for ShopCart Item approval but I've just<BR>>done it at =
>a=20
> customer with a hideously<BR>>complex business scenario, so should =
>be able=20
> to answer any questions. <BR>><BR>>Regards,<BR>>Jocelyn=20
> Dart<BR>>Senior Consultant<BR>>SAP Australia Pty =
>Ltd.<BR>>Level 1/168=20
> Walker St.<BR>>North Sydney <BR>>NSW, =
>2060<BR>>Australia<BR>>T +61=20
> 412 390 267<BR>>M + 61 412 390 267<BR>>E=20
> jocelyn.dart at sap.com<BR>>http://www.sap.com<BR>><BR>>The =
>information=20
> contained in or attached to this electronic<BR>transmission<BR>>is=20
> confidential and may be legally privileged. It is intended only =
>for<BR>>the=20
> person or entity to which it is addressed. If you are not =
>the<BR>>intended=20
> recipient, you are hereby notified that any =
>distribution,<BR>>copying,=20
> review, retransmission, dissemination or other use of =
>this<BR>>electronic=20
> transmission or the information contained in it is =
>strictly<BR>>prohibited.=20
> If you have received this electronic transmission in =
>error,<BR>>please=20
> immediately contact the sender to arrange for the return of=20
> the<BR>>original documents. <BR>>Electronic transmission cannot =
>be=20
> guaranteed to be secure and<BR>>accordingly, the sender does not =
>accept=20
> liability for any such data<BR>>corruption, interception, =
>unauthorized=20
> amendment, viruses, delays or<BR>the<BR>>consequences =
>thereof.<BR>>Any=20
> views expressed in this electronic transmission are those of=20
> the<BR>>individual sender, except where the message states =
>otherwis! e and=20
> the<BR>>sender is authorized to state them to be the views of SAP =
>AG or any=20
> of<BR>>its subsidiaries. SAP AG, its subsidiaries, and their=20
> directors,<BR>>officers and employees make no representation nor =
>accept any=20
> liability<BR>>for the accuracy or completeness of the views or =
>information=20
> contained<BR>>herein. Please be aware that the furnishing of any =
>pricing=20
> information/<BR>>business proposal herein is indicative only, is =
>subject to=20
> change and<BR>>shall not be construed as an offer or as =
>constituting a=20
> binding<BR>>agreement on the part of SAP AG or any of its =
>subsidiaries to=20
> enter<BR>into<BR>>any relationship, unless otherwise expressly =
>stated.=20
> <BR>><BR>><BR>>-----Original Message-----<BR>>From:=20
> sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]=20
> On<BR>Behalf<BR>>Of Baunach, Natasha R<BR>>Sent: Wednesday, 02 =
>November=20
> 2005 8:01 AM<BR>>To: SAP Workflow Users' Group<BR>>Subject: RE: =
>SRM=20
> BAdi-n step for Shopping Carts<BR>><BR>>Sue,<BR>><BR>>You =
>are=20
> correct that the value in BBP_WFL_SECURITY is the key=20
> to<BR>>allowing/prohibiting changes to shopping carts during =
>approvals=20
> (even<BR>>though they all use the same task). Please keep in mind =
>that if=20
> the<BR>>value is set to 'not defined', SAP has added the code in =
>the=20
> BADI<BR>>BBP_WFL_SECUR_BADI, implementation BBP_WFL_SECUR_BADI_S to =
>change=20
> it to<BR>>4 (I think it comes in as activated) which is equivalent =
>to no=20
> changes<BR>>are allowed.<BR>><BR>> if scenario is initial =
>.<BR>>=20
> call function 'BBP_PDH_WFL_SECLEVEL_DB_GET'<BR>> exporting<BR>> =
>iv_user=20
> =3D actual_user<BR>> importing<BR>> ev_sec_level =3D=20
> new_sec_level.<BR>><BR>> if new_sec_level is initial.<BR>>=20
> new_sec_level =3D 4.<BR>> endif.<BR>> endif.<BR>>=20
> endif.<BR>><BR>>I have never used Events to recalculate agents =
>for=20
> active tasks. In<BR>our<BR>>current production system, the security =
>level=20
> is set to "Low - workflow<BR>>is always restarted when changes are =
>made".=20
> So, if the requestor makes<BR>>any changes to the workflow, it is =
>restarted=20
> so agents are<BR>recalculated.<BR>>I will look into Events during =
>our=20
> upgrade and will leverage off<BR>>Ginger's=20
> =
>presentations.<BR>><BR>>Regards,<BR>>Natasha<BR>><BR>><BR>=
>>-----Original=20
> Message-----<BR>>From: sap-wug-bounces at mit.edu=20
> [mailto:sap-wug-bounces at mit.edu] On<BR>Behalf<BR>>Of Susan R.=20
> 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=20
> info. Our current process does not call<BR>for<BR>>ad-hoc =
>approvers, but I=20
> am <BR>>still hoping to take advantage of this=20
> functionality.<BR>><BR>>Am I correct that the value in =
>BBP_WFL_SECURITY=20
> (currently set to 'not<BR>>defined') would be the key to=20
> <BR>>allowing/prohibiting changes to S! hopping Carts, all using =
>the same=20
> task<BR>>? Just re-stating in my own <BR>>words what I thought =
>you=20
> said...<BR>><BR>>Have you used Events to cause the recalculation =
>of=20
> agents for active<BR>>tasks ? This could solve a lot <BR>>of our =
>
> problems, where the Shopping Cart changes during the =
>approval<BR>>process,=20
> and the wrong <BR>>approvers still have the 'old' approval =
>task...(Ginger=20
> Gatling<BR>delivered<BR>>a great presentation on <BR>>this topic =
>at the=20
> recent TechEd in Boston).<BR>><BR>>Many=20
> thanks,<BR>>Sue<BR>><BR>>Baunach, Natasha R =
>wrote:<BR>><BR>>=20
> <BR>><BR>>>Hi Sue,<BR>>><BR>>>I have implemented=20
> BBP_WFL_APPROV_BADI in our SRM 4.0 sandbox with<BR>>>different =
>level of=20
> approvals and certain line items going to =
>different<BR>>>approvers.=20
> Hopefully, I can answer some of your =
>questions.<BR>>><BR>>>1. Yes,=20
> approval index must be incremented by 1. You can still =
>have<BR>>>your=20
> ad-hoc appro! val steps between pre-defined approval steps=20
> assuming<BR>>>that you allow for ad-hoc approvers (you can =
>disable=20
> this<BR>>> <BR>>><BR>>functionality<BR>>=20
> <BR>><BR>>>via BADI 'Allow Changes to Approvers'=20
> BBP_CHNG_AGNT_ALLOW.<BR>>><BR>>>2. It is the same task =
>that is=20
> used for approvals in all shopping cart<BR>>>approval workflows=20
> available in SRM 4.0. The task is TS10008126.<BR>>>Whether or =
>not an=20
> approver can change the cart during approval process<BR>>>is =
>determined=20
> by the settings at the role level. Go to transaction<BR>>>PFCG, =
>input=20
> your role, hit display. Then go to Personalization tab<BR>>>=20
> <BR>>><BR>>and<BR>> <BR>><BR>>>look for =
>personalization=20
> object key 'BBP_WFL_SECURITY'. During<BR>>>=20
> <BR>>><BR>>runtime,<BR>> <BR>><BR>>>this default =
>can be=20
> overwritten in the BADI 'Authorization to Change<BR>>>During =
>Approval'=20
> BBP_WFL_SECUR_BADI. So basically, if your approvers<BR>>>=20
> <BR>>><BR>>at<BR>> <BR>><BR>>>different levels =
>have=20
> different roles, you should be able to control<BR>>>change =
>ability via=20
> this setting at the role level. If it is more<BR>>>complicated =
>than=20
> that, then you will need to place your more<BR>>>=20
> <BR>>><BR>>complicated<BR>> <BR>><BR>>>logic in =
>the BADI.=20
> <BR>>><BR>>>BTW, I think that you can also use a different =
>BADI to=20
> allow only<BR>>>certain fields to be changed. It could be =
>applicable=20
> only to CUF's.<BR>>> <BR>>><BR>>I<BR>>=20
> <BR>><BR>>>have this requirement and will be looking into it =
>shortly=20
> -- if a user<BR>>>has finance approver profile, only allow them =
>to=20
> change GL account<BR>>>assignment and nothing else; no changes =
>are=20
> allowed for other<BR>>> <BR>>><BR>>approver.<BR>>=20
> <BR>><BR>>>I hope this helps.=20
> =
><BR>>><BR>>>Natasha<BR>>><BR>>><BR>>>-----O=
>riginal=20
> Message-----<BR>>>From: sap-wug-bounces at MIT.EDU=20
> [mailto:sap-wug-bounces at MIT.EDU] On<BR>>>=20
> <BR>>><BR>>Behalf<BR>> <BR>><BR>>>Of Susan R.=20
> Keohan<BR>>>Sent: Tuesday, November 01, 2005 6:56 =
>AM<BR>>>To: SAP=20
> Workflow Users' Group<BR>>>Subject: SRM BAdi-n step for Shopping =
>
> Carts<BR>>><BR>>>Hi all,<BR>>><BR>>>I am =
>trying to=20
> embark on the implementation of BBP_WFL_APPROV_BADI<BR>>>=20
> <BR>>><BR>>(SRM<BR>> <BR>><BR>>>4.0). Have looked =
>at all=20
> <BR>>>the notes, docu, sample implementations, =
>etc.<BR>>>1) The=20
> docu for this BAdi says 'Note that there must be absolutely =
>no<BR>>>gaps=20
> in the approval steps and <BR>>>that approvers must be defined =
>for every=20
> step.' I assume this means<BR>>>that the ApprovalIndex must be=20
> <BR>>>incremented from 0 by 1 with no gaps in it. Am I correct ! =
>? Or=20
> does<BR>>>this mean that there can be no <BR>>>intervening =
>steps=20
> *between* approval steps ?<BR>>><BR>>>2) Is it possible to =
>pass an=20
> approver an approval task, which also<BR>>>allows them to change =
>the=20
> cart ? <BR>>> But other approvers (different approval levels) =
>can only=20
> approve or<BR>>>reject? Can I determine <BR>>>which tasks =
>the=20
> approvers can get and set that in the BAdi =
>?<BR>>><BR>>>Obviously,=20
> I am an SRM novice and a BAdi novice as well, so any help<BR>>>=20
> <BR>>><BR>>is<BR>> <BR>><BR>>>greatly=20
> appreciated.<BR>>>Happy WF-ing,<BR>>>Sue<BR>>>=20
> <BR>>><BR>><BR>>=20
> <BR>><BR>_______________________________________________<BR>SAP-WUG =
>mailing=20
> =
>list<BR>SAP-WUG at mit.edu<BR>http://mailman.mit.edu/mailman/listinfo/sap-wu=
>g<BR><BR>_______________________________________________<BR>SAP-WUG=20
> mailing=20
> =
>list<BR>SAP-WUG at mit.edu<BR>http://mailman.mit.edu/mailman/listinfo/sap-wu=
>g<BR></BLOCKQUOTE>
><P>
><HR SIZE=3D1>
><A=20
>href=3D"http://us.lrd.yahoo.com/_ylc=3DX3oDMTFqODRtdXQ4BF9TAzMyOTc1MDIEX3=
>MDOTY2ODgxNjkEcG9zAzEEc2VjA21haWwtZm9vdGVyBHNsawNmYw--/SIG=3D110oav78o/**=
>http%3a//farechase.yahoo.com/">Yahoo!=20
>FareChase - Search multiple travel sites in one click.</A> =
></BODY></HTML>
>
>------_=_NextPart_001_01C5E5BE.714BA55B--
>------------------------------
>
>_______________________________________________
>SAP-WUG mailing list
>SAP-WUG at mit.edu
>http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>End of SAP-WUG Digest, Vol 12, Issue 35
>***************************************
More information about the SAP-WUG
mailing list