Barbara, since this has been happening for an extended period, the EDB may not
contain all the potential names that need to be corrected.  At least in our case, if
the ID# in the IID doesn't find a match in the EDB, then the most recent record in
the history DB should be used.

--On Wednesday, February 02, 2005 11:18 AM -0800 Barbara Vanden Borre
<[log in to unmask]> wrote:

> Release 1624 responds to an error that Davis initially brought to our
> attention, but I later discovered affects nearly every payroll site.  It's
> subtle and may not have come to your attention because it's in an area that
> we don't look at very often, specifically the contents of the UC0IDB table
> in the IID database, which stores identity information (employee id number,
> name, SSN, and birth date).  The problem affects only names in IID.  Id
> numbers, SSNs, and birth dates are fine.
>
> The IID database was designed to be used and maintained via CICS only, not
> through batch processing.  If you perform an online new hire or name or SSN
> change, behind the scenes programs are invoked to ensure that those changes
> are propagated to the IID database as well as entered in the EDB.  Later,
> just one, limited batch IID interface was added, and that's where the
> problem lies.
>
> Employee Self Service offers employees the ability to change their own data
> on the web.  All those payroll-related web entries are turned into batch
> transactions in the FTPUSRx.GET.IVRNH file to be processed five nights a
> week by PPP130 in an abbreviated form of batch EDB file maintenance.
>
> At first the employee-entered transactions were limited to those suitable
> for newly hired employees, hence the name IVRNH = IVR New Hire, nor was
> there any connection with IID data.  Later the options were greatly
> expanded, and among those IVRNH transactions are occasional name changes,
> coded as N1 and N2 transactions, which require IID updates as well as EDB
> updates.  (R1253 in 1999 added the IID support.)  When processed by PPP130
> in a type 5 update, these transactions apply changes to first, middle,
> last, and/or suffix portions of an employee's name in both the EDB and
> IID.    Typically only one of the four fields is modified.  The size of the
> component fields is such that two transactions are required to accommodate
> an entire name, but if only the last name is changed for an employee, only
> an N2 transaction is created whereas if only the first name is changed,
> only an N1 transaction is created, and so on.
>
> When these batch N1 and N2 transactions are processed, names in the EDB and
> IID are correctly updated for the specified employee.  The problem is that
> the same name change is applied to additional employees in the IID who
> never should have been touched.  As an example, if an N2 transaction were
> processed to change Joe Doe's last name to Smith, an unpredictable number
> of other employees would have their last name changed to Smith as well -
> but only in the IID database, not in the EDB.  The same behavior occurs for
> changes to first, middle, and/or suffix portions of the name.
>
> We identified the 'other' employees, who should not have been changed in
> IID, as all those who also had IVRNH transactions -- of any kind -- in the
> same batch and whose employee id numbers were higher than an id with a
> legitimate name change.  This occurred because an internal storage area
> used to pass data between programs was not cleared out between employees,
> so PPP130 thought it had additional employees for whom name changes should
> be applied.  The fix in r1624 is literally a one line re-initialization of
> the storage area.
>
> There are no table updates.
>
> CONSEQUENCES AND IMPLEMENTATION
>
> The batch IID interface referred to above was enabled in 1999, however we
> didn't implement IID processing for our sites (except for ASUCLA which does
> not use it) until approximately 2000-2001, with the date varying by
> site.  The errors have been occurring since IID processing was first turned
> on, but you wouldn't be aware of the incorrect name data unless you
> happened to do a hire and were presented with a list of employees from IID
> who the system thought could potentially be the same person, e.g., have the
> same SSN, and it happened to include one of those with incorrect
> data.  Even then, unless you happened to recognize those 'possibles', you
> wouldn't necessarily realize that a portion of a name was
> incorrect.  That's why the problem has been present for such a long time
> without it being realized.
>
> I ran some matches between EDB and IID yesterday, and came up with these
> counts of employees with name differences.  Some of the variation in
> numbers can be attributed to the number of employees at a site, but it goes
> beyond that.  Culturally there may be greater or less use of Employee Self
> Service features by employees at a particular site, and the more activity
> there is, the more IVRNH transactions there are, and that ripples over to
> more employees whose names were inappropriately updated.
>
> DV - 7315
> RV - 258
> SD - 5773
> SC - 213
> SB - 530
> AS - none (not using IID)
> HA - 3
>
> I recommend that we install r1624 as soon as possible after completion of
> testing so we can prevent any further incorrect name changes.  The next
> step, now being discussed by Base Payroll and Payroll Coordination, will be
> to correct the erroneous entries.  The general thinking at this time is
> that when there is a mismatch, we should assume that the EDB contains the
> correct name.
>
> Ok to proceed?
>
>    bvb



========================================
Lou Browdy, Manager, Computing Support
UCSB Accounting Services and Controls
3201 SAAS Building
Santa Barbara, CA  93106-2040
(805)893-2326(Voice) (805)893-8682(FAX)