SAP-WUG Digest, Vol 48, Issue 47

Mon Nov 24 11:13:40 EST 2008

Hi
   Regarding   Condition Editor for a Trip expenses wrkflw .
Go to SWB_COND tx and specify  Condition , what ever you required.
If you want to specify any User name . Use name Field(Consider L_usre_name)
 should be in Business object Attribute.
Balaji.T

On Fri, Nov 21, 2008 at 9:31 PM, <sap-wug-request at mit.edu> wrote:

> 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: Condition Editor for a Trip expenses wrkflw (John A Haworth)
>   2. SWCONT's limitations with long values... (Mike Gambier)
>   3. RE: SWCONT's limitations with long values... (Mike Gambier)
>   4. RE: SWCONT's limitations with long values... (Mike Gambier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Nov 2008 15:09:23 +0000
> From: John A Haworth <jhoworth at csc.com>
> Subject: RE: Condition Editor for a Trip expenses wrkflw
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Message-ID:
>        <OF71C4E59B.E1132E6A-ON80257508.00535ACE-80257508.005364F0 at csc.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for that.
>
> Kind Regards
>
> JOHN HAWORTH
> CSC
>
> Euxton House
> Euxton Lane
> Chorley
> PR76FE
> Office:01257236457
> Mob:  07710917927
>
>
>
>
> CSC ? This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery.  NOTE: Regardless of content, this e-mail shall not
> operate to bind CSC to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose
>  ?
> CSC Computer Sciences Limited ? Registered Office: Royal Pavilion,
> Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK ? Registered in England
> No: 0963578
>
>
>
> "Sue Doughty" <Sue.Doughty at odfl.com>
> Sent by: sap-wug-bounces at mit.edu
> 21/11/2008 14:33
> Please respond to
> "SAP Workflow Users' Group" <sap-wug at mit.edu>
>
>
> To
> "SAP Workflow Users' Group" <sap-wug at mit.edu>
> cc
>
> Subject
> RE: Condition Editor for a Trip expenses wrkflw
>
>
>
>
>
>
> Hi John,
>
> The Agents container in the condition editor is the user that triggered
> the event.
>
> In the Condition editor on the Start Events tab check that Agents =
> Trip.Traveler?s User.
>
> Regards,
> Sue T. Doughty
> SAP Workflow Specialist
> Old Dominion Freight Line, Inc.
> 500 Old Dominion Way
> Thomasville, NC 27360
> Phone:  (336) 822-5189
> Toll Free (800 ) 432-6335, ext. 5189
> Email:  sue.doughty at odfl.com
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
> Of John A Haworth
> Sent: Friday, November 21, 2008 7:57 AM
> To: SAP Workflow Users' Group
> Subject: Condition Editor for a Trip expenses wrkflw
>
>
> Hi
>
> I need to use the condition editor to limit the triggering of a workflow
> based on the person who initiates the workflow should be the same as the
> person identified in the Trip object.
>
> In the editor I can see the Trip object and under the System Field I can
> see the %User Name% Who is this User Name ? I really want the workflow
> initiator, but cant see it ??
>
> Kind Regards
>
> JOHN HAWORTH
> CSC
>
> Euxton House
> Euxton Lane
> Chorley
> PR76FE
> Office:01257236457
> Mob:  07710917927
>
>
>
>
> CSC ? This is a PRIVATE message. If you are not the intended recipient,
> please delete without copying and kindly advise us by e-mail of the
> mistake in delivery.  NOTE: Regardless of content, this e-mail shall not
> operate to bind CSC to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose
> ?
> CSC Computer Sciences Limited ? Registered Office: Royal Pavilion,
> Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK ? Registered in England
> No: 0963578 _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.mit.edu/pipermail/sap-wug/attachments/20081121/7bf764c0/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Nov 2008 15:30:31 +0000
> From: Mike Gambier <madgambler at hotmail.com>
> Subject: SWCONT's limitations with long values...
> To: <sap-wug at mit.edu>
> Message-ID: <BAY117-W27190EFD8167C1D5B2EB94D50F0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> Hi,
>
> I'm trying to convince SAP that using a really long structure-based single
> line importing parameter for a BApI, that might grow and grow, isn't a smart
> idea because SWCONT is limited to 255 chars. My fear is that we'll hit some
> sort of limit somewhere which will cause problems, whether that will be in
> BoR elsewhere like a BAdI.
>
> They've come back and said that swc* macros can cope with longer strings at
> runtime and no truncation will result. Personally I'm not convinced and can
> only assume that the SAP code flicks into set/get table mode to cope
> somehwere, but I can't seem to find where..does anyone here know whether it
> can do this and how?
>
> Regardless of their suggested approach, I want to try and impress upon them
> that a nested unstructured approach is more suitable to our needs and
> something more akin to SAP's Master Data Generator table EPRODA (which
> assigns a type definition to an element) has more of a future in our system.
>
> But they're being a bit stubborn about this and any ammuntion from the WUG
> about pitfalls when using long parameter definitions like this would be
> useful.
>
> Thanks in advance,
>
> Mike GT
> _________________________________________________________________
> See the most popular videos on the web
> http://clk.atdmt.com/GBL/go/115454061/direct/01/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.mit.edu/pipermail/sap-wug/attachments/20081121/0a2a5770/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 Nov 2008 15:40:37 +0000
> From: Mike Gambier <madgambler at hotmail.com>
> Subject: RE: SWCONT's limitations with long values...
> To: <sap-wug at mit.edu>
> Message-ID: <BAY117-W38F6FC00758DAC008C0A5AD50F0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi again,
>
> I forgot to mention that the example they provide where an importing
> parameter structure is already longer than 255 is BoR Object Method
> ISUCONTRCT.ChangeFromData where parameter ContractData is based on
> BAPIISUCONTRACT which is 386 chars long in our system.
>
> So, it must be able to cope somehow...presumably if I could be bothered to
> debug it I'd find out how ;)
>
> MGT
>
>
>
> From: madgambler at hotmail.comTo: sap-wug at mit.eduSubject: SWCONT's
> limitations with long values...Date: Fri, 21 Nov 2008 15:30:31 +0000
>
>
>
> Hi,
>
> I'm trying to convince SAP that using a really long structure-based single
> line importing parameter for a BApI, that might grow and grow, isn't a smart
> idea because SWCONT is limited to 255 chars. My fear is that we'll hit some
> sort of limit somewhere which will cause problems, whether that will be in
> BoR elsewhere like a BAdI.
>
> They've come back and said that swc* macros can cope with longer strings at
> runtime and no truncation will result. Personally I'm not convinced and can
> only assume that the SAP code flicks into set/get table mode to cope
> somehwere, but I can't seem to find where..does anyone here know whether it
> can do this and how?
>
> Regardless of their suggested approach, I want to try and impress upon them
> that a nested unstructured approach is more suitable to our needs and
> something more akin to SAP's Master Data Generator table EPRODA (which
> assigns a type definition to an element) has more of a future in our system.
>
> But they're being a bit stubborn about this and any ammuntion from the WUG
> about pitfalls when using long parameter definitions like this would be
> useful.
>
> Thanks in advance,
>
> Mike GT
>
> BigSnapSearch.com - 24 prizes a day, every day. Search now
> _________________________________________________________________
> See the most popular videos on the web
> http://clk.atdmt.com/GBL/go/115454061/direct/01/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.mit.edu/pipermail/sap-wug/attachments/20081121/4a6e878d/attachment-0001.htm
>
> ------------------------------
>
> Message: 4
> Date: Fri, 21 Nov 2008 16:01:07 +0000
> From: Mike Gambier <madgambler at hotmail.com>
> Subject: RE: SWCONT's limitations with long values...
> To: <sap-wug at mit.edu>
> Message-ID: <BAY117-W39916B7DE1E0D4963331EFD50F0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Apologies for the spam :P
>
> So, OK it decomposes the structures element by element (but only up to 255
> chars for each). Hence a container becomes quite full of 'sub' elements
> belonging to the parent element.
>
> I think I knew this...been a while since I've neeeded to care about it XD
>
> But...I still don't think this is ideal where the parameter will be
> extended a lot...
>
> I know that I can pass a multi-line table based on SWCONT into an
> SWCONT-based container (so setting a container into a container as a table),
> so I'm leaning towards suggesting an unstructured 'table of elements +
> values' instead of a complex structure...
> Pity BoR can't cope with ABAP_PARMBIND though...
>
> MGT
>
>
>
> From: madgambler at hotmail.comTo: sap-wug at mit.eduSubject: RE: SWCONT's
> limitations with long values...Date: Fri, 21 Nov 2008 15:40:37 +0000
>
> Hi again, I forgot to mention that the example they provide where an
> importing parameter structure is already longer than 255 is BoR Object
> Method ISUCONTRCT.ChangeFromData where parameter ContractData is based on
> BAPIISUCONTRACT which is 386 chars long in our system. So, it must be able
> to cope somehow...presumably if I could be bothered to debug it I'd find out
> how ;) MGT
>
>
>
> From: madgambler at hotmail.comTo: sap-wug at mit.eduSubject: SWCONT's
> limitations with long values...Date: Fri, 21 Nov 2008 15:30:31 +0000
>
>
>
> Hi,
>
> I'm trying to convince SAP that using a really long structure-based single
> line importing parameter for a BApI, that might grow and grow, isn't a smart
> idea because SWCONT is limited to 255 chars. My fear is that we'll hit some
> sort of limit somewhere which will cause problems, whether that will be in
> BoR elsewhere like a BAdI.
>
> They've come back and said that swc* macros can cope with longer strings at
> runtime and no truncation will result. Personally I'm not convinced and can
> only assume that the SAP code flicks into set/get table mode to cope
> somehwere, but I can't seem to find where..does anyone here know whether it
> can do this and how?
>
> Regardless of their suggested approach, I want to try and impress upon them
> that a nested unstructured approach is more suitable to our needs and
> something more akin to SAP's Master Data Generator table EPRODA (which
> assigns a type definition to an element) has more of a future in our system.
>
> But they're being a bit stubborn about this and any ammuntion from the WUG
> about pitfalls when using long parameter definitions like this would be
> useful.
>
> Thanks in advance,
>
> Mike GT
>
> BigSnapSearch.com - 24 prizes a day, every day. Search now
>
> Win ?1000 John Lewis shopping sprees with BigSnapSearch.com Search now
> _________________________________________________________________
> Win ?1000 John Lewis shopping sprees with BigSnapSearch.com
> http://clk.atdmt.com/UKM/go/117442309/direct/01/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.mit.edu/pipermail/sap-wug/attachments/20081121/9706c3ae/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> End of SAP-WUG Digest, Vol 48, Issue 47
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20081124/cc14d4e6/attachment.htm