ESS Leave request Workflow

Thu May 12 10:25:33 EDT 2005

Mike
I have added BUS1065 to the workflow container and implemented a step to get the employee details.
I now have object services available and the approver can be seen from PA20.
Many Thanks for this.
David

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu]On Behalf
Of Michael Pokraka
Sent: 12 May 2005 10:14
To: SAP Workflow Users' Group
Subject: RE: ESS Leave request Workflow

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 destroye
d, 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.