Archived Data from prior periods is available in the FYI Archive.

As a result of the 1099 processes that were run for calendar year 2002, we found that there were some instances where the one-time vendor option on a Direct Pay was used to pay for services. As you can imagine, this caused difficulties in our data collection and subsequent reporting to the IRS. This notice is meant to remind all users that the one-time vendor option cannot be used for payments for services rendered.

The information below is part of the Banner documentation which speaks to the issue and will clarify when a one-time vendor can and cannot be used.

Although Banner will allow the use of the option, USNH has placed restrictions on its use. USNH will allow the use of the "one-time vendor" option only under the following circumstances:

  • Refunds
  • Rebates
  • Non-employee travel or business expense reimbursement
  • Membership fees to organization
  • Cash prices due to raffles and not connected to employment - provided that the payment is less than $600 and that the originating unit does not see future need to research the payment through vendor history [Payments for $600 or more are reported to the IRS via W2G reporting by the Controller's Office.]
  • Feeds into Banner from an outside source (i.e., PCard for Student Systems, etc.)

NOTE: The "one-time vendor" option cannot be used for payments for services rendered or when a vendor code has already been established in Banner.

For more detailed information, please visit the purchasing web site to view the entire procedure for the appropriate use of the "one-time vendor" option.

Back To Top

As a result of the issues with the forms server last week - we have been running on an alternative solution since then. The IT group has received and installed new parts for the primary server and are now ready to put it back into place. The systems will need to be down for about an hour in order to move all related forms back. The IT folks are preparing to do this at 6 PM on Wednesday, March 12th. So that you do not loose any data, please complete any documents you may be working on before that time.

Additionally, there is one remaining instance in Banner that has not yet been moved to the new disk storage area purchased in January, this is the TRNG instance. As most testing for finance is currently conducted in BTST - this most likely will have it's most significant impact on the HR folks. In order to move this instance, it will need to be unavailable for one day. The IT folks are preparing to perform this work on Thursday, March 13th.

Just to recap -

  1. All instances including BPRD will not be available after 6 PM on March 12th. All instances including BPRD, except TRNG as noted below, will be available as usual Thursday morning.
  2. The TRNG instance will not be available all day on Thursday, March 13th. No other instances should be impacted.
Back To Top

Last Thursday we experienced a Web-enabled Banner service outage that resulted in Banner being totally unavailable to users for three hours. We regret the inconvenience this caused and thought that you would appreciate learning what happened and what we have learned from the experience.

What happened - there are files that Banner accesses to paint the Web interface and provide the logic to the application. The Web application server needs to read these files for your application to run. These files are served from a storage area network that has dual redundancy for all critical components. What occurred were two simultaneous failures of redundant hardware. The details are a disk failed; an automatic fail-over to a hot spare was underway when a disk-controller failed; the disk-controller failed to default to the redundant disk-controller. Based on mean time between failure data from the manufacture you might experience a simultaneous failure such as this once in a decade if the system was in continuous service 24 by 7.

What we did - Enterprise Computing Group went into disaster recovery mode as planned. A solution was designed to recovery services to users as quickly as possible without any dependence on the failed system being repaired. An alternative file serving environment was created and the files were restored from backups. The new environment was tested at multiple levels including the Controller's office and returned to the Banner users. The failed system was repaired during the day by ECG staff with parts expressed in by the vendor and was restored to service later that same day.

What we learned - be prepared. Having a plan, good documentation, reliable data backup systems, and talented staff are invaluable. We were fortunate in having all four. It has been reinforced that the highly unlikely is possible thus our disaster recovery plan will gain from the experience and when the highly unlikely occurs next time the recovery will be much faster.

Unrelated good news - last week a number of Banner Student users experienced network drops or application "freezes" while working in Banner. The Banner Web-enabled applications were unaffected. A joint working group of users, ECG, and Networking staff addressed the issue. The problem was caused by a change in networking software behavior following an upgrade - the same configuration prior to the upgrade yielded different behavior that had not been observed in prior upgrades on campus. A solution has been developed and implemented.

Back To Top

The tip is - When approving or denying a transaction in Banner Finance, please select the OK or the Cancel button on the message dialog box as soon as possible. This will help keep the approval job running as quickly and smoothly as it can.

Some additional background:

Recently several reports were forwarded regarding slow processing time on the Banner Finance system - particularly in the afternoon. The MIS staff has done some research on this issue and has discovered that there is indeed some slow down in document's getting approved that frequently occurs sometime around 1 PM. After watching the processes for several days through this time, they discovered that on many occasions of this "slow-down" the issue lie in a single document that had been partially approved, but not completely approved.

After you have approved a document on the FOAUAPP form, you will receive a message that looks something like the message below.

Until you click on the OK or the Cancel - this document is "Locked" by you and no one else, nor any other process, can even look at the document until you do select one or the other button.

When the process that works with the approvals runs, which occurs every other minute in the background all day long, when it comes to look to see if the approvals have been applied to this document - it cannot look at the document until you have clicked on either the OK or the Cancel button. So the process simply sits and waits to be able to access the document. It processes no other documents and will simply wait as long as it takes for this document to become available.

If someone approves the document and then forgets to press the OK or Cancel button on the form above, no other documents can be processed by the approvals job until you do select one of the buttons. This also means that since all of our documents have to be approved either by the user completing it or by someone else on the FOAUAPP form before they can be posted, that no documents will be available to post until this step is completed.

As you can see - this will have the impact of slowing down the entire system. Sometimes it can seem like it takes awhile for the messages to come back, but please remember to complete this last step before you go off to the facilities or to lunch or a meeting. While you are away - many other documents will be awaiting your return.

If you have any questions or concerns regarding this Tip - please contact Finance FYI.

Back To Top

Last Modified: 6/21/2012 12:25 PM
Last Published: