ESS Leave request Workflow

[Michael Pokraka]

Hi David, 
You need to include the more generic BUS2065 object on top of the EMPLOYEET as
a container element in your WF for the PA20 object services to find your flow,
as EMPLOYEET doesn't have a simple PERNR as a key. 

Also, if users don't have access to PA20, why should they want to see who
approved leave that they cannot see? (That reminds me, I must go see the
Hitchhiker's Guide to the Galaxy). Or what about the leave request overview in
the portal - that shows the approver? 
Another issue is that sometimes the leave is created manually as part of the
flow, so the approver still won't feature as per your requirements. 

A nice argument for your compliance folks (aside from this is best practice in
the rest of the known universe) is that WF-BATCH is deliberately used for
security. It's 'policy' that nobody outside HR can modify personnel records and
managers creating leave opens up a potential risk.... yadayada, you get the
idea.

Cheers
Mike

--- "Bibby, David" <david.bibby at Linklaters.com> wrote:

> Mark,
> Thanks for your suggestions.
> Unfortunately we are using the portal for this workflow and PA20 doesn't
> appear to have object services available either.
> The BAPI doesn't allow me to specify the user.
> 
> I have checked the workflow and the step before the one that creates the
> absence is in the sub workflow 'Find employee and lock' and has 'Avance with
> Dialog' set.
> 
> The chances of convincing our compliance department are slim and giving users
> auth to PA20 won't be allowed.
> I'm surprised more people have not come across this issue, but our compliance
> dept are particularly hot on just about everything.
> 
> It looks like I may have to go down a more custom route although I won't be
> doing any direct table updates. 
> 
> Regards
> David
> 
> 
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]On Behalf
> Of Mark Pyc
> Sent: 11 May 2005 16:59
> To: SAP Workflow Users' Group
> Subject: Re: ESS Leave request Workflow
> 
> 
> G'day David,
> 
> This is a bit of classic. You've got a couple of basic choices. 
> 
> 1 - Convince your compliance team that the Workflow log contains all
> authorization history. Not sure about this specific transaction but
> most have a link to object services which gets you to the log. This is
> always my preference.
> 
> 2 - Use the 'Advance with Dialog' functionality and wrap the call in a
> non-background non-dialog step. So it is a foreground step but it
> contains no dialog interaction. When this is the subsequent step to
> the approval it will happen under the user-id of the approver
> completely transparently to the user. (This assumes you're not using
> the portal and UWL where this doesn't work.) In this case you need to
> ensure that the authorisers have sufficient authority to perform the
> action.
> 
> It is possible in some cases that the BAPI allows you to specify the
> Update user, but not often. Of course there are always other 'dirty'
> options. You could always go and manually update the 'Changed by'
> value but that's entering into a whole other world of issues.
> 
> Have fun,
> Mark
> 
> On 5/11/05, Bibby, David <david.bibby at linklaters.com> wrote:
> > Hello,
> > I have a problem whereby the absence record created by this workflow is a
> background step and is therefore created by WF-BATCH.
> > The business requirement is that when the users go into transaction PA20 to
> view absences they want to see the approvers name not 'WF-BATCH'. Apparently
> this is for compliance reasons.
> > 
> > One solution I have is to create a Z copy of the BAPI
> BAPI_PTMGRATTABS_MNGCREATION.
> > >From initial investigation into this BAPI it's not obvious where it needs
> modifying. It could mean modifying more than one if the actual change needed
> is another function call within this BAPI. I would also need to delegate this
> BO and create a new method on the Z business object plus a new workflow step
> to replace the existing standard one.
> > 
> > This solution seems quite laborious and I wondered if anyone had come
> across this problem before and had another solution, or am I already on the
> right track with what I propose above ?
> > 
> > Many Thanks In Advance
> > David
> > 
> > -----------------------------------------------------------------------
> > 
> > This message is confidential. It may also be privileged or
> > otherwise protected by work product immunity or other legal
> > rules. If you have received it by mistake please let us know
> > by reply and then delete it from your system; you should not
> > copy it or d
> isclose its contents to anyone. All messages sent
> > to and from Linklaters may be monitored to ensure compliance
> > with internal policies and to protect our business. Emails are
> > not secure and cannot be guaranteed to be error free as they
> > can be intercepted, amended, lost or destroyed, or contain
> > viruses. Anyone who communicates with us by email is taken
> > to accept these risks.
> > 
> > The contents of any email addressed to our clients are subject
> > to our usual terms of business; anything which does not relate
> > to the official business of the firm is neither given nor endorsed by it.
> > 
> > The registered address of the UK partnership of Linklaters is One
> > Silk Street, London, EC2Y 8HQ. Please refer to
> > http://www.linklaters.com/regulation for important information on
> > the regulatory position of the firm.
> > 
> > _______________________________________________
> > 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
> 
> 
> 
> -----------------------------------------------------------------------
> 
> This message is confidential. It may also be privileged or
> otherwise protected by work product immunity or other legal
> rules. If you have received it by mistake please let us know
> by reply and then delete it from your system; you should not
> copy it or disclose its contents to anyone. All messages sent
> to and from Linklaters may be monitored to ensure compliance
> with internal policies and to protect our business. Emails are
> not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, lost or destroyed, or contain
> viruses. Anyone who communicates with us by email is taken
> to accept these risks.
> 
> The contents of any email addressed to our clients are subject
> to our usual terms of business; anything which does not relate
> to the official business of the firm is neither given nor endorsed by it.  
> 
> The registered address of the UK partnership of Linklaters is One 
> Silk Street, London, EC2Y 8HQ. Please refer to 
> http://www.linklaters.com/regulation for important information on
> the regulatory position of the firm.
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>