BASIS Steering committee
W. David Wimberly
Bill Moody, Colleen Briney, David Keith, and Bill Overby
Computing Services BASIS May Status
Progress during May included maintenance type activities in LEAVE and GJIM, key decisions being made regarding hourly time sheet processing, the start of analysis on the BASIS Labor Distribution module, investigation of methods to address additional requirements related to Travel, and further review and input on BASIS documentation.
Regarding documentation, Computing Services has concluded that the course materials, user's guides, and online help text which are being developed will not be adequate reference materials for the support and maintenance of the BASIS applications. Although we regret having to develop even more documentation since it takes time from other development activities, there is a need for specific and concise documentation on any unique or non-standard aspects of an application, the basic components of a system, and the design concepts employed. We do not plan to include or re-document standard features, functions, and operations common to all BASIS applications. We hope that our documentation (which we are considering calling a System Manual) can be developed during the analysis of system requirements, and that it will facilitate communication within the core groups during and after the system development.
Coding and testing of both enhancements and fixes to LEAVE continued through May. These activities and the status of each follows.
COOP has completed entry of their January test data and is awaiting our approval and stabilization of the test system to enter February test data.
There were several changes and enhancements made to GJIM during May:
During June we will provide whatever production support is required for GJIM, begin preparing our System Manual for this application, and develop facilities for loading Journal Entry documents from an external source (probably a CMS ID).
There was no activity during April on this application.
Alternatives for the placement of vendor data on various screens/maintenance functions were considered in May and some prototypes were developed. Additional input is necessary to know which elements need segregation for security purposes (these are management decisions related to who will be permitted to create vendors or change vendor names). This must then be balanced with ease of use factors, our software capabilities, and the specific data requirements (like 7 possible names for each vendor). We are very eager to get David Keith up to speed on our architecture, standards, user requirements, and design work done so far in order to assist us and provide Business Affairs involvement. We plan to use our BASIS Vendor file to support the TRAVEL application, so there is an immediate need to finalize decisions in this area.
The LVCI (List Vendors by Commodity class Item) program was generated with a new option of the program generator which was not available when this routine was originally written. The generated program had to be broken previously, which prevented regeneration. This is no longer the case, and as features are added to our list models they can now be easily incorporated to this program.
The Steering Committee decided that no paper work (I9, Drug Free statement, or W4) will be required to be in Human Resources prior to the entry of a wage rate or hourly time for an employee. The system implication is that the departments will need an online facility to designate the setup of a new employee. The wage rate and hourly time sheet entry process will then need to validate an employee (SSN) against the existing Payroll records or the pending new employee setups. Exactly what data will be required on the setup has not been decided. We have determined that the best procedure for keeping the systems synchronized is for HR to also use this BASIS new employee setup so that all new employees are processed in the same manner. This further implies that W4 information be entered to BASIS by HR as a supplement for a new employee setup or as an update for an existing employee, and that all data be extracted and loaded to MSA on a scheduled basis. Consideration of required elements, screen design, and interfaces are in process.
The Steering Committee also questioned system requirements related to work study: whether time sheets had to be retained in Financial Aid, whether departments rather than Financial Aid should enter time for work study employees, and whether time had to be reported via a special process accommodating time in/time out entry. The stated goal was to get work study paid on the same schedule as other hourly employees and establish one procedure for use by departments to report hourly time.
A method for approving hourly time needs to be established. The approval of an entire budgetary unit's hourly time, as done for overtime, is one model. The fact that this does not provide time sheet approval by the individuals responsible for the cost centers to which the time is being charged has been raised once again as an issue. This must be settled in order for us to move forward.
An extremely complex situation has been defined involving appointed employees being paid hourly who are over the FICA maximum. Due to the manner taxes and deductions are handled within MSA, special transactions are required with each hourly payroll to override on a one time basis all the employee's normal deductions and code their pay transaction differently. This is obviously a very labor intensive process as it is currently handled. Further discussion of how BASIS might alleviate some of this problem will be held.
We have continued to meet with Donna Carter to work out the details related to the proposed Travel system. The latest snag is the need, on an occasional basis, for more than two travel related requisitions to accompany a Travel Authorization request. This is an issue because of limitations in the amount of data we can carry as part of a single transaction. Two associated requisitions seemed very doable, while 4 or 5 is pushing the limits considering names, addresses, descriptions, and other necessary data. There are alternatives. The travel related requisitions could be entered individually and maintained in an open status until attached to a Travel Authorization for approval (this resembles the GJIM model where documents are created in one process and submitted for approval in another). Another possibility is to permit only two travel related requisitions with the original Travel Authorization and require that any additional requisitions be handled as a supplement to the original TA. This would not be required for most travel, but when needed the original TA would be misleading because it excludes the additional information which would follow as a supplemental authorization. These choices appear to be less appealing than dealing with the entire travel request as one process. We are continuing to analyze these alternatives in order to formulate a recommendation.
Another issue we have gone back and forth on is whether to set employees up as vendors. On the one hand this seems redundant since the necessary employee information should be contained in the payroll system. However, that is not always the case.
In spite of these open issues, we have updated our data dictionary definitions, the screens, and the system overview and still plan to present a recommended approach for travel processing.
This project is now officially underway. A core group of concerned parties has been formed and two meetings have been held. The objectives have been discussed, existing reports and outputs have been identified, and many issues have emerged. More discussions are required before this area can be fully understood and a system approach developed. It is evident that there is a great deal of potential for labor savings in this area due to the lengthy and detailed nature of current adjustment processing procedures.
Changes previously completed to segregate data updated by Computing Services from data updated by the TARGET administrator were implemented in production during May. This included the new commands for Default Review Group (DRG) and Transaction User Parameters (TUP) as well as new menu structures. The following new programs were developed during May, although not all have been tested by the users:
Other miscellaneous "To Dos" for TARGET include long term transaction management (archiving, purging, and printing), investigation of an e-mail facility, and an update to Computing Services' documentation.
A solution was developed for the problem where some "banner key fields" were not properly restored after suspending to another function. This problem only existed for fields where we permit various input formats, such as dates. In conjunction with making the necessary corrections to programs and program models, we updated our documentation regarding the proper handling of these fields.
One "desk management" training class was conducted during May. There has not been adequate demand to schedule another class, although there are still many departments without a desk administrator appointed. For desk-based security and TARGET routing to be successful, we need most departments performing the desk management function.
An additional online list function is planned to identify the desk administrator(s) for a selected budgetary unit. We hope to develop this function during June.
Please feel free to raise any questions or concerns prompted by this report.