Release 1576 introduces a new, optional, feature to PPS that will simplify
the job of correctly assessing charges for employee use of vacation and
sick leave. Currently, for an employee being paid from multiple
distributions, it's necessary to manually calculate and enter the individual
shares of the leave hours on the individual pay lines in batch transactions
or online and thus associate each share with an appropriate FAU. R1576
provides a means by which the system can automatically perform the
proration of charges across eligible FAUs.
You can read the release documents for details, but basically the way it
works is that you would enter a DOS code of 'VAX' (for vacation usage) or
'SKX' (for sick leave usage) on any one of the multiple time lines for an
employee, and that will signal the system to perform the proration. The
effective date of the leave usage will determine whether current pay or
historical pay will be the basis for distributing the costs, and for an
already-run compute cycle, the pay data will be drawn from the DB2 PAR.
These special DOS codes are used only to trigger the proration, and
later in the compute get converted to the traditional 'VAC' and 'SKL'
codes, which is what you'll see in the PAR.
There is a variety of controls to enable you to choose when to use
the automatic proration and when not to use it:
- You can continue to specify the old 'VAC' and 'SKL' DOS codes, in which
case the system will behave as it does now. You also have the option
to use a mix of the two methodologies, which means that on a
department or even individual employee basis you can prorate manually
as before or use the new feature.
- Every time transaction will be assigned a 'prorate leave indicator' that
will be saved and stored in the PAR. (In the DB2 PAR it will become
a field in the ERN table.) This indicator will have yes/no values
(N=no, Y or blank=yes) signifying whether the FAU will be eligible
for assignment of 'VAX' or 'SKX' hours. By default it will be a 'yes'
setting, but you can change that to 'N' to exclude a specific transaction.
My understanding from talking with Jim Tuohig is that when you set the
indicator to 'N', you're telling the system to not include that FAU (which
effectively means a department) in the assessment of the charges but rather
to perform the proration across the other FAUs for the employee.
CICS screens that are modified for display and entry of the prorate
leave
indicator are: EDHC, EDLR/ETLR, EDAP/ETAP, EDTE/ETTE, and
EDTX/ETTX.
Corresponding modified transaction forms are UPAY 640D and UPAY
644A, C, D, and E. UPAY 644B and F are made obsolete.
- An option is provided whereby you can specify fund numbers in the fund
range table, for example hospital funds, that you want excluded. To
support this a new fund grouping of 'NOVAXSKX' is created, along with a
new "below the line" program, PPFAU039 that will be passed an FAU
and, via a lookup of NOVAXSKX entries in the FND table, will reply back
whether the FAU should or should not be excluded.
- A new system parameter, 285, is introduced to 'control the number of
historical earnings months which are permitted for DOS "VAX" or "SKX"
entry. That is, when "VAX" is entered and the associated Transaction
Earnings Date is prior to the number of historical months indicated by
System Parameter 285, the Time Input transaction will be rejected.'
A value of 1 would signify that the proration should be performed for
only the current month; a value of 2 would signify that it should be
performed for the current month and one prior historical month; and so on.
Another way to use this parameter is to set it to zero, which will block all
use of 'VAX' and 'SKX' and effectively turn off the automatic leave usage
proration feature.
R1576 also produces a new report, PPP390A. This report id probably sounds
odd, as the norm is 'PPP' followed by 4 digits, however PPP390 already produces
reports 1 through 9, and 'A' is the traditional one-character shorthand for
'10'.
This report is a Leave Prorate Worksheet that not only shows the breakout of
hours by time line, but also identifies items where the proration has been
blocked, e.g., by a prorate leave indicator value of 'N'.
TABLE UPDATES:
- A template transaction is provided for system parameter 285.
- Samples of optional NOVAXSKX FND table transactions are provided.
- And, message table transactions that can be used in production are provided.
Contrary to what you might expect, 'VAX' and 'SKX' must not be added to
the DOS table.
------------------------------
Release 1593 consists of a followup fixit to program PPP390 to correct a
technical glitch with the end of month date routine that can cause a runaway
job at sites using the prorate leave option. It must be installed at the same
time as r1576 to prevent this problem from occurring in production.
------------------------------
SITE-SPECIFIC ISSUES:
- Hastings has a local modification to the EDHC screen to display employee
hire date, and it happens that its position is right where Base now needs to
display the prorate indicator, so we've moved the hire date field just
to the
right of where DOS code is displayed.
- As is usual with 'below the line' programs that involve logic based on FAU
values, sites using non-standard FAUs must determine whether local
modifications are needed. For r1576 we're talking about new program
PPFAU039. It is passed an FAU, and the Base version plucks out the fund
number from the FAU, sets a flag to say that it wants to check NOVAXSKX
entries in the FND table, and then calls existing utility program PPFAU018
to search for that fund number. Depending on what it finds in the FND
table,
PPFAU039 will return a yes/no answer to say whether the pay transaction is
eligible for leave proration via 'VAX' or 'SKX'.
Riverside has a conventional fund number field and values in its
FAUs, so
I anticipate that we'll be able to use the Base version of PPFAU039.
San Diego has a fund number in its FAU that is 6 bytes rather than the
standard 5 bytes in length, but the infrastructure is set up to
handle that,
and the mechanics of PPFAU039 should work as issued by Base.
Copymembers at compile time will bring in the local field definitions.
Davis definitely requires modifications, as it has no fund number in
its FAUs.
Historically a variety of account attributes has been used in below
the line
as substitutes for fund number. We'll need you to identify which
account
attribute can be used to answer the question, is this FAU eligible
for leave
proration? I expect that, as before, the substitutes for fund can
and will be
stored in the FND table, assuming that Davis chooses to use the
proration
feature.
IMPLEMENTATION
This will be one of the more challenging releases to implement because
local choices and decisions and training are involved. On the other hand,
we don't want to keep r1576/r1593 on the back burner for too long because
it hits some fairly active and frequently modified programs, also because it
makes a DB2 structure change (add the prorate indicator to the ERN table).
The simplest situation would be for a site that does not intend to use the
new functionality. In that case, with your permission, we can go ahead and
install with the feature turned off (parameter 285 set to zero), and the
changes
will scarcely be visible. For sites that do intend to use the leave proration,
a phased approach may be suitable, e.g.:
Phase 1 - Install the release with the new feature turned off.
Phase 2 - Turn the feature on in a limited mode, perhaps with parameter
285 set to a value of one, and letting a small audience of users
begin to
use 'VAX' and 'SKX'. You might want to try it with a department or two
or just the payroll office.
Phase 3 - Once you have some experience, begin to teach and encourage
use of 'VAX' and 'SKX' across the campus, keeping in mind that it's
not required. PPS will be perfectly happy if individual users or
departments
continue to manually prorate with 'VAC' and 'SKL'.
Phase 4 - Over time, tweak the number of historical months in the parameter
to suit your needs.
WHAT WE NEED FROM YOU:
1 - An Ok to install releases 1576 and 1593.
2 - A decision as to whether you plan to use the feature.
3 - If the answer is yes, then:
3A - A value for parameter 285
3B - NOVAXSKX entries for the FND table. We'll be glad to take the
transactions for a test spin.
3C - For Davis, directions on how to support the PPFAU039 functionality.
For RV and SD, we'll assume we can go with the Base version unless
you tell us otherwise.
3D - and information about roll out plans would be welcome
Thank you in advance for all the planning and coordination I know this will
entail....
bvb
|
