FIS BULLETIN Number 5

Announcements | Calendar | Status | T&T-Q&A | Training | Inside Peek | Odds & Ends

February 5, 1997

IMPORTANT ANNOUNCEMENTS

GENERAL:

USERS WITH PROBLEMS RUNNING FGIBDST: FIS/Banner Macintosh users experiencing problems running FGIBDST (starts on its own and returns strange results) should read the Questions and Answers section for a possible solution to the problem.

BANNER UPGRADE ISSUES: If you only read one "Insider’s Peek at FIS" in your Banner existence, please read this one.

ACQUISITIONS:

BUG FIX ALERT: FPAPOAS - PURCHASE ORDER ASSIGNMENT: Since the installation of the upgrades, a new bug has been discovered in the Purchase Order Assignment form. Described below is how the form currently works, and how the form will work once the fix is implemented sometime in the next week.

How the form currently works:
1) user enters form FPAPOAS
2) navigates to the "Purchase Order Number" field
3) user types in a number or 'NEXT' for assignment, hits commit (cursor remains in the PO Number field)
4) user determines first number was in error, enters a new number and hits commit for the second time. (Don't test this yourselves!)

When this happens two purchase orders are created. The first purchase order looks like it retains the link to the requisition but really doesn't. The second purchase order shows that it was not created from a requisition, but it really holds the true link. Furthermore, the first purchase order can not be completed or deleted through the form. User keeps receiving the error message: "Transaction date must be equal to or greater than original reqn trans date" (which makes no sense whatsoever).

We have come up with a bug fix that should be implemented within the next week. How the form will work (after the fix is in place):
When user types in the second number and hit's commit, the following message is displayed:
"Item already assigned to P#######. Exit Screen and do not Commit Changes." (where P####### equals the first po number entered) and user will be asked to acknowledge message.

This will stop anyone from accidently creating the second purchase order. Users must exit the form without saving changes and re-enter to continue processing.

If you have questions or you currently have purchase orders that you can not delete due to this problem, please contact Karsen Jones (kjones@cats).

BANNER REPORTS:

NEW MONTHLY REPORT: FZRINOF - ORGANIZATION/FUND EXPENDITURES WITH NO BUDGET": The FZINOF report is a monthly report that we plan to distribute on a regular basis beginning with the February 28, 1997 monthly reports. If your service center’s FZRINOF report does not exceed 20 pages, it will print on your service center’s printer at about the same time of the month that the ledgers are printed. To avoid unnecessarily tying up your service center’s printer, particularly if it is slow, FZRINOF reports exceeding 20 pages will be printed at CATS and will be distributed to you via campus mail.

The FZRINOF report was originally produced as a fiscal closing report designed to assist service centers in uncovering transactions that *might* be recorded against invalid fund-org code combinations. The report includes fund-org code summary balances for any fund-org that is not budgeted. As you can guess, there might be instances where a fund-org is legitimately not budgeted.

Background: Under the pre-Banner ledger system, accounts and funds had to be linked together in the Chart of Accounts (Account-Fund Profile) before the account-fund could be used. This allowed exception reports ("no title" reports) to be produced indicating transactions recorded against invalid account/fund couplings. The Banner Chart of Accounts does not provide a similar fund-org coupling mechanism. As a result, the FZRINOF report was created to uncover *possible* invalid fund-organization code couplings.

Service centers are advised to review the appropriateness each fund-org combination on the listing. If the fund-organization code are not correct, then use Banner queries to determine what transactions make up the balance. These transactions should be transferred to the correct fund-organization code using a transfer of expenditure form.

Failure to correct transactions recorded against invalid fund-organization codes may result in unexpected budgetary overdrafts; erroneous unit, service center, and campuswide financial reports; and erroneous billings to federal, state, and private agencies.

OTHER FIS / BANNER ITEMS: None

CALENDAR OF FIS / BANNER EVENTS

Please note that period close-related dates are estimated.

PROJECT STATUS

CALENDAR YEAR-END BANNER REPORTING: IRS Form 1099 reports were successfully produced and distributed.

REPORT PRODUCTION COORDINATION: Work continues on this project

DISTRIBUTED TRANSFER OF EXPENDITURES ("Short" version, the "Long," detailed version appears as a bonus installment of "Insider’s Peek." Check the results of last month’s TOE survey in the "Odds and Ends" section below.): Work continues on customizing the Banner TOE/TOF input form and in developing procedures governing the use of the Banner TOE/TOF form. The project remains on schedule for full implementation by early April 1997.

We investigated the feasibility of combining distributed TOF’s with the distributed TOE’s and found that it could easily be done. As a result, distributed TOF’ will be made available with distributed TOE’s. Later this month, we hope to offer users a test drive of the TOE/TOF input form. From a Banner user’s own workstation, the customized Banner TOE/TOF form will be made accessible from the UTRN database. Complete step-by-step instructions will be provided prior to the test drive period. We look forward to receiving feedback from those of you participating in the test drive.

Several service centers have offered up volunteers to participate in full-scale testing of the distributed TOE/TOF process. This will take place later this month. A complete half-day TOE/TOF classroom lab training program is planned for mid- to late-March. It will be conducted based on service center and the types of TOE’s/TOF’s that your service center typically process. In this way, we can tailor training to better meet your needs. Complete user documentation will also be provided to all users.

Paper TOE’s and TOF’s will continue to be accepted after implementation of the distributed TOE’s and TOF’s process. However, we hope that all service centers will choose to use the distributed process. This will minimize the difficulty in processing TOE’s involving two different service centers - one using paper and the other using the distributed process. As you can guess, the approval process for these kinds of transactions will be complicated.

APPROVAL QUEUES SETUP: Service Center Managers and their unit heads should begin thinking about approval queue setup for TOE’S input by their Service Center. Please refer to the guidance provided in the "Long Version" of this article included in the "Insider’s Peek at FIS" section.

BUDGET QUERY CLASS: To gain a better understanding of how the Banner TOE/TOF process fits into the overall campus budgeting and accounting environment, we suggest that you attend the Budget Query class presented by the Planning and Budget Office, if you haven’t already done so. The next half-day class is tentatively scheduled for Monday, March 10, 1997. Contact Don MacAngus at x4349 for additional information.

SERVICE CENTERS INVOLVED WITH CONTRACTS AND GRANTS FUNDS should be aware that the Extramural Fund Accounting Unit will be presenting a Contracts and Grants training workshop that will take place shortly after TOE/TOF training. Because of the sensitivity surrounding contract and grant transactions, distributed TOE and TOF entries involving contract and grant fund codes will not be allowed until a user has completed this training.

QUESTIONS & ANSWERS / TIPS & TRICKS

TIPS & TRICKS: None submitted over the past month

QUESTIONS & ANSWERS

How come FGIBDST sometimes goes out and pulls enormous budget figures($84450188.55) when I first go in, before I've even had a chance to input any FOAPAL info? It's really starting to bug me, because this can take a while and it ties everything up. It's not consistent; it just seems to do it when it likes.

ANSWER: Other Macintosh Banner users have reported experiencing the same problem. The problem does not seem to effect PC users. Several service centers believe that the problem is not related to Banner, but to a Telnet computer communications software/hardware problem. These service centers reported that the problem disappeared when latest version of UCSC Telnet (available on the CATS server) was reinstalled on the offending computer workstation, ALL telnet sessions were deleted, and new sessions were reloaded. Those with technical savvy have commented that the problem appears to involve problems with keyboard mappings. We have reported the problem to the IRC, along with other information we’ve accumulated about the situation. (Hats off to Marilyn Wood in Natural Sciences Division for passing on this information and Mimi Hill in the Arts Division for providing some of the specifics about the likely fix.)

________________________
Questions or problems regarding the Banner system can be directed to:
Ledger Reports, Fiscal Closing - Vicki Gutzwiller vickig@cats
Banner Security, Access - Monique Leduc mleduc@cats
Other questions - Kirk Lew kllew@cats

INSIDER’S PEEK AT FIS

BONUS EDITION:

DISTRIBUTED TOE’S/TOF’S (LONG VERSION)

Banner came to us with a "vanilla" version of the TOE form that is currently used by the Accounting Office. For distributed TOE’s, this "vanilla" TOE form is being customized to make it easier to use. Extraneous data entry fields have been "masked" (i.e. removed from the form by a programmer-analyst/artist) to eliminate the need to tab through numerous unused data entry fields (Making for less muscular left pinkies around the campus). Those FIS and Acctg Ofc folks who have tested the form have found it simple to use (which, as you know, is very unusual for Banner).

In enhancing the form, we noticed that transfers of funds could also be easily entered using the same form. As a result, distributed TOF’s have been combined with distributed TOE’s. (What the heck, we said.)

RULE CODES: How data is processed on the Banner TOE/TOF form is controlled by rule codes. Rule codes are four character codes that tell Banner how to process a TOE/TOF transaction into the operating and general ledgers. (Think of a rule code as being a mail slot in a post office. The slot you put your letter in dictates where it will go). When you enter a TOE or TOF, you will enter a rule code on the TOE/TOF form. In addition to determining transaction processing, the rule code also checks for some types of invalid transactions.

There will be several rule codes that will be available for different situations. The vast majority of distributed TOE transactions will involve the basic rule code that essentially says "You want me to process a transaction involving unrestricted funds and organization codes all controlled by your service center" (Pause for a definition: unrestricted funds, or funding that is used to conduct most everyday university business, include general (19900), registration fee (20000), and educational fee (20095) funds). Another rule code will be used to process contract and grant fund-related transactions. Another will handle expenditure transfers involving equipment. Yet another will be used only for TOF’s. A major portion of the TOE/TOF training will focus on explaining how to properly use rule codes. User documentation will also provide guidance.

APPROVAL QUEUE SETUP TIPS FOR SERVICE CENTER MANAGERS (More rules to live by): Processing TOE’s involving unrestricted funds and organization codes that are the responsibility of the same Service Center involves less risk than, say, processing purchasing documents like Purchase Orders that eventually result in the production of a check. Therefore, for these types of TOE’s, Service Centers may choose to allow implied approval on TOE’s for any dollar amount. In other words, Service Centers may choose to NOT have any additional on-line approval for TOE’s -- the inputter could be given maximum implied approval; or the Service Center may decide at what dollar level a TOE should route to a manager, PI, etc. for explicit approval. The Distributed TOE/TOF training will cover what is required for backup documentation. As you might expect, TOE’s involving two different Service Center's will route to BOTH Service Centers for approval, no matter what the dollar amount or fund type.

Transfer of Funds (TOF) (i.e. budgetary transfers), however, can NEVER have implied approval, regardless of dollar amount. That is, all TOF’s MUST be approved by someone other than the inputter. This will probably result in separate TOE and TOF approval queues for most Service Centers.

Certain types of transfers will ALWAYS route to Central Offices for final approval, once they have been approved (either implicitly or explicitly) by the Service Center. These are: Equipment and Construction-in-Progress transfers; Payroll Activity Code adjustments; Balance Sheet transactions; and Contract and Grant Fund Expense transfers. These exceptions will be covered in more detail during training, including any special backup documentation requirements.

A few things to keep in mind when designing your TOE/TOF queues:

• All documents (including TOE’s/TOF’s) route by organization code. You should use the highest level "roll-up" org possible.
• There needs to be at least two approvers (primary and backup) at EACH dollar level of a queue.
• TOE’s/TOF’s route through the dollar levels of a queue based on the absolute total dollar amount of the document. For example, if a TOE consists of two transactions: a $100 Debit and a $100 Credit, the document will be considered to have a value of $200 for approval purposes, even though the net document balance is zero.

TOE/TOF Authorization Forms for both inputting and approval will be provided at the Distributed TOE/TOF training and must be completed and returned to the Banner Security Administrator before Distributed TOE’s/TOF’s can be activated for a Service Center. If you have any questions about TOE/TOF approval queues, please contact Monique Leduc at x5133 or mleduc@cats

TOE/TOF Test Drive (Limited Time Offer. No fine print. Honest): Later this month, we plan to offer users a test drive of the TOE/TOF input form. From a Banner user’s own workstation, the customized Banner TOE/TOF form will be made accessible from the UTRN database. Complete step-by-step instructions will be provided prior to the test drive period. (We have an ulterior motive: to get feedback so that we can fine-tune the form, if needed, and also to get users somewhat familiar with the form prior to training so that the training can focus on boring stuff like rule codes).

Just when you think this is too good to be true. You’re right, it is. There are a few things about the distributed TOE/TOF process that aren’t so great. (Com’n, you had to be expecting this). Printing of TOE/TOF forms is not elegant. You will need to know how to run a print job using a separate Banner form, GJAPCTL - Process Parameter Entry Form (The form name is scarier than it really is). Actually, it’s not that hard to print, just harder than it probably needs to be (This is Banner, after all). Documentation will provide you with guidance and the TOE/TOF training will also include a brief overview. This is the same form used to print out PO’s. (So there’s probably someone in each service center who knows something about Banner printing-perhaps we can put a target on their backs to make them more identifiable).

The other part of the TOE/TOF process that’s not so glamorous involves the "office of record." Because this is a distributed, or decentralized process, in which the Service Center is responsible for approving/posting TOE’s/TOF’s involving unrestricted funds, the service center is also responsible for maintaining the supporting documentation for these transactions. This documentation must *always* be complete and easily retrievable in the event campus internal auditors or the Regent’s independent auditors (i.e. Deloitte & Touche, CPA’s, no less) need to review TOE or TOF transactions. Document retention guidelines will be discussed in training. User documentation will also provide you with additional guidance.

On the whole, we think the distributed TOE/TOF process will be one of the more popular and beneficial Banner processes. (No, we won’t wager on that remark. Talk to us later, though.) Stay tuned...you can never say enough about TOE’s and TOF’s.

Now that we’re in the middle of Bannerland: Where do we go from here?

Having made our way to the middle of Bannerland, we are confronted with a major decision - to ride another ride (i.e. continue with the planned Banner upgrade path) or sit on a bench and collect ourselves before riding another ride (i.e. wait a bit, then pursue what might be a more preferable Banner upgrade option).

The current FIS/Banner plan calls for us to prepare for the next Banner upgrade, from our current version 2.0.7 to 2.1.5. This is to be implemented sometime around December 1997. Analysis has just begun on planning for the upgrade. Preliminary findings and reports we have received from other colleges and universities using Banner (Banner installations) indicate that there are a number of major upgrade issues confronting us (Repeat after me: There are no painless upgrades)

To complicate matters, SCT/Banner has announced that the next Banner upgrade, known as Banner 2000 (queue up the 2001: A Space Odyssey theme song) will be released in July 1997 (The betting money says December 1997 is more likely). This announcement creates a dilemma for us (and many other Banner installations). By the time we plan and implement the upgrade to 2.1.5, put users through a what is likely to be a rigorous Banner retraining effort, and go through the pains of adapting to the 2.1.5 interface, it will be obsolete. Within months of the 2.1.5 implementation, we will be repeating the same steps to implement Banner 2000 by December 1998. (Was that a groan I heard?).

Here are the facts that we have been able to gather based on our preliminary analysis:

So far we have identified some of Banner 2.1.5’s more attractive features (the drum roll, please):

Support of a graphical user interface (GUI) and a mouse. A character-based interface is also available (the version of Banner we are currently using is character-based). Other Banner installations have opted to use only character based interfaces or a mix of character-based and graphical interfaces. Oregon State University has tested GUI functionality and reports that it is identical to the character-based interface(sans mouse support). Since December 1996, OSU has been using character-based Banner 2.1.5 and has not yet implemented GUI.

Some improvements to the Banner Acquisitions/Purchasing functions.

• Improved inventorial equipment functionality.
• Some improvement in contracts and grants functionality, especially in the area of proposals.
• Some bugs existing in version 2.0.7 have been fixed in version 2.1.5.
• Improved help features

Banner 2.1.5’s shortcomings (fasten your seatbelts, it gets pretty technical at times):

• Graphical form files are delivered to a workstation from a forms servers (several of them actually). Separate GUI versions of Banner forms exist - one each for the Macintosh, Windows 3.1/95, and Windows NT platforms. We have received no information about forms support for Unix Motif. Being graphical files, they are large and will significantly increase traffic across the campus network. As a result of all this, response time is expected to be no better than what is currently available. Indeed, it could be worse, particularly during peak usage periods. As we mentioned earlier, many institutions are opting to use the character-based forms because the file size of character-based forms is much smaller than comparable graphical ones, speeding delivery. In addition, a lower-powered workstation can handle processing character-based forms.
• Banner 2.1.5 uses client-server processing, which means that some information processing will be done on your workstation (using the CPU, or brains, on your terminal, Mac, or PC. Under Banner 2.0.7, processing takes place on DINKY). This might offset a bit of the performance degradation resulting from the situation described in 1. above.)
• Because of 1. and 2., you will need a powerful workstation in order to run Banner 2.1.5, particularly in GUI mode. For adequate performance, the minimum computer hardware requirement includes a fast Pentium PC with at least 32 megabytes of RAM or a PowerMac with at least 24 megabytes of RAM. Running Banner 2.1.5 in GUI mode is likely to be costly for many service centers.
• The differences between the Banner 2.1.5 graphical or character-based interface and the Banner 2.0.7 interface are significant. It will take users some time to get used to the changes. Because of this, a comprehensive Banner retraining effort will be needed. Additionally, documentation will have to be overhauled.
• Version 2.1.5 contains "bugs" - some of which are a continuation of version 2.0.7 bugs. Others are completely new.

Cutting through the usual SCT hyperbole, we believe the following Banner 2000 (formerly called Banner 3.0 and before that 2.2) features to be pertinent:

• Banner 2000 will include all the functionality of Banner 2.1.5. Some bugs in Banner 2.1.5 should be corrected in Banner 2000.
• Banner 2000 will use a web browser, like Netscape, as its user interface. As a result, you don’t need an extremely powerful workstation to run it. It also eliminates cross-platform problems (i.e. ongoing support of forms for the Macintosh and Unix).
• To upgrade from Banner 2.0.7 to Banner 2000 requires that 2.1.5 be installed first. That doesn’t mean you have to Banner users will have to use 2.1.5, though. Banner 2000 can be installed immediately after installation of Banner 2.1.5. It will take several days of system downtime, though.

We will know more about Banner 2000 in the next few months. The annual Banner users conference to be held next month should provide us with many more details, which we will pass on to you.

Other considerations:

SCT/Banner only supports the latest two versions of its software, meaning that once Banner 2000 is released, support for Banner 2.0.7 ends. Banner support includes providing bug fixes and other support to campus programmer-analysts. This support is expected to end in the Fall of 1997. Additionally, the database application on which Banner runs, Oracle (remember, the "workhorse?"), upgrades its software and drops support for old versions, too. We believe that we can continue to safely use version 2.0.7 through December 1998 (not without some trouble, though it’s manageable). Eventually, we will have to upgrade to a more recent version of Banner. However, if we pursue the right course of action, we should be able to minimize hardship to the campus (Timing really is everything).

Many other colleges and universities using Banner are facing the same dilemma as us. Those that have not installed and tested Banner 2.1.5 are contemplating upgrading from 2.0.7, directly to Banner 2000 in order to avoid the disruption and turmoil (i.e. retraining, adapting to the interface, dealing with bugs, etc.) caused by back-to-back major upgrades. Some of these installations are requesting SCT/Banner to continue 2.0.7 support beyond the established standard so that they can make the upgrade from 2.0.7 to Banner 2000. If we were to pursue a similar course, we would likely aim for December 1998 as a Banner 2000 conversion date. In the interim we might consider making improvements to Banner 2.0.7. (in addition to fixing what still doesn’t work.)

Over the next few months, we will continue this dialog through the FIS Bulletin and in user group meetings. We will also continue to provide you with more details (why suffer alone?). Over this time, we would appreciate getting your thoughts about going for another ride or sitting on bench for a while.

In the next issue:
A candid interview with BannerSlug, the official mascot of Bannerland.

ODDS & ENDS

FIS / BANNER: None

REQUEST FOR FEEDBACK ISSUES

A BIG THANKS TO ALL WHO RESPONDED TO THE TOE SURVEY: All but one service center responded to our request for information concerning the volume and extent of TOE processing, and the number of preparers and approvers at each service center. The data is being used to plan training. We are "categorizing" service centers according to the variety of TOE’s they prepare and tailoring training to meet their needs.

For those interested in the results, the following are some of the more interesting findings:

• A total of 37 service centers and offices not affiliated with a service center reported TOE information to us.
• There are 103 preparers of TOE’s on the campus. There are 101 approvers. (Note some preparers are also approvers)
• During the off peak months (July-March), an average of about 2,572 entry lines of TOE’s are prepared each month on the campus, or about 69.5 entry lines per service center. During the peak months (April-June), the average monthly number of lines balloons to about 5,434 entry lines, or about 146.9 entry lines per service center.
• TOE entry lines involving the same fund-org constitute about 38.2% of the total campus TOE entry lines. 39.6% involve TOE entry lines transferring expenditures within fund-orgs maintained by the service center. 11.6% involve TOE entry lines involving different service centers. The remaining 10.6% of TOE entry lines involve plant funds, extramural funds, and balance sheet accounts.
• Only one service center prepared TOE entry lines involving plant funds.

Contributors: Kirk Lew, Monique Leduc, Karsen Jones, Vicki Gutzwiller
Your comments and suggestions are always welcome. Please direct them to the editor, Kirk Lew kllew@cats

Financial Affairs | Accounting Offices | Campus Controller | FIS

Comments to: controller@ucsc.edu - Maintained by FIS, Updated