Table of Contents

  • Leave Accounting (LEAVE)
  • General Journal Interface Module (GJIM)
  • Personal Services Budget (PSB)
  • University Procurement System (UPS)
  • Hourly Time Sheets (HRLY-TS)
  • Travel Authorizations
  • Labor Distribution
  • NSM/Program Generator



    BASIS Steering committee
    Gene Buckley, Dick Cottrill, Tom Dorre, David Whitmire, David Martinson, and Bob Zimmerman


    W. David Wimberly


    Bill Moody, Colleen Briney, David Keith, and Bill Overby
    BASIS-L discussion lists


    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.

    Leave Accounting (LEAVE)

    Coding and testing of both enhancements and fixes to LEAVE continued through May. These activities and the status of each follows.

    1. A fix to the problem of using WKLV and skipping a week with a holiday has been coded and is being tested by Human Resources.

    2. The special exception of charging an employee's vacation balance instead of comp time when the vacation balance exceeds 240 hours has been corrected and tested. It has not been moved to production pending acceptance of other changes currently in test.

    3. The monthly synchronization program has been corrected so that all new employees are now pulled from MSA into the Leave system. This modification was tested, accepted, and has been placed in production.

    4. The Average Monthly Leave report was changed so that 'Comp Time Used' excludes any holiday charges. This modification was tested, accepted, and has been placed in production.

    5. The Budgetary Units Without Leave report was modified to sort employees by name. This change has also been accepted and placed in production.

    6. The FHAC routine to force holidays after a closed leave month in which the current extra time period starts is currently being tested. It is needed by June 16 when entry to the June extra-time period will begin, since the Memorial Day holiday occurs in the prior closed month and may not have been explicitly reported for all eligible employees.

    7. A problem with some key fields not being properly restored after a suspend operation has been corrected. This required coding changes in most of the application programs. Migration to production is pending approval of other changes.

    8. Leave usage totals were not being properly updated when multiple leave reasons were added for a day using WKLV or EXTM, and the new reasons caused the old reason to be sorted to a different position (1, 2 or 3 reasons are permitted per day). A correction has been applied to these programs and is currently being tested by Human Resources.

    9. A problem was discovered whereby if EXTM was accessed in a particular manner with an effective date not defined by the online calendar, the program terminated with an error condition. A fix for this problem was coded, but testing revealed that it caused other problems. Further coding and testing are underway.

    10. Yet another problem with EXTM and alternate holidays has emerged. We have found that EXTM updated the 'Leave Reported Thru Date' to be the end of the month even though the extra time period ended prior to that date. This creates a problem in May since the extra time period ends before the end of month (May 28) and a subsequent date is a holiday (May 30). The result is that the system will never default the May 30 holiday for the employee and assumes the employee worked that day, thus earning 8 hours of comp time. A correction is being made so that the 'Leave Reported Thru Date' will never be updated by EXTM beyond the end of the extra-time period. Additionally, a report has been written to identify the employees affected so that HR can update them on MNLV replacing their holiday and correcting their balances.

    11. An online batch job submission facility has been developed for LEAVE, although it has not yet been turned over to HR for testing. The only on-request, report-only batch job currently needing this facility is an edit program that aggregates the detail usage data and compares it to the stored usage totals. Other needs, possibly including departmentally initiated batch jobs, are expected to emerge.
    We hope to wrap up all the above open issues during June. In addition:

    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.

    General Journal Interface Module (GJIM)

    There were several changes and enhancements made to GJIM during May:

    1. A slight modification was made in the way commands that occur in lists are processed so that GJIM would be consistent with other BASIS applications.

    2. A new data base index was created to allow listing JE type documents by the fund explosion rule placed on those documents. This required modifying the JEM and LDJE (batch JE load facility) programs to generate the necessary values for the index, development of the new list (LJED), and development and execution of a conversion program to generate the necessary index values for existing JE documents.

    3. A generic production batch update job was implemented to provide a means of executing conversion or data correction programs as noted above.

    4. The action and messages related to NextR (PF8, next record) processing were made consistent across documents.

    5. Documentation on the function and use of the batch JE load facility was prepared.

    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).

    Personal Services Budget (PSB)

    There was no activity during April on this application.

    University Procurement System (UPS)

    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.

    Hourly Time Sheets (HRLY-TS)

    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.

    Travel Authorizations

    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.

    These appear to be good reasons to place employee travelers on our BASIS vendor file, and does not preclude our validating that the employee is defined on payroll.

    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.

    Labor Distribution

    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.

    NSM/Program Generator

    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.