attendance.approved vs attendance.created (40B)

[Dart, Jocelyn]

Hi Michel,
I won't give you my personal opinion of the HR events because language that
strong
should never be put in an email, but I can perhaps give you a few clues
based on my
own experience with HR events.  If there's an HR person out there perhaps
they can
elaborate....
 
The problem stems from the "lock indicator" field, which is used to indicate
whether or
not an HR record is active.  Some *expletive deleted* put the lock indicator
in the key
of the HR record.  So when you are going through the approval process what
can happen is
this:
 
User creates original locked record: CREATED event is raised for the new
locked record.
Locked record is approved: APPROVED event is raised for the locked record.
The locked
record is then "unlocked" - because this is a change in key, this means the
locked
record has been deleted and a new record is created - raising the CREATED
event.
An unlocked record is locked again - i.e. the approval has been cancelled,
therefore
a REQUESTCANCELLED event is raised for the unlocked record, and the record
is then
locked - because this is a change in key, this means the locked record has
been deleted
and a new record has been created - raising the CREATED event and so on and
so forth.
 
If you think this is *expletive deleted* confusing you are absolutely
correct.  I was working
across several types of HR records - I can't remember if ATTENDANCE was one
of them but
the behaviour seemed to be common to a  lot of HR records.
 
In the end for my HR workflows, I ended up using the HR event tables and the
option of using
HR event function modules to control the events to try and make sure the
following was happening:
 
If a record is created "locked" - raise REQUESTED event (not CREATED)
If a record is created "unlocked" - raise CREATED event
If a locked record is unlocked - raise APPROVED event for old record,
CREATED for new record
If an unlocked record is locked - raise REQUESTCANCELLED event for old
record, REQUESTED for new record
 
At least that way I had a consistent behaviour going that I could workflow
against.
But I'll admit that as a non-HR person I did get the help of some friendly
HR folk to help
me sort this out, and I had some HR event function module examples to work
from.
 
Hope that helps a little anyway.
 
If anyone else in the SAP-WUG has some better way of handling it, I'd love
to know it myself for future
reference.
Regards,
 
Jocelyn Dart
Consultant (BBP, Ecommerce, Internet Transaction Server, Workflow)
SAP Australia
Email  <mailto:jocelyn.dart at sap.com> jocelyn.dart at sap.com
Tel: +61 412 390 267
Fax: +61 2 9935 4880
 
-----Original Message-----
From: Michel Laviolette [mailto:michel_laviolette at hotmail.com]
Sent: Thursday, 21 June 2001 5:31 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: attendance.approved vs attendance.created (40B)
 
 
Hi,
I've been experiencing discrepancies with some of the events raised
(created) through the HR attendance approval process. I have event traces
(logs) indicating that the attendance approval sometimes (???) raises the
ATTENDANCE.CREATED followed by ATTENDANCE.REQUESTCANCELLED... Some other
times, the event ATTENDANCE.APPROVED is followed by ATTENDANCE.CREATED.
These inconsistencies seam to originate behind the 'Fast Entry' (PA71)
approval process. My Attendance workflow has a wait for event
REQUESTCANCELLED which needless to say only traps half of the conditions
listed above.
 
My Questions:
1) Can anyone explain why the REQUESTCANCELLED & APPROVED events are
interchanged?
2) If I include a wait for event APPROVED, what other processes could be
impacted?
 
Many thanks,
Michel Laviolette
Workflow Developer
Hull Quebec Canada
 
 
 
 
 
 
 
 
  _____
 
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
<http://www.hotmail.com> .
 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20010620/c88bab1b/attachment.htm