MEMORANDUM


Table of Contents

MEMORANDUM
  • BASIS I
  • BASIS II
  • Common

  • MEMORANDUM

    To:

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

    From:

    W. David Wimberly

    Copy:

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

    Subject:

    BASIS July status

    Pieces of the BASIS puzzle are beginning to fall into place. The support facilities for "desk" based security are now complete and a basic TARGET processing function has been developed and is being tested within Computing Services. Best of all, Joe Fournier has now been hired as the project Training Coordinator. These developments along with the operational (not quite 100% complete) Leave, GJIM, and TARGET Administration systems mean it is time to get serious about planning for implementation. In fact, Computing Services is making plans to start the analysis for the next modules. I recommend hourly time sheet processing and travel authorizations for our phase 2 projects.

    BASIS I

    Progress

    More functions and features have been added to the Leave Accounting system.

    1. The extra time maintenance function, EXTM, was completed and released for user testing. It is used to enter detailed time records from which comp time and overtime are calculated.
    2. The catastrophic leave function, CATL, was completed. This routine will be used by the Leave Administrator to record and process donations to the catastrophic leave pool and to grant catastrophic leave.
    3. Three online list facilities have been developed, all dealing with overtime.
      LOCC List overtime for a company cost center
      LOBU List overtime for a budgetary unit
      LORC List overtime involving a rate change
    4. The "10 day leave without pay" rule was added (employees with more than 10 days leave without pay in a month do not accrue vacation or sick leave).
    5. Sample online documentation for MNLV and MB has been loaded to the data dictionary and is available from those functions.

    The development of a monthly batch job to synchronize data in the Leave system with that in MSA Payroll is in process. The only other system development tasks are programming 3 to 4 loosely defined reports and the addition of TARGET functions for approving overtime and leave adjustments.

    Major issues

    I have decided to modify this section to only identify issues related to modules actively being addressed by the project team. Items previously reported have been removed since they were not related to Leave Accounting.

    1. Confidentiality of an employee's SSN has been emphasized again. The system currently uses SSN as the primary key to select a person for processing and to synchronize data with the MSA Payroll. Suppressing the display of the SSN would be possible, but would require significant re-development effort at this time. It may also prove operationally cumbersome since the identification of an employee to process would always have to be made by selection from a list.

    2. The system is very near completion and yet there are no plans for an acceptance test, user documentation, user training, nor implementation. A re-evaluation of responsibility for these tasks or a re-commitment to them seems appropriate.

    Plans

    See the schedule provided at the end of this report.

    BASIS II

    Progress

    BASIS II development activity during July dealt with the General Journal Interface Module. GJIM updates and enhancements included:

    1. The development of a prototype list function which included the command ID within the list so that when an entry is selected, the command to process the entry is also provided. This concept has now been incorporated into the program generator as an option for all lists and the appropriate GJIM lists have been regenerated to use it. This is really slick when used with the suspend feature.

    2. The Journal Entry function (JE) received a face lift. This function, to be used almost exclusively by Financial Affairs, was redesigned for high volume data entry. The number of entries per screen was increased from 4 to 12 with most all descriptions removed. The descriptions are now available via a De-Code window which is displayed upon request.

    3. All functions were updated to work with changes made to the data base: Budgetary Unit replaced Department, Department Representative replaced Department Bookkeeper, elements were added to accommodate the interface with the BUDGET System, and one index was redefined to use effective date rather than entry number.

    4. The requirement for and display of document totals was made consistent across functions.

    5. The MSA Explosion Master file was defined to Natural and is now used to validate the "User Codes" entered on JE.

    6. One of the list functions was re-developed to use the altered data base index and two new list functions were written. All lists were re-generated to incorporate the new feature of indicating what entries from the list were processed by protecting the mark field preceding the entry.

    7. Routines to perform format edits and allow alternate formats on fields such as dates were modified to not require a valid entry when the user presses PF3 or enters the FIN or LOG commands.

    8. Sample online documentation for expenditure transfers and journal entries has been loaded to Predict and is available via these functions.

    The Funds Transfer function is continuing to prove that it is the most complex of the GJIM processes. Many of the reasons for this were included in last month's report. After getting a basic function operational, we have decided to take a new approach in order to simplify the program and make it more efficient. We are in the process of re-developing it with a slightly altered design and expect it to be available for user testing in early August.

    During July we also summarized and documented feedback we had received near the end of June on UPS.

    The primary development tasks remaining for GJIM include a routine to extract and format transactions for MSA, a generalized text management facility, and the addition of TARGET functions for the submission for approval and review of GJIM transactions.

    Major issues

    This section has been modified to only identify issues related to modules actively being addressed by the project team. The first item remains from last month's report since it involves GJIM, other items from last month's report have been removed, and item 2 is new to this 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 GJIM transaction descriptions (explanations).

    2. The system is very near completion and yet there are no plans for an acceptance test, user documentation, user training, nor implementation. A re-evaluation of responsibility for these tasks or a re-commitment to them seems appropriate.

    Plans

    See the schedule provided at the end of this report.

    Common

    Progress

    Changes were made within our program generator to provide new features or incorporate changes:

    1. All four list models were altered to accommodate the presence of a command ID within the list. When this feature is used, the command ID is selected along with other data and that command may be automatically invoked by pressing PF2. On the other hand, if a command is explicitly specified that command will override the one from the list. The inclusion of this feature is optional, lists can be generated without including the command ID in the list.
    2. All four list models were altered so they indicate what items from the list were selected and processed. This is done by protecting and making non-display the mark field used for selection, which is very effective when these fields are otherwise displayed in reverse video.
    3. On all the maintenance program models, the use of PF8 for next record processing has been removed whenever an add action is being performed.

    A great deal of work has been accomplished in the transition to desk based security.

    1. Conversion programs were written and tested to create desks for current active users and to switch current NSM security definitions from users to the new desks.
    2. The NSM Maintenance System was overhauled to accommodate desk definitions, assignment of desks to users, assignment of applications to desks, identification of application ownership by desk, and the incorporation of security by value so that departments can directly manage their own desks. Several new list facilities were also developed to allow browsing the new data.
    3. The primary support routine for enforcing security within NSM v2 applications was modified and tested.
    4. A function was developed to allow a user to switch between two desks for situations where a user has been assigned two desks on an interim basis.

    Remaining development activities for the conversion to "desks " include modification of the NSM v1 support routines and the updating of utilities and applications that are impacted by data base changes that are being made to support this transition. Once all testing has been completed, plans for implementing desk based security will be developed and a conversion date set.

    TARGET processing is finally demonstrable. A demo TARGET transaction is now functioning along with the following support facilities:

    1. A function that allows an individual to assume review responsibility for another desk, if that desk has provided that authority via proxy.
    2. A list facility for displaying the transactions that are pending review by a desk. Transactions can be selected from this list and the appropriate transaction processing command invoked. In this manner, a reviewer can selectively review and approve or disapprove transactions. (The normal review process displays transactions in the chronological order in which they were entered.)
    3. A list facility for displaying the transactions that have been entered by requestor, by status, by date. This allows a reviewer to follow up on transactions that have been submitted but not approved or to browse transactions previously processed.
    4. Facilities for listing comments that have been entered for a transaction and for the creation of new comments. This is essentially the "yellow sticky" feature.

    Plans

    See the attached schedule for detail information.

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