BASIS Steering committee
and Bob Zimmerman
W. David Wimberly
BASIS-L discussion list
Computing Services BASIS May Status
Tweaking and tuning of most functions continued through May.
TAs are created as closed POs when there are no reimbursables,
a Company Center is required even though there are no reimbursables,
approval of a TA with an advance is permitted even though it is after
the departure date,
obsolete vendor names or addresses are no longer accepted,
and the list goes on.
Bugs were fixed, field edits added,
screens re-laid out, audit information changed, and
decode windows created.
New functions for the month included:
The following activities occurred in the batch arena:
- LILP, List Invoice Lines for a PO.
- LIST, List Invoices for a Status, Type by payment consolidation
code and date payment (scheduled or actual).
- TAN, maintenance routine for the Travel Agency (vendor) Number used
by default when an airfare TRPO is indicated on the TA.
- MPTA, which permits the Travel Office to Modify in-Process TAs.
- DCPU, used to update the Date Check Picked Up in the Treasurer's
- The format and content of the Travel Advance checks were modified,
and a file and record layout of this data was prepared for
- The encumbrance accounting and reporting routines
have undergone a second major rewrite to accommodate the decision to
report current and end of period data.
The new Purchase Order Summary report includes the same MSA data
previously reported (current as of the time of the run) and Travel PO
data -- current data equivalent to that coming from MSA plus
end of period encumbrance balances, a blanket
indicator, and status.
This report has been completed along with the generation of transactions
to create Travel encumbrances in MSA at the end of a period and to
reverse those the following period.
- Work continues on the other interface to MSA, the generation of
transactions to load three types of invoices (travel advance manual
checks, travel claims, and travel related invoices)
plus adjustment documents (required when
an advance exceeds the claim).
Most of the details have been worked out, and we are about ready to
test these transactions.
- Reports for the Checks on Hand and
the Outstanding Travel Receivables (sorted three ways)
are near completion.
Remaining development tasks include
completion of the batch processes identified above,
finishing the MPTR (Modify in-Process Travel Related purchase orders)
writing invoice lists as they are identified,
generation of a 'dun' notice when an advance exceeds a claim,
developing an online job submission function,
and getting all the batch job changes documented for
In our spare time we will
continue to fix problems as they are reported and begin putting our
System Manual documentation together for the system.
There has been no activity to report in this area.
Various fixes and enhancements are continually being made to this
The most significant developments follow.
- A change was made to the method devised for segregating the checks
that have to be held for pickup due to missing paper work.
The Level-5 field now remains the check distribution BU, and only
Level-3 and Level-4 are set to ZZZ9.
Several online functions were affected by this change.
- A new MSA SYNC process has been developed to update BASIS information
for appointed employees with data currently on MSA.
Further testing of this function is required.
- A bug was found and corrected in the Employee conversion process
whereby hourly employees were being set as eligible for leave.
- The batch programs were finished that generate the regular
hourly time transactions and the overtime transactions.
Part of this process determines if the employee's FICA exemption status
is currently set correctly on MSA, and changes it if necessary.
It also identifies any time that has not been approved, reschedules it
for payment on the next payroll run, resequences that time to the
end of the overtime list, and recomputes the overtime.
- Test transactions were generated out of HRLY-TS, processed
through an MSA payroll, and then loaded to LABOR.
- A briefing was held with Production Control to inform them of
the planned changes to the production systems.
- Several problems were found with
TEHA (time entry for hourly appointed) related to how it handled
We believe those have now been corrected.
- A special Company Cost Center distribution window was developed
for TEHA and Leave's EXTM.
- LTHT, List Transactions for Hourly Time approval, was developed.
- Input continued to be provided to HR on the Quick Reference Card,
their test plan, and training materials.
Our primary remaining activities include continued testing
and responding to identified problems.
We also plan to develop
an employee hourly time consolidation function to
aggregate and display all
time reported for a period,
generate transactions to load work study payments to SAFARI,
and update our System Manual documentation.
The following activities occurred for Leave during May.
Time was also spent reviewing Michelle's test plan and new
Quick Reference Card.
Remaining activities include
developing a special function to view old EXTM data and
modifying existing reports to use the new data source.
The following development activities were completed during May.
- A routine was written to accrue comp time that had
been elected and approved, and to recompute the employee's leave
balances with that data.
This process will be done after the cutoff for overtime approval,
since the data and the approvals can be changed up until that point
- EXTM, extra time maintenance, had several problems corrected.
- MNLV, monthly leave, now displays the total leave hours entered
for the month.
- A program was written
to create monthly leave records for employees that
have not yet had activity in a month.
This used to be part of the SYNC process but has been separated since
the SYNC is now for the EMPLOYEE file and is somewhat application
- The Payroll Distribution function, PD, was enhanced to include
facilities for A21 certification
and to carry over the percent distribution versus the gross dollars
on a copy action.
- The function to allow changes to title codes and compensation
periods (TCP) was completed.
- The function to define the default compensation periods
(DCP) for each payroll was written.
- The function to pre-define a compensation period (PCP)
for an employee and payroll was written.
Most online functions then were modified to ignore or disregard these
Subsequently, an improved manner of handling these entries was
developed so that these exceptions did not have to be made, and PCP
was modified and the special processing removed from other online
- The List Predefined compensation periods Not Paid (LPNP)
function was written.
- The SUI and Workers Compensation tax rates were added to the
control data maintained by CTLD.
- The load process was modified to use the default and pre-defined
compensation definitions, use the SUI/Workers Comp rates from the
control file, and produce
- The programs to produce the
accounting entries for GL for both a payroll load and for retroactive
adjustments were completed and test output provided to Financial
- Test runs were made loading data output from HRLY-TS and feed
through a test MSA payroll.
- Kathryn provided suggestions to HR for items to be included
in their test plan.
Computing Services has now completed the critical
programming functions identified as being required by June 1
and is available to support HR's testing.
Other development still outstanding includes
the development of reports and data extracts, and
the setup and documentation of batch production changes.
The modifications completed and reported in my April status report
have now been moved to production.
There has been no activity involving this application.
The new TARGET commands and Criteria Types for TRAVEL,
HRLY-TS, and LABOR were defined on production.
We are approaching 100 commands within the UPS system.
This will undoubtedly present a problem involving NSM security since
it only permits 100 commands to be allowed or disallowed per command
The primary method of defining access is in terms of listing the
commands allowed since it also permits a more restrictive security
level to be specified (read only).
I am planning to investigate the possibility of providing a third
method in which a combination of these two methods can be employed:
commands to be disallowed would be identified along with commands
that are allowed with a more restrictive security level.
Given this method, commands available with the desk's normal security
level would not have to be identified and the life of the
100 command limit extended.
I believe this would also simplify the security administration task
for the application owners.
Kathryn continues to provide support to desk
administrators as requested.
Please feel free to raise any questions or concerns prompted by this