BASIS Steering committee
W. David Wimberly
Colleen Briney, Jim Isch, David Keith,
and Bill Overby
Computing Services BASIS November/December Status
This report will cover November and the first part of December. My next report will cover the last half of December and January and will be prepared the first of February.
The biggest development for the past period is that the UPS Vendor Maintenance subsystem has gone to production in order to support 1994's 1099 vendor reporting. A lot of effort from many offices went into testing, tuning, and preparing standards for this module so that it could be implemented in time for this year-end activity. This goes to show that having a real deadline supported by all offices can help make things happen.
There were two other developments of a general nature that I would also like to comment on. First, there has been a recognition that many of the BASIS Core Team members do not fully understand and have not mastered use of our NSM/TARGET architecture. This is especially critical since these are the individuals actively participating in the analysis, design, testing, documentation, and training of our new systems. It is vital that all team members be proficient in the use of our basic toolset. The good news is that special classes have been conducted to address this need, and more are scheduled.
The second is that we seem to have gotten over the hump and are now able to make effective use of our DEMO environment. It just took doing it, primarily with UPS and now beginning with HRLY-TS. DEMO is an area where our applications reside with separate versions of programs and data. It is to be used for user testing of applications and for training, or even for demonstration purposes. Its independence from TEST makes it much easier for Computing Services to proceed with program changes and enhancements while these other activities are taking place.
As reported above, this subsystem is now in production. There was a great deal of user testing, user feedback, and development activity required to accomplish this goal. At times programs were being modified and moved to DEMO twice a day. Needless to say there was a lot of communication followed by fixing, enhancing, and fine tuning. The entire team deserves credit for a job well done.
Unrelated to the components that have been implemented in production, a new approach was devised for handling proposed vendors which may be specified on a requisition, or more immediately on a Travel Authorization. A goal of this design was to have one central facility (a subprogram to be precise) handle the entry of a proposed vendor's information regardless of its source (requisitions, TAs, etc.), and a common way to process the proposed vendor into a real vendor. To accomplish this we now have a Proposed-Vendor file, the subprogram to accept and validate proposed vendor information, a list function to display the proposed vendors, and a proposed vendor processing function that interfaces with the name search and vendor maintenance functions. These components will be used and implemented with the Travel subsystem.
The Travel Authorization function continues to be the main focus of development activity. The current version looks very little like the one that existed at the beginning of this reporting period. It has been overhauled
Remaining development tasks include adding further validations and special processes to the TA function, writing all travel advance processing functions, writing travel claim and travel invoice functions, and developing interfaces with MSA including transactions to represent the encumbrances at end-of-month.
There has been a great deal of development activity in this application. Practically all existing functions were modified and enhanced and many new ones written. The SUHE (setup hourly employee, renamed from SUNE) and BLOC functions were modified to work with the Employee file and the data captured from the I9DF and W4 functions. The Wage Rate and Update Wage Rate functions now automatically update employee attributes such as hire date, termination date, and date of I9. The time entry functions now work with the Employee file and use the Company Cost Center distribution change window. Edits were added to the W4 function. Security by value was added to all necessary functions. New functions include three TARGET transaction lists; an hourly information change function that generates TARGET transactions for Human Resources approval; a function for maintaining the MSA Level 2 thru 5 codes; a special control function for changing SSNs, MSA Level 2, and flagging Emp-IDs as duplicates; a list showing where all time has been reported for an employee for a week (to see why an employee might be in an overtime situation); a function to set the new optional sub-group code that will permit a budgetary unit's list of employees to be sorted by sub-group; and a debugging function that displays all Employee file elements. The list of SSNs that defines our test population was also provided by Human Resources and was used to convert those employees from MSA with their SSNs being scrambled during the process. Except for one or two functions this has all been moved and set up on DEMO where it is available for user testing.
Remaining development activities include the following.
Development activity for this period has focused exclusively on the program to load the post payroll MSA data (which includes MSA's Company Cost Center distribution) to the new Labor Distribution file. This task was more challenging than anticipated, but appears to be near completion. In addressing it, several issues were raised involving how to handle special types of activity and how this activity would be accounted for in the General Ledger Interface (a major component that will have to be added to this same program). This forced us to document and review the accounting entries to be generated and, as a result, we have been able to resolve most outstanding issues. The items we are still uncertain about are how to account for the proportion of fringe benefits attributable to County earnings and whether there remains a need for COEX to charge back actual fringe benefits versus a percentage.
Remaining development activities include the following.
The LEAVE system has been very stable. There has been some discussion of system changes to better account for Family Leave, but the decision has been made to defer doing anything at this time. We have continued to provide occasional support to COEX in their testing of the LEAVE system. As soon as all pieces of the HRLY-TS application are in place we will begin efforts to change the LEAVE system to use the Employee file, restrict leave reporting there for hourly appointed, restrict Extra Time reporting to only appointed employees and integrate it with the HRLY-TS data, and make the necessary changes for COEX.
GJIM activity included implementation in production of the Company Cost Center Reviewers (CCCR) command and the HELP command that includes a help topic related to TARGET routing of GJIM transactions. Some work has been completed on changing Journal Entry Maintenance (JEM) to not require a document total and instead move this validation to the point of document submission (JETP). This change will make it easier to enter documents with a large number of lines by allowing the user to periodically save what has been entered prior to the complete entry of the document. This modification should be completed and ready for testing soon.
There has been no activity involving this application.
The modification of the User Notice facility to include the comment associated with a TARGET transaction rejection has been implemented in production. Further tweaking of the batch processes to print TARGET transactions was also completed. Now we need to figure out exactly how and where we want to use these routines. A new criteria type was also defined for Travel and review criteria maintenance routines developed to support specification by Budgetary Unit and In state versus Out of state types of travel.
We still have plans to implement changes in TARGET processing to retain the "old" values that exist at the time a transaction is created. This will require modification of these program models, regeneration of all TARGET functions, and some special coding in a few situations. It will also mean that the LEAVE MB function will work slightly differently when viewing non-pending transactions. These modifications, planned for completion previously, should be in place by the end of the year.
Minor fixes were applied to three NSM-MS list commands and to the LOGON program. Computing Services also participated in the review of some documentation Joe Fournier prepared for application owners' use of NSM-MS.
Please feel free to raise any questions or concerns prompted by this report.