Release 1492 responds to the need to make final payment of wages
in a timely manner in accordance with the California Labor Code for
large numbers of employees, e.g., at the end of the regular academic
school year, by providing support for a new type of compute called a
'YX' compute.  It has some similarities to an 'XX' compute, in that it's
ad hoc and dates for it won't appear in the calendar table, but overall
it behaves more like a regular compute.

Much of the new processing is dependent on these three fields, all
of which are system-maintained and not updateable by users:
- Final Pay (FP) Indicator - already defined in the EDB, but now being
   added to the PAR.
- FP Cycle - employee's primary pay schedule for final pay.
   Added to both EDB and PAR.
- FP Date - 'represents either the PCR End Date as taken from the Final
   Pay End Date ... or the current date when the update source is Rush
   Checks'.  Also added to both EDB and PAR.

This is a complex new process, and the release letter and Detail Design
documents do an excellent job of describing it.  The presentation is more
functional and less technical than usual, and I recommend reading them.
Below I'm listing some of the high points:

INITIATION OF THE COMPUTE

   The payroll manager will identify the need and the dates for a 'YX' compute
and will schedule it in advance with UCOP Production Control.  Initially, as
we familiarize ourselves with the process, it will have to be on an ad hoc
basis, however it would be helpful if you could schedule it on your local
calendars for next June, assuming you plan to run it then.  The service
request for r1492 described a new ISCA online CICS screen to assist in
identifying potential candidate dates for 'YX' computes, but that screen
was not included in the release.  Note that these special cycles must be
coordinated with the banks.

TIMING AND ELIGIBLE POPULATION

   Selection of the population is based on employee primary pay schedule,
i.e., MO, MA, or semi-monthly, and a date on which the payroll manager
expects large numbers of employees to separate.  Note that there
is no support for biweekly cycles due to the extended arrears timing of
regular BW computes and the complexity of dealing with biweekly cycles
that cross monthly and fiscal year boundaries.  The example given in
release documents is that of an MO compute with an 063003 pay period
end date.  Many employees paid on the MO cycle leave mid-month in June
and due to state regulations must be paid long before the regular compute
is run.  The trick is to identify a specific date on which many of these
employees will be separated or their appointments will end.  In the example,
that date was given as 062003, but it could just as well have been 061303
or 061203, which I believe were dates on which many campuses ended their
spring terms.

The selection of employees occurs in the 'timesheet' job and is based on
the PPP340 spec card.  Basically you fill in all of the information for the
regular compute you're simulating (begin and end dates, compute type,
e.g., 'MO', and regular check date) and you add to that a special check date,
compute type, and end date.  The special compute type is required to be
'Y-something', and our convention will be 'Y1' for the first YX of a month,
and 'Y2' for the second.  The special pay period end date is the basis for
selecting employees.  All employees with the specified primary pay
schedule and separating on, or with appointments ending on, the special
end date will be selected and will be written to an online time roster when
PPP320 is run.   It doesn't matter whether they're positive or exception
people or whether they're normally paper timesheet or online roster people,
they'll be eligible and will be written to the online roster.

A key component to the process is that pay on the selected employees'
regular compute will be blocked, therefore 'YX' final pay computes must be
run prior to their corresponding regular computes.

PROCESSING

- Paper timesheets/timefiles are not supported.  An attempt to run PPP300
   for a 'YX' compute will cause it to fail.
- You can't sneak in transactions to be edited for employees who are not
   part of the final pay population.  They'll be blocked.
- PPP390 is modified to not perform automatic pay processing because
   the AU folks were included on the roster.
- PPP400 performs normal deductions, as if the employees were being
   paid on their regular pay cycle.
- PPP420 generates paper checks (mandated by the state) for all
   final pay employees.
- Note that there could be Fidelity deductions, so in spite of the fact that
   everyone will receive a paper check, we still must run PPP430.
- Re bank transmissions, there will always be a RECON file, and
   there may or may not be a NACHA file, depending on whether there
   was any GTN Surepay activity.

TABLE UPDATES
   Transactions are provided with which to update the data element table
and the message table.

IMPLEMENTATION
   Note that 'YX' computes are dependent on the use of online time rosters,
thus, although r1492 must be installed for all sites, as things stand
currently,
they can not be used for ASUCLA or Santa Cruz (or for Davis Medical Center
employees unless the campus payroll office does the data entry and so on).
It is, however, feasible to use online rosters for only 'YX' computes and
continue to run regular computes based on paper timesheets/timefiles.

Hastings, I'm not sure whether you would find the 'YX' compute useful for
you, given that it's generally seen as a 'bulk processor', but we're certainly
willing to run it for you if you want us to do so.

Operationally we're still working out some details about job naming and such,
and we'll send more information later on to those sites expressing an interest
in running a 'YX' compute.

I'd appreciate it if you would let us know three things:

- Whether you anticipate using YX computes.
-  If yes, the timeframe, and if it's in June, the dates you have in mind.
-  And as usual, we'd like your ok to install the release.

If you have questions, let us know....

   bvb