Table of Contents

  • Common



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


    W. David Wimberly


    Bill Moody, Colleen Briney, Bill Overby and William Rains
    BASIS-L discussion lists


    BASIS June status

    The initial coding of the basic functions of the Leave Accounting System and the General Journal Interface Module are near completion. This does not include TARGET functions, the general text manager, or user-requested changes that are expected as a result of further testing. Even though there is significant development work still remaining, the focus of attention for the core teams is becoming one of testing and implementation. Detailed plans for these have not yet been published, but it appears that an August 1 implementation of GJIM is unrealistic as was a June implementation of Leave. A reassessment of our schedules and a redefinition of our objectives is needed for the following reasons:

    Related to documentation, the Computing Services team members have developed new guidelines for the development of documentation for specific functions (commands) within the systems. Each analyst is preparing documentation for one of the functions he or she developed as a sample. This effort was initiated because of past complaints about Computing Services' documentation and writing styles, the desire of Computing Services to develop and maintain one set of comprehensive documentation for each system, the availability of current tools to make this documentation available as online help within the applications, the anticipation that Computing Services would be developing the online documentation due to their knowledge of the applications and availability of resources, and the realization that the development of complete system documentation will be a massive effort that could delay system implementation if not completed. Subsequently we have been advised that the Training Coordinator will be assigned the responsibility of determining documentation standards for BASIS and may also develop that documentation. We will plan to make our work available as input for that individual.



    The Leave Accounting system has stabilized and many features and components were added during June.

    1. Weekly and monthly leave reporting functions have been working flawlessly.
    2. We have added the ability to simulate different system dates so that we can arbitrarily alter the testing periods.
    3. The logic and routines to prorate leave for new hires and terminations was developed.
    4. Vast improvements were made to the monthly balance function so that the information displayed could be more easily understood.
    5. Routines were written to generate the MSA transactions necessary to place vacation and sick leave balances on check stubs and to load overtime payment transactions.
    6. Documentation for monthly leave processing and the monthly balance function was prepared and is being reviewed internally within Computing Services.
    7. A tremendous amount of time was spent on the extra time maintenance function. It will be used to enter detailed time records so that comp time and overtime can be calculated. It is easily the most complex routine we have tackled due to the fact that it must also deal with leave data which may occur in both the previous and the future month (since some extra time periods have 5 weeks). This module is currently in unit testing and will shortly be turned over to the core team for their testing.
    8. An employee name search facility was developed and implemented to provide a means of finding an employee's SSN when it is not known.
    9. All online maintenance functions were updated and regenerated to remain compatible with the latest changes made to the program generator.
    In addition, we feel we have worked out the details for handling nine month employees when they are inactive during the summer and defined how catastrophic leave will be processed (both contributions to the pool and granting of leave from the pool).

    The primary development tasks remaining include a facility to track catastrophic leave activity (currently under development), a routine to synchronize the personnel information maintained in the Leave System with that in MSA, the addition of TARGET functions for approving overtime and leave adjustments, and the definition as well as development of necessary reports.

    Major issues

    The first item of this list from last month's report has been removed. Tom Dorre has indicated that due to the small number of individuals that go on catastrophic leave, we should not attempt to automate the transfer of their vacation and sick leave accruals back to the catastrophic leave pool. Instead, these transfers should be processed manually (facilities are available to do so). I strongly agree with this opinion and think we should look for other areas where we may be trying to "kill a fly with a sledge hammer". All other items on this list remain unchanged and relate to subsequent modules of BASIS I which are not currently being addressed.

    1. Determine the requirements and methods to be used for defining, storing, and applying the Company/Cost Center distributions for use in charging out salary expenses.

    2. Develop a means for performing available funds checking for salary/budget activity and for projecting future salary expenses.

    3. Understand and define the specifics regarding summer school budgeting and summer teaching appointments.

    4. Determine how to accommodate extra compensation and overloads.

    5. Define any security by value requirements, outside of leave accounting.


    See the schedule provided at the end of this report.



    Almost all of the BASIS II development activity for June dealt with the General Journal Interface Module.

    1. All maintenance functions were renamed to correspond with the two character prefix that will be used to identify those transactions within the source document ID within General ledger. These are:
      ACAccount Changes
      IIInterdepartmental Invoices
      ETExpenditure Transfers
      JEJournal Entries
      FTFunds Transfers

    2. The first four of the above functions were available for testing through most of June and have been undergoing change based upon user feedback. Modifications included the alteration of screen formats for consistency, the addition of special entry options for cost centers and amounts, the creation of standard field validations across functions, and the use of common decode processing logic. The criteria to be used to determine who should approve these transactions within TARGET were also reviewed and these functions were updated and regenerated to remain compatible with the latest changes made to the program generator.

    3. The Funds Transfer function is proving to be more complex than other GJIM functions and the definition of its requirements evolved throughout the month. This was due to the following issues:

    4. Three list functions were developed that allow browsing GJIM transactions based upon various criteria.

    5. The decision was made to use a calendar maintained within the system to determine when GL periods are open for posting and a maintenance function for this control data was developed.

    6. Documentation for expenditure transfers and journal entries was prepared and is being reviewed internally within Computing Services.

    The primary development tasks remaining include some file and dictionary definition changes for new and renamed elements, three additional list facilities, routines to extract and format GJIM transactions for MSA, a generalized text management facility, the addition of TARGET functions for submitting for approval and reviewing GJIM transactions, and the definition as well as development of any needed reports (hopefully none).

    Purchasing representatives provided feedback based on their testing of the vendor maintenance system. These suggestions have been discussed resulting in some changes already being implemented, agreements made to implement many others, agreements made to not implement some, and a need recognized to investigate the impact and feasibility of the rest. Response to these items may not be timely since this is now a secondary priority to the completion and implementation of GJIM. Additionally, UPS programs need to be upgraded and regenerated to incorporate new features of our program generator.

    Major issues

    All items listed are unchanged from last month's report.

    1. Time is needed for the design and development of a general purpose facility to provide word processing-like capabilities for requisition, purchase order, and general journal descriptions.

    2. Consensus needs to be reached regarding inter-departmental order processing.

    3. A method of identifying and reporting federal expenditures by the period of the obligation needs to be identified.

    4. The requirements of the system remain chock full of exceptions and special handling requirements. We hope we can document all of them and develop a system that takes them into consideration.

    5. There is a need to replace or interface with various inventory systems. The areas that have a possible interest in such a facility include: Scientific Supplies, Dining Services, Physical Plant and Cooperative Extension Service.


    See the schedule provided at the end of this report.



    The significant changes that had been completed to the program generator maintenance functions were implemented during June. A detailed step by step set of instructions was prepared to identify all updates that were required to existing programs and these instructions were tested out on the NSM Maintenance System. Kathryn then assisted where necessary in upgrading GJIM, LEAVE, PSB, and TARGET. Only the UPS application remains to have the necessary changes made and the programs regenerated.

    Attempts were made to simplify the use and understanding of the Natural User Profile. This included some minor modifications to the program and some reworking of the documentation. It appears this will need to be a "power user" tool due to the number of options, requisite understanding of 3270 field types, and variety of 3270 terminal emulators in use campus wide.

    The TARGET routine to establish the list of reviewers for a transaction was modified during June and the routine to update the list based upon a review action was written. The maintenance routine for a "DEMO" review criteria was developed and documentation for the proxy maintenance function was written.

    We have initiated the development effort associated with the conversion to desk based security. Necessary data base file changes have been identified and implemented on a test file, conversion requirements have been identified and most of these programs have been developed, a list of arbitrary desk IDs to be assigned during conversion has been developed (we have chosen names from mythology and geography rather than numbers), routines are in development to identify currently active IDs so that desks need not be assigned to IDs that are not in use within Natural, and routines are in development to validate users as active and to update their current organizational assignment (to be executed monthly). Additional activities that will be required include:


    See the attached schedule for detail information.

    Please feel free to raise any questions or concerns prompted by this report.