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

Inactivation of Activity Codes - causing issues with feeding systems such as student and Payroll

Over the past several weeks there have been several transactions from feeding systems that were not updated due to activity codes that have been inactivated. The creating, maintaining, and inactivating these codes is vested with the campuses/departments. Once one of these codes has been deactivated, the system will not allow any transactions to process using this code. This means, if the activity code is currently on a detail code in the student system, any feed from the student system will fail to post, because of that inactive code. The same is true for any outstanding encumbrances, payroll activity, etc. The system does not check to see if there is activity outstanding for you - you have to do that prior to deactivating the code.

Prior to deactivating any activity code, each must be researched thoroughly to make sure it is not currently in use for some activity. The following items have to be checked;

There are no outstanding encumbrance against this activity code, requisitions, purchase orders, POBs, etc.

There is no payroll activity using this activity code.

The code is not being used by any of the student detail codes.

The code is not part of any default accounting line for any PCard cardholders.

The code is not referenced on any open - but complete and approved - invoices.

If you require assistance with this, please contact Banner.Finance.Production@unh.edu before the code is inactivated.

If a feed is stopped due the an inactive code, we will have to reactivate the code in order to process the feed. This is particularly important for outstanding encumbrance activity, as reactivating the code is the only way to clear the current commitment.

Back To Top

No PCard transaction activity during VMS shut down

As an addendum to Monday's email, in addition to the items listed, there will be no PCard activity processed in the Banner Finance system while the VMS cluster is unavailable. We continue to communicate our daily transactions through the VAX cluster. Therefore while this system is not available, no new PCard activity will be processed into Banner Finance.

All activity from the Bank will accumulate during this time and will be processed as quickly as possible once the VAX cluster returns.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As you have all seen and heard for months - the VMS cluster will be moving beginning this coming Saturday, October 19th. Although our current finance system is no longer located on the VMS cluster, this does impact financial users in a number of ways.

CUFS will not be available for query of any kind.

1032 data, such as MASEXPB, will not be available for query of any kind.

Use of the VAX cluster to transfer files between all our systems, particularly for feeds to finance, will not be available, all of you who have regular feeds have already been contacted to make alternative arrangements.

Depending upon the timing of when the VAX cluster returns, could impact when the next few payroll feeds are posted to Banner. (The payroll feeds must first process through the CUFS system to calculate the fringe).

Creation of individuals as vendors will not be possible during the time the VAX is unavailable. Depending upon the situation, which will have to be reviewed on a case-by-case basis, this could result in a slight delay to process a payment coming due to an individual who is not yet a vendor, please make every effort to have that person established as a vendor this week. That will allow the invoice to be processed appropriately in Banner while the VAX cluster is down.

Fund and Org creates may take a little longer to process. The existence of the fund-area-org combination will have to be manually determined to properly establish the crosswalk data. In addition, all that are created while the VAX is off-line will have to be verified and any new CUFS items created on the VAX once it returns.

These are the larger issues from a financial perspective we are aware of, there may well be others that impact your respective areas. Primarily, the results will be slight delays in processing some items until the cluster returns.

Everyone will make every effort to minimize any delays, but all should be aware that some may occur.

Back To Top

There seems to be a flurry of questions surrounding the MR2 Report of Unposted documents, we hope this will help clarify things.

The Report of Unposted Documents does report documents that are in process in some manner, however, it also includes lines that have remained in a table called BAKO even after the document has posted and is reflected correctly in Banner. These documents and their related amounts are reflected properly in FGIBDST, FGIDOCR and FGITRND. However, they also cause FGIBAVL to reflect a budget availability that is incorrect. As you know, FGIBDST only reflects posted documents and FGIBAVL reflects posted and "in process" documents, which it takes from the BAKO table.

The BAKO table is a temporary holding place for documents while they are waiting to be completed, approved or posted. Most every document will be in this table at one point or another. As soon as a document is entered into any table, the document will also reside in the BAKO table until successfully posted or removed by the user. After posting, the document is generally removed from the BAKO table. There are times however, that although the document is posted, some or all of the lines related to that document remain in BAKO.

Due to the complexity of the Banner tables, there is no other report at this time that can provide a listing of incomplete/not approved/unposted documents. Utilizing the BAKO table is the most direct route to this data. However, use of this data will also result in display of documents that are posted and remain on the BAKO table. This has been causing some of the confusion we have been hearing about over the past few days.

If you find lines from documents that you believe should not still be on this list, please call your campus Help Desk. They will relay the pertinent information and the issue will be further researched. If your document is one of the errant lines, there is nothing you or any of the central offices can do to clear it. There is no document process that we are aware of that will result in the lines being cleared. Processing additional documents attempting to clear these amounts will not correct the problem and may make your budget availability even worse. Until we can get this issue under better control, there are two steps that can be taken to allow you to continue processing documents. First, you can add sufficient budget to the line, or pool, to negate the impact of this document on your BAVL line. This is not ideal, but it will support ongoing operations until we can get the root of the problem resolved. Second, you can request your campus central office provide an NSF override. This will allow your subsequent documents to process even though it appears to be out of available budget.

We are working with SCT to resolve this behavior. Removing the lines from the BAKO table is a complex procedure and there is a great deal of research that must occur before it is decided to remove any line from this table outside of the normal Banner processes. Sometimes the lines will simply self-correct, sometimes they are removed as a result of the weekly run of the BAVL rebuild process, and occasionally we must manipulate the table directly to remove errant lines. The latter action can only occur immediately preceding a rebuild of the BAVL table, otherwise the action will have no impact on the data being reported.

Thanks to all of you for your patience, we know this report is not ideal, but it is the only reporting mechanism that can get you close to the data you are looking for, at this time.

Back To Top

Welcome to Banner General Release 5.4!

The upgrade is complete and the production instance is available for your use. Please report any issues or concerns you might find to your campus help desk.

Thank you all for your patience.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The Banner Finance Production instance (BPRD) will be unavailable to all users from 9 PM tonight, Thursday, October 3rd, until normal business hours on Monday morning, October 7th.

This is the upgrade to SCTs general release 5.4 that was discussed in email last week and at the BSC Forum during this past week.

This upgrade will not impact the availability of other instance such as BTST, nor will it impact the availability of the MR data and the Webi access. These will continue to be available for testing or training and reporting activity during their normal schedules. Of course, since the production instance will not be available on Friday - the MR data will reflect the data as of Thursday night's production until Tuesday of next week.

We apologize in advance for any inconvenience this may cause you - if you have questions or concerns please forward through your campus' help desk or reply to this mail message.

Thank you.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Banner Finance is currently operating on SCT's general release 5.2. This is two releases behind the current version. With our go-live date and the number of issues faced to stabilize the environment post-go-live, there has not been an opportunity to address implementation of a new release until now. As time goes on, particularly after HR goes live, USNH will be more current with SCT releases, but for now - there will be times when we linger behind.

Many of you have been involved in testing the new release which has been in test mode in the BTST environment for several weeks. Over 30 users participated in testing the system this past Tuesday. There are some areas that will present a slightly different interface to the user and some items that did not function previously that have now been corrected. These items will be reviewed and demonstrated in more detail at the BSC Forum scheduled for Wednesday October 2nd. Please attend if you possibly can.

The production environment will be upgraded over the weekend of October 4, 5, and 6. Yes, you did read that correctly, it includes Friday. It will require 3 days to fully upgrade the production environment. To accommodate this, the production environment will not be available on Friday, October 4th - for the entire day - Saturday, October 5th, and Sunday, October 6th. The system will be backed up - upgraded - and back in production for normal business Monday, October 7th. All invoices requiring checks as part of the Monday morning accounts payable check run will have to be entered, approved and posted by close of business Thursday, October 3rd to be included in the check selection process run Monday morning.

We look forward to seeing you at the BSC Forum. If you are unable to make the forum, materials and pointers of the changes will be available on the FYI web site about the same time as the Forum meeting, so please feel free to reference that site after Wednesday, October 2nd.

Back To Top

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