Link in exchange to the workitem in sap worklace
Kobi Levi
kobil at sonol.co.il
Wed Nov 2 09:13:55 EST 2005
hi Kjetil Kilhavn,
The program u mentioned -RSWUWFML2 provide u to sent shortcut to the sap workplace and if u have single sighn on u don’t have to enter pas and user (logon details).
My wuestion is how to customize it
Thanks
koby
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of sap-wug-request at mit.edu
Sent: Wednesday, November 02, 2005 2:27 PM
To: sap-wug at mit.edu
Subject: SAP-WUG Digest, Vol 12, Issue 6
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: Link in exchange to the workitem in sap worklace
(Kjetil Kilhavn)
----------------------------------------------------------------------
Date: Wed, 2 Nov 2005 13:25:25 +0100
From: "Kjetil Kilhavn" <KJETILK at statoil.com>
To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
Subject: RE: Link in exchange to the workitem in sap worklace
Message-ID: <273AA3C12CC7C54DA3C0C33F3857FE5C59C01A at ST-EXCL03.statoil.net>
Content-Type: text/plain;
charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: list
Reply-To: SAP Workflow Users' Group <sap-wug at mit.edu>
Message: 1
If it has to be a link I can't help you. We use the .SAP attachment from RSWUWFML2 and it works but (in our case) required modification (read enhancement :-) of RSWUWFML2.
What exactly is your problem, and how does your single sign-on work?
--
Kjetil Kilhavn, Statoil ״FT KTJ ITS BKS SAP Basis ״FT (Konsernרkonomi, -finans og -tjenester) KTJ (Konserntjenester) ITS (IT-tjenester) BKS (BRA kompetansesenter) SAP (Systeme, Anwendungen und Produkte)
> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Kobi Levi
> Sent: 2. november 2005 10:07
> To: sap-wug at mit.edu
> Subject: Link in exchange to the workitem in sap worklace
>
> Hi all,
>
> How can I make a link in the url text (se38-RSWUWFML-standard text for
> notification)to work item in the sap business workplace .
> I need that the user who get the message in the exchanfe will have
> single sighn on to the work item in sap business workplace.
> Thanks
> Koby levy
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of sap-wug-request at mit.edu
> Sent: Wednesday, November 02, 2005 4:04 AM
> To: sap-wug at mit.edu
> Subject: SAP-WUG Digest, Vol 12, Issue 3
>
> 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: SRM BAdi-n step for Shopping Carts (Baunach, Natasha R)
> 2. RE: SRM BAdi-n step for Shopping Carts (Dart, Jocelyn)
> 3. Re: SRM BAdi-n step for Shopping Carts (Sue Keohan)
>
>
> ----------------------------------------------------------------------
>
> Date: Tue, 1 Nov 2005 16:24:11 -0800
> From: "Baunach, Natasha R" <natasha.r.baunach at intel.com>
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Subject: RE: SRM BAdi-n step for Shopping Carts
> Message-ID:
> <31F5998A44B92447BD334F8FBBA0B01F0A7B625F at orsmsx401.amr.corp.i
> ntel.com>
> 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
>
> Jocelyn,
>
> I am implementing line items based approval at Intel. So far things
> seem to be working OK but our test cycle just started.
> If you don't mind, I might have questions for you in the near future.
> You're right
> -- it isn't pretty.
>
> Natasha
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Dart, Jocelyn
> Sent: Tuesday, November 01, 2005 3:16 PM
> To: SAP Workflow Users' Group
> Subject: RE: SRM BAdi-n step for Shopping Carts
>
> Hi Sue,
> You don't need to raise any special events to restart when the user
> changes it.
> 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.
> So you just need to concentrate on getting your BADI code correct -
> i.e.
> to say "who does it go to next".
>
> 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.
>
> 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 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 = actual_user
> importing
> ev_sec_level = new_sec_level.
>
> if new_sec_level is initial.
> new_sec_level = 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
> 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
> allowing/prohibiting changes to Shopping Carts, all using the same
> task ? Just re-stating in my own words what I thought you said...
>
> Have you used Events to cause the recalculation of agents for active
> tasks ? This could solve a lot of our problems, where the Shopping
> Cart changes during the approval process, and the wrong approvers
> still have the 'old' approval task...(Ginger Gatling delivered a great
> presentation on this topic at the recent TechEd in Boston).
>
> Many thanks,
> Sue
>
> Baunach, Natasha R wrote:
>
> > 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 approval steps between pre-defined approval
> steps assuming
>
> > that you allow for ad-hoc approvers (you can disable this
> functionality
> > 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
> and
> > look for personalization object key 'BBP_WFL_SECURITY'. During
> runtime,
> > this default can be overwritten in the BADI 'Authorization
> to Change
> > During Approval' BBP_WFL_SECUR_BADI. So basically, if your
> approvers
> at
> > 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
> complicated
> > logic in the BADI.
> >
> > 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.
> I
> > 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
> approver.
> >
> > I hope this helps.
> >
> > 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 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
> (SRM
> > 4.0). Have looked at all
> > 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 that approvers must be defined for
> > every step.' I assume this means that the ApprovalIndex must be
> > incremented from 0 by 1 with no gaps in it. Am I correct ?
> Or does
> > this mean that there can be no intervening steps *between* approval
> > steps ?
> >
> > 2) Is it possible to pass an approver an approval task, which also
> > allows them to change the cart ?
> > But other approvers (different approval levels) can only
> approve or
>
> > reject? Can I determine 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
> is
> > greatly appreciated.
> > Happy WF-ing,
> > Sue
>
> --
> Susan R. Keohan
> SAP Workflow Developer
> MIT Lincoln Laboratory
> 244 Wood Street
> LI-200
> Lexington, MA. 02420
> 781-981-3561
> keohan at ll.mit.edu
> _______________________________________________
> 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: Wed, 2 Nov 2005 08:54:48 +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:
> <EFB207BF0F7FAA47A800709C57D0523D01B9848B 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: 2
>
> That's fine - just ask it via the WUG as usual.
>
> Key thing seems to be:
> * The approval object guid must be unique for each combination of
> approval index/group of items to be approved together
>
> * If its the same approval index/group of items to be approved, make
> absolutelyl sure you send out the same approval object guid each time
> or you can trigger unexpected restarts
>
> * Calculate future approvals - ignore the past - the standard code
> will take care of adding in past approvers (assuming you have all
> notes)
>
> * Only a history of "approved" results is kept - i.e. you can only see
> who rejected items on the current approval index level
>
> * As you cannot see in the approval previews what triggered a
> reapproval, encourage the users to use "Display Changes" to see why
> reapprovals were necessary
>
>
> 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 Baunach, Natasha R
> Sent: Wednesday, 02 November 2005 11:24 AM
> To: SAP Workflow Users' Group
> Subject: RE: SRM BAdi-n step for Shopping Carts
>
> Jocelyn,
>
> I am implementing line items based approval at Intel. So far things
> seem to be working OK but our test cycle just started.
> If you don't mind, I might have questions for you in the near future.
> You're right
> -- it isn't pretty.
>
> Natasha
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu
> [mailto:sap-wug-bounces at mit.edu] On Behalf Of Dart, Jocelyn
> Sent: Tuesday, November 01, 2005 3:16 PM
> To: SAP Workflow Users' Group
> Subject: RE: SRM BAdi-n step for Shopping Carts
>
> Hi Sue,
> You don't need to raise any special events to restart when the user
> changes it.
> 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.
> So you just need to concentrate on getting your BADI code correct -
> i.e.
> to say "who does it go to next".
>
> 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.
>
> 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 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 = actual_user
> importing
> ev_sec_level = new_sec_level.
>
> if new_sec_level is initial.
> new_sec_level = 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
> 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
> allowing/prohibiting changes to Shopping Carts, all using the same
> task ? Just re-stating in my own words what I thought you said...
>
> Have you used Events to cause the recalculation of agents for active
> tasks ? This could solve a lot of our problems, where the Shopping
> Cart changes during the approval process, and the wrong approvers
> still have the 'old' approval task...(Ginger Gatling delivered a great
> presentation on this topic at the recent TechEd in Boston).
>
> Many thanks,
> Sue
>
> Baunach, Natasha R wrote:
>
> > 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 approval steps between pre-defined approval
> steps assuming
>
> > that you allow for ad-hoc approvers (you can disable this
> functionality
> > 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
> and
> > look for personalization object key 'BBP_WFL_SECURITY'. During
> runtime,
> > this default can be overwritten in the BADI 'Authorization
> to Change
> > During Approval' BBP_WFL_SECUR_BADI. So basically, if your
> approvers
> at
> > 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
> complicated
> > logic in the BADI.
> >
> > 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.
> I
> > 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
> approver.
> >
> > I hope this helps.
> >
> > 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 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
> (SRM
> > 4.0). Have looked at all
> > 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 that approvers must be defined for
> > every step.' I assume this means that the ApprovalIndex must be
> > incremented from 0 by 1 with no gaps in it. Am I correct ?
> Or does
> > this mean that there can be no intervening steps *between* approval
> > steps ?
> >
> > 2) Is it possible to pass an approver an approval task, which also
> > allows them to change the cart ?
> > But other approvers (different approval levels) can only
> approve or
>
> > reject? Can I determine 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
> is
> > greatly appreciated.
> > Happy WF-ing,
> > Sue
>
> --
> Susan R. Keohan
> SAP Workflow Developer
> MIT Lincoln Laboratory
> 244 Wood Street
> LI-200
> Lexington, MA. 02420
> 781-981-3561
> keohan at ll.mit.edu
> _______________________________________________
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
> ------------------------------
>
> Date: Tue, 01 Nov 2005 21:02:21 -0500
> From: Sue Keohan <keohan at ll.mit.edu>
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Subject: Re: SRM BAdi-n step for Shopping Carts
> Message-ID: <43681E2D.5030502 at ll.mit.edu>
> In-Reply-To:
> <EFB207BF0F7FAA47A800709C57D0523D01B98400 at sgsine10.sin.sap.corp>
> References:
> <EFB207BF0F7FAA47A800709C57D0523D01B98400 at sgsine10.sin.sap.corp>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Precedence: list
> Reply-To: SAP Workflow Users' Group <sap-wug at mit.edu>
> Message: 3
>
> Hi Jocelyn,
>
> I was thinking to raise custom events when master data on the
> R/3 side changes, for example, Profit Center, which usually means a
> re-org, and
> in that case, new approvers. The Events under the workflow header,
> version dependent tab, would seem to be able to do this 'Reevaluate
> Rules of Active Workitems', but of course, seeing is believing.
>
> I am interested in whole Shopping Cart Approvals via the BAdi, not
> Item Approval. So, for that part at least, pheww!
> As for the BAdi, it may prove challenging, as our business process
> calls for certain approvers (at 'level 1') to be able to 'restart'
> approvals at the point where the last rejection occurred, or 'begin
> anew'. The BAdi would need to take this into consideration. Looks
> like I have my work cut out for me.
>
> Best regards,
> Sue
>
>
> Dart, Jocelyn wrote:
>
> >Hi Sue,
> >You don't need to raise any special events to restart when the user
> >changes it.
> >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.
> >So you just need to concentrate on getting your BADI code correct -
> i.e.
> >to say "who does it go to next".
> >
> >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.
> >
> >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 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 = actual_user
> > importing
> > ev_sec_level = new_sec_level.
> >
> > if new_sec_level is initial.
> > new_sec_level = 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
> >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
> >allowing/prohibiting changes to Shopping Carts, all using
> the same task
>
> >? Just re-stating in my own words what I thought you said...
> >
> >Have you used Events to cause the recalculation of agents for active
> >tasks ? This could solve a lot of our problems, where the
> Shopping Cart
>
> >changes during the approval process, and the wrong approvers
> still have
>
> >the 'old' approval task...(Ginger Gatling delivered a great
> >presentation on this topic at the recent TechEd in Boston).
> >
> >Many thanks,
> >Sue
> >
> >Baunach, Natasha R wrote:
> >
> >
> >
> >>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 approval steps between pre-defined approval
> steps assuming
>
> >>that you allow for ad-hoc approvers (you can disable this
> >>
> >>
> >functionality
> >
> >
> >>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
> >>
> >>
> >and
> >
> >
> >>look for personalization object key 'BBP_WFL_SECURITY'. During
> >>
> >>
> >runtime,
> >
> >
> >>this default can be overwritten in the BADI 'Authorization
> to Change
> >>During Approval' BBP_WFL_SECUR_BADI. So basically, if your
> approvers
> >>
> >>
> >at
> >
> >
> >>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
> >>
> >>
> >complicated
> >
> >
> >>logic in the BADI.
> >>
> >>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.
> >>
> >>
> >I
> >
> >
> >>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
> >>
> >>
> >approver.
> >
> >
> >>I hope this helps.
> >>
> >>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 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
> >>
> >>
> >(SRM
> >
> >
> >>4.0). Have looked at all
> >>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 that approvers must be defined for
> >>every step.' I assume this means that the ApprovalIndex must be
> >>incremented from 0 by 1 with no gaps in it. Am I correct ?
> Or does
> >>this mean that there can be no intervening steps *between* approval
> >>steps ?
> >>
> >>2) Is it possible to pass an approver an approval task, which also
> >>allows them to change the cart ?
> >> But other approvers (different approval levels) can only
> approve or
>
> >>reject? Can I determine 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
> >>
> >>
> >is
> >
> >
> >>greatly appreciated.
> >>Happy WF-ing,
> >>Sue
> >>
> >>
> >
> >
> >
> ------------------------------
>
> _______________________________________________
> 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 3
> **************************************
>
>
>
> -----------------------------------------------
> This message was scanned for malicious content and viruses by Finjan
> Internet Vital Security 1Box(tm)
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message.
Thank you.
------------------------------
_______________________________________________
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 6
**************************************
-----------------------------------------------
This message was scanned for malicious content and viruses by Finjan Internet Vital Security 1Box(tm)
More information about the SAP-WUG
mailing list