September 7, 1994

Table of Contents

  • Employee ID
  • Labor Distribution
  • Travel



    BASIS Steering Committee


    David Wimberly


    BASIS changes

    The following are changes to current procedures or practices necessitated by new BASIS modules currently under development. These recommendations are from the BASIS Core teams made up of various representatives of Computing Services, Financial Affairs, Business Affairs, and Human Resources. Input and direction regarding these issues is requested.

    Employee ID

    The BASIS I team has been struggling with the issue of how to maintain confidentiality of employee SSNs when those values are used as the primary identifier for all of our employee data. With LEAVE, this was accomplished by restricting an operator's access to those employees who are assigned to budgetary units that correspond to a pre-defined set of budgetary units established for that operator. There are problems with this arrangement even in LEAVE: an operator can't view past records for an employee who has since moved to another unit. There are more serious questions and problems as we look toward new systems such as Hourly Time Sheets and Labor Distribution. In these areas electronic transactions involving specific individuals will be routed across the campus and between departments since the criteria for reviewing activity will switch to the Cost Center involved versus the location where the employee is assigned. Not displaying the employee's SSN during the processing of these transactions would be difficult since it is a primary identifier of the data. Greater problems would be presented in devising methods of browsing and selecting this data for further processing (such as initiating a retroactive change in payroll distribution) if the SSN had to be protected from view.

    The BASIS I team recommends the creation of an Employee ID for all employees. This would be a six digit number sequentially assigned starting with 100001. It would be used as the unique identifier on all employee BASIS data, and thus would appear on online screens and lists. Each employee would continue to be identified by their unique SSN, which would be retained in the system but would not be used for normal displays due to the confidentiality of that element. To facilitate processing, the system would accept either an Employee ID or an SSN as the selection criteria for data. When an SSN is entered (determined by the format of the entry), the system would access the employee record to determine the Employee ID plus provide an additional check to ensure the operator is authorized to access that employee's SSN (based upon the locations where the employee works and the pre-defined units established for access by the operator). The employee ID and name would then be displayed.

    Note: Most update access to employee information, and in some cases view access, will be restricted in a similar manner as the SSN. On the other hand, view access to most employee data, and even update access at times, is anticipated to be provided on an unrestricted basis (the SSN being the exception). The employee ID is needed in the latter situations.

    The following options were also considered and are provided here as background information.

    1. Design future systems incorporating security to restrict access to data based upon where the employee works, like the LEAVE system does. This option appears to be unduly restrictive and might actually be a major hindrance in our ability to do business using future systems. This would likely create more situations like what Tom Ruffer reported on BASIS-L, he has to communicate the overtime worked by an employee in his unit to the home office where the employee is appointed in order to have that office enter the overtime using his cost center. It might also lead to developing systems that hide the SSN (it would be used for selection and processing although the operator would never see it). This would be less efficient than the direct entry of the SSN and is rather abstract for the user since he doesn't see the identifier for the data, which might lead to training and support problems.

    2. Take a very liberal interpretation of where SSN confidentiality applies by assuming that all administrators using the system have a need to know that data, and continue to use the SSN as the primary identifier throughout our systems. This would not appear to be the intent of legal counsel's ruling on this issue (passed on by Tom Dorre in August 1993), but it does appear to be the common practice in other areas of University business (SAFARI takes no steps to keep employee SSNs confidential, the faculty/staff directory update listing is distributed with SSN on it, the Student Inquiry system provides a name search that returns SSN, and this number appears on the face of all staff IDs).

    3. Use the Personnel ID Number (PIDN) from SAFARI as the BASIS employee ID since that number has already been created for most employees. This concept seems to have a great deal of appeal since it would keep us from creating one more number to be used campus-wide. However, there are many known problems with this concept and probably many more that are unknown at this time.

      1. The SAFARI IDs for staff are currently created from an extract of MSA Payroll data using SSN as the unique identifier; if the SSN is already on SAFARI nothing is done, while a PIDN is assigned for any SSN not already on SAFARI. Basically, only the employee name, SSN, and PIDN are created for employees on SAFARI. The quality of this data is also suspect since name changes and SSN changes are not automatically synchronized between the two systems.

      2. Since BASIS will allow departments to essentially create new employees, there would have to be a means for BASIS to assign PIDNs and create the necessary employee records in SAFARI. This presents several technical problems since the SAFARI Next Number file is VSAM (as opposed to ADABAS) and SAFARI relies heavily on filters (Cobol routines linked to AMS's I/O routines) in the maintenance of its data. A further issue would be obtaining permission for BASIS to do this.

      3. SAFARI accepts massive amounts of personal data from external sources and creates PIDNs for these people. The SSN is not always available for these and when provided is frequently wrong. The discovery of people with duplicate records within SAFARI is common, requiring consolidation of records. In BASIS, each new employee will be researched by HR personnel using extensive name search facilities as well as requiring supporting documentation showing the employee's SSN. Relying on SAFARI's SSN to identify a person and derive a PIDN for HR would not seem to be appropriate given the potential for erroneous data within SAFARI and the need for high quality data in Payroll.

      4. A student is not required to provide his SSN, and so may be in SAFARI without an SSN. This same student may later become an employee, but his existing PIDN would not be located via his SSN. The result could be the creation of another PIDN for the same person.

      Note: The SSN is now and would remain the key element in crossreferencing Payroll and SAFARI data. Online facilities could be developed to facilitate this. Given a SAFARI PIDN, BASIS could be developed to accept a PIDN in addition to either the Employee ID or the SSN. The programs could identify the PIDN from its format and translate it to an SSN using SAFARI data and then to an Employee ID using BASIS data, all behind the scenes, and then display the desired employee information. Likewise, a function could be provided to display a SAFARI PIDN given an employee ID. This read only type access of SAFARI data is much simplier than cross-system updates.

    After considering these options, the BASIS I core teams have concluded that it is in the best interest of the project, the BASIS systems, and the University to create an Employee ID. Support for this recommendation is strongly encouraged, and system development is proceeding with the assumption that this recommendation is accepted.

    Labor Distribution

    The new Labor Distribution module will be very different from the current system. It will be an online data base system where departments can browse the detail associated with their payroll charges and interactively initiate requests for retroactive adjustments. In one respect there will be a great deal more detail data than is retained in the current system since individual pay records from each payroll will be retained. At the same time it will be greatly summarized since actual fringe benefits will not be maintained by person by benefit provider. Given this overall design, there are two changes from current practice for which approval by the Steering Committee is being sought.

    1. Actual Fringe Benefits

      The University policy has been, and will continue to be, to charge out to departments a set percentage of the employee's salary for fringe benefits. This percentage benefit, and not the actual benefits, are what flow into GL by Company Cost Center, and these are also the amounts moved with retroactive adjustments. The current system also maintains by employee the actual fringe benefits by benefit provider (the University's portion of TIAA/CREF separate from the University's portion of medical insurance, etc.). This is detailed and voluminous data that the University does not currently use and that we plan to no longer maintain in the new system. We do plan to summarize these actual fringe benefits by employee and retain that value for inquiry, reporting, and analysis. What will not be available is the break down of that amount by benefit provider.

    2. Retroactive Payroll Adjustments

      The online entry of retroactive payroll adjustments will be a major change for the campus community. Currently such changes are requested via the PAF by back dating the effective date on the PAF and specifying a different company cost center distribution on the form. This back dating can cover very long periods of time and thus apply to payroll charges generated over several months. It can also be effective into the future such that the single document is requesting changes in past charges (retroactive changes) and also specifying the cost center distribution to be applied on future payrolls.

      The new system will retain the specific charges generated per payroll and require that retroactive changes be specified by payroll. Where one PAF could have been used to effect a change across several payrolls in the past, the new Labor Distribution module will require that such a change be specified for each individual payroll. Given this situation, however, the online 'copy' action can be used to carry forward the desired distribution so that reentry is not required. In conjunction, since retroactive changes will be requested for specific payrolls already executed, changes in future payroll distributions will continue to be processed via the PAF paper process.


    The following policy or procedural changes are being requested to support the implementation of the Travel module of BASIS. Acceptance and support for the following items by the BASIS Steering Committee is requested.

    1. Travel Advance Policy

      A trimmed down and streamlined travel advance procedure is envisioned for those situations where adequate lead time is provided. It will start with the request for a travel advance being included as part of the electronic Travel Authorization. Once the authorization is approved and other minimum qualifications met, the travel advance check will be automatically generated and mailed to the traveler. The traveler will not have to make a special trip to the Treasurer's Office and administrative personnel will not have to perform the special processing currently required for each travel advance.

      Note: Travel advances required on short notice will be processed in the same manner as other advances. These may require the Treasurer's Office to initiate a special run to generate advance checks, but all advances approved up to that point will be produced and available for distribution. This need should be negligible since there will be set times each day when travel advance checks are produced.

      Two issues related to this new process are deemed significant enough to require management support:

      1. Travel advance checks cannot be mailed to the traveler if a written Travel Advance Agreement is required for each advance. Rather, we propose that an agreement to pay back all travel advances be obtained so that subsequent promissory notes are not required.

      2. Numerous limitations and restrictions are applied to allowable travel expenses and associated advances. To simplify the process and programming for determining an acceptable amount to advance for meals, a simple rule needs to be established. We propose that advances for meals be fixed at $20 per day for in-state travel and $26 per day for out-of-state travel, and always based on a full day's allowance.

        travel, where one authorization is established to cover many trips. These are normally frequent and occur in-state, but exceptions are made. The current practice requires an advance for each trip, which is deducted from the claim for the same trip. The frequent traveler is placed in the position of requesting and receiving frequent travel advances, all for the same travel authorization. This procedure is not to the traveler's benefit nor to the University's.

      3. We request that an advance granted for a blanket travel authorization be treated as a "long term advance", not to be settled until the final claim is submitted for that travel authorization. This advance would be requested, as would other advances, on the Travel Authorization request, and thus the amount would be subject to management approval. It would remain in the hands of the traveler as multiple trips are taken and claims for those trips are submitted and reimbursed. In fact, it would offer an incentive for the traveler to submit his claims in a timely manner. Special restrictions could be imposed such as limiting the advance amount and requiring that all blanket travel authorizations be settled and closed at year end. If this type advance was not desired for a specific trip, a normal travel authorization and advance could be requested.

        An alternative, given the concept of the long term advance is not acceptable, is to no longer provide travel advances for blanket authorizations. It must be recognized that this has the potential to increase the total number of travel authorizations since trips where an advance is needed would involve a new authorization versus use of the blanket. However, it might also be appropriate that trips requiring such a level of expenditure be requested and processed separately and should not be made under blanket authorizations.

        Both of these recommendations are made in order to avoid providing multiple travel advances for a blanket authorization, as is the current practice. The processing and record keeping to support multiple advances will be difficult and they require additional personnel resources to administer. The amounts involved are normally small, there are a high number of these advances currently, and there will continue to be the alternative of obtaining a specific Travel Authorization for a trip where an advance is required.

    2. Travel Advance Fund

      Many special manual and automated steps are required to maintain the separate travel advance fund. A separate bank account is required with it's own check stock, PC programs are used to record disbursements and print checks in the Treasurer's Office, and this account requires its own check reconciliation. These are all duplicate steps that are either performed currently in Accounts Payable or will be part of the BASIS Travel module. Further, employee reimbursement checks for which an advance was obtained are written for the entire travel amount and have to be intercepted, deposited into the Travel Advance Fund, and a new check written to the employee from the Travel Advance Fund for the amount owed.

      We propose that the Travel Advance Fund be moved to a Travel Advance Cost Center, that the travel advance bank account be eliminated, that a separate AP check number series be used for advance checks, that travel advance checks be generated by BASIS, that "manual check" type invoices be generated by BASIS for MSA, that, when a claim is processed that exceeds the amount of the advance, the employee's reimbursement invoice be generated with a negative line to replenish the travel advance cost center and the employee's travel reimbursement check be generated for only the amount owed, that, when the advance exceeds the amount of the claim, accounting entries be generated to establish the overpayment as a receivable and charge the departments center(s) for the trip, and that BASIS provide the reporting and audit information necessary for the management of the travel advance cost center.

      Considerations for implementing these changes include our authorization for the Travel Advance Fund and changes in the expenditure data reported via the voucher process to the state when certain changes are made regarding the trip plans between the time of the advance and the claim (including cancellation of trip plans and advances that exceed reimbursement claims).

    3. Travel Purchase Orders in MSA

      The BASIS Travel module will maintain information on Travel Authorizations and their travel related purchase orders (typically for airline tickets and conference registrations). Part of this BASIS information includes the manner to distribute charges for these expenses. BASIS will also provide for the entry and recording of the expense claims and potentially the invoices for travel related purchases. Given this information, BASIS can feed MSA with the appropriate invoice information to have reimbursement checks written and travel related vendor checks written. However, it is only practical to do this if there are no POs in MSA that require referencing by these invoices. Although the PO information is known in BASIS and could also be feed to MSA, it is anticipated that it will be changing due to such actions as supplements and distribution changes. Keeping both systems synchronized would be difficult. Furthermore, MSA does not provide a reasonable facility for distributing an expense across many cost centers, which makes referencing a PO that was set up differently than the distribution desired at invoice time especially difficult.

      We request that Travel Authorizations and travel related purchase orders not be defined as Purchase Orders within the MSA system, and that payments for these items be entered into BASIS and fed to the MSA AP system as direct payments. In order to provide complete information on encumbrances and open orders, the following additional steps will be taken.

    4. MICR Check Printer

      Attached is a short report and analysis developed in November 1992 regarding the use of a laser/MICR printer for the production of checks at the University. Use of such a printer is highly recommended for the BASIS Accounts Payable system so that check numbers can be assigned by the system prior to their being physically printed, to aid in voucher processing and the disbursing function. The BASIS AP system is not yet in development, but this same technology would be of value in the production of travel advance checks, and would give us the opportunity to become familiar with this technology in a low volume application.

      We request that funding be identified and steps be initiated to acquire a MICR/laser printer for the production of BASIS checks, and potentially for use in the production of MSA checks.