Link to BUS2009 object not working in workitem

Mon Jun 21 23:27:52 EDT 2010

Hi Jocelyn,

I'm struggling to understand why the exact same call of a function
module should work differently in the method of a delegated subtype
(ZBUS2009) as opposed to in the supertype (BUS2009).

I tried setting ENJ_CALL_ME53N, it had no effect. If I understand the
code correctly, it will always pick ME53N except if ENJ_CALL_ME53N
exists and set to ' '. So I didn't expect it to make a difference
anyway.

cheers
Rick Bakker
Hanabi Technology

On Tue, Jun 22, 2010 at 11:16 AM, Dart, Jocelyn <jocelyn.dart at sap.com> wrote:
> Ummmm....
> Ok well the fact that the workaround work is works-as-designed behaviour.
> You are supposed to be able to use a delegated subtype with your own default method.
>
> Did you check the Set/Get Parameters?  Because MMPUR_REQUISITION_DISPLAY works on set/get parameters
> ENJ_CALL_ME53N and ME_DISPLAY_ONLY to determine whether to call ME53 or ME53N....
>
> So it would only take the wrong set/get parameters values in the wrong user master or a setting changed during a session by e.g. going to ME53N directly to make a difference.
>
> Regards,
> Jocelyn
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Rick Bakker
> Sent: Tuesday, 22 June 2010 12:59 PM
> To: SAP Workflow Users' Group
> Subject: Re: Link to BUS2009 object not working in workitem
>
> Hello Workflowers,
>
> I don't have a fix but I do have a workaround.
>
> To recap:
> - ECC6
> - custom workflow based on BUS2009 (Purchase Requisition Item)
> - workitem contains link to the object instance (as per default
> behaviour) in SBWP
> - clicking on the link to the object instance (by regular users) has no effect;
>  expected behaviour is that it should display the PRI via tx ME53N;
>  SU53 says that authorization failed on tx SWIA;
>  ST01 says that authorization failed on tx ME53
>
> My workaround is to delegate to ZBUS2009 (I was doing this anyway) and
> create a method called DISPLAY2 which is an exact copy of the DISPLAY
> method of BUS2009 (which calls fm MMPUR_REQUISITION_DISPLAY). This
> DISPLAY2 is then set to the default method of ZBUS2009.
>
> I have no idea why this works, but it does. A bug? I tried
> regenerating BUS2009, it didn't help. Good news is that the users
> don't need any extra privileges. So no need to let them have SWIA!
>
> If anyone has any ideas on how to get the BUS2009 method working, feel
> free. I'll give them a try.
> I'd prefer not to change BUS2009 itself.
>
> cheers
> Rick Bakker
> Hanabi Technology
>
> On Tue, Jun 22, 2010 at 7:55 AM, Ravi Dixit <dolbydix at gmail.com> wrote:
>> Hi Rick
>>
>> We had similar issues with HR related items as well like infotype updates.
>> We got exactly the same auth error.
>> Let us know if you come with with a fix.... :)
>>
>> Cheers
>> Ravi
>>
>> On Mon, Jun 21, 2010 at 2:04 AM, <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: Link to BUS2009 object not working in workitem (Rick Bakker)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sun, 20 Jun 2010 12:14:34 +0800
>>> From: Rick Bakker <rbakker at gmail.com>
>>> Subject: Re: Link to BUS2009 object not working in workitem
>>> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
>>> Message-ID:
>>>        <AANLkTilKyY-AHI8d-o9iBeOKwxML5RaM7a2mOZUAxagU at mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> Hi Workflowers,
>>>
>>> Thanks for all the suggestions. I will get to the bottom of this and
>>> report back!
>>> At the moment it looks like there's an authorization missing or a
>>> setting set wrong which causes fm MMPUR_REQUISITION_DISPLAY (called by
>>> the Display method of BUS2009)  to choose tx ME53 instead of ME53N.
>>> The users don't have authorization to run ME53 (this shows up in ST01)
>>> and that's the way it should be. Now just have to find out why it's
>>> doing this.
>>>
>>> cheers
>>> Rick Bakker
>>> Hanabi Technology
>>>
>>>
>>> On Sun, Jun 20, 2010 at 12:09 AM, Mike Pokraka
>>> <wug at workflowconnections.com> wrote:
>>> > Hi Rick,
>>> >
>>> > You are completely right SWIA is complete overkill and should never be
>>> > given to everyone.
>>> > The issue with SU53 is that it will report the last failed check. The
>>> > workflow system will sometimes check several authorisations before
>>> > failing. I think you can figure out where this is leading...
>>> >
>>> > Do an auth trace with SM05 instead.
>>> >
>>> > Cheers,
>>> > Mike
>>> >
>>> >
>>> > On Thu, June 17, 2010 11:16 am, Rick Bakker wrote:
>>> >> Hello,
>>> >>
>>> >> Thanks for the responses. I tried the personal workflow settings but
>>> >> no luck. Haven't tried the authorizations yet.
>>> >>
>>> >> Isn't it a bit dangerous to give everyone SWIA access?
>>> >>
>>> >> thanks!
>>> >> Rick Bakker
>>> >> Hanabi Technology
>>> >>
>>> >>> Try assigning the below authorization to all User Roles
>>> >>>
>>> >>> Object S_TCODE
>>> >>> ?for field SWO_ASYNC
>>> >>> and
>>> >>> AUTH - - - S_TCODE RC=0 TCD=SSC1;
>>> >>> AUTH - - - S_TCODE RC=0 TCD=SSC0;
>>> >>>
>>> >>> Alternately , you can check the workaround below :
>>> >>>
>>> >>> In the personal workflow settings , Check the check box "Double
>>> >>> Clicking
>>> >>> on
>>> >>> an object displays the object in the same window " .
>>> >>>
>>> >>>>
>>> >>>> to open the link the user indeed needs authorisation for transaction
>>> >>>> SWIA.
>>> >>>> I had the same issue and when the authorisation for transaction SWIA
>>> >>>> was
>>> >>>> given to the users everything worked fine.
>>> >>>>
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>>
>>>
>>> End of SAP-WUG Digest, Vol 67, Issue 56
>>> ***************************************
>>
>>
>>
>> --
>> Best Regards
>> Ravi Dixit
>>
>> _______________________________________________
>> 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
>