BASIS Steering Committee
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.
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.
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.
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.
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.
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.
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:
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.
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.
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).
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.
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.