02 - 048 Definition of Attributes in Banner

What is the purpose of this document?

The purpose of this document is to outline the definition, structure, and format of the attribute reporting solution designed by USNH and SCT and the implementation of that solution across the FOAPAL elements at USNH.

What is an Attribute?

An attribute is an alphanumeric field associated with individual values of an element of the FOAPAL string.  They exist to provide flexibility in reporting data from the financial system.  Attribute values can be attached to individual FOAPAL element values to tag them as belonging to a particular category.  Financial reports are run for selected attribute values.  The attributes collect the data in a variety of meaningful ways. 

Attributes are attached to FOAPAL element values and therefore are not associated with detailed transactions.  Banner neither supports use of attributes as a control or data entry restriction nor are there any on-line forms associating attributes with transaction data.  Attributes solely support the reporting environment.

Attribute Definitions

Attribute Type - A reporting component that supports grouping of data in some  meaningful way.  The assignment of the values within a type should all bear similar characteristics supporting some logical grouping or totaling function.  Some attribute types may collect data that can be used for multiple reporting processes.

Attribute Set - Is designed to collects attribute types together in a manner that facilitates the assignment of new FOAPAL elements.  For example, a new fund at KSC would be assigned attribute values for all attribute types in the USNH and KSC sets.

Sets are not in use at USNH. 

Attribute Value - Represent all the possible values that could be assigned to a FOAPAL element for each Attribute Type. For example:

Attribute Type Attribute Value
Type Value Description Value assigned Description
FDIVRCM
Fund Attribute: for Division or RC Unit
UNHB
UNH COLSA
UNHD
UNH CEPS
KSCE
KSC Executive
KSCA
KSC Academic Affairs

Ownership

Attributes exist to meet both central and departmental reporting needs. Many attribute types will be used by a variety of both user types.

All attributes are established and maintained centrally.  Attribute types are defined through collaboration between central, campus and departmental stakeholders. When a new type is created it is assigned a "steward" or owner.   The steward is responsible for defining individual values to the attribute and endorsing any future changes to the values. Initial assignment or changes to values assigned on individual FOAPAL elements can be requested by either the party responsible for the FOAPAL element, i.e. the fund manager for the fund, or the steward of the Attribute Type.

For example, an attribute type for a NCAA report is developed jointly between central, campus and Athletics staff and established in Banner.  Someone in Athletics, at UNH this could be the BSC Manager, would then have the responsibility for defining the attribute values and initially assigning the values to the appropriate FOAPAL element. Once completed, the data is sent to Banner Finance Production at USNH Financial Services - FAST, to be updated in Banner.

  1. A reporting need expected to require attributes should be submitted to the campus Business Office or VPFA office for evaluation and approval. The request will be reviewed by campus and central staff to verify there is not already a solution in place that will meet the need.
  2. The Campus Business Office will forward the request to FAST at Banner Finance Production.
  3. FAST will review the request for a new type.
  4. If approved, the process outlined above will be used to establish the attribute.

Other Issues

  1. We will not cross FOAPAL elements within the same Attribute Type.  For example, if we need campus associated with both fund and org, we will create one attribute type called FCAMPUS to be associated with fund and a different attribute type called OCAMPUS to be associated with org.  While Banner supports attributes being used for multiple FOAPAL elements, at USNH the use of each attribute type will be restricted to one of the FOAPAL elements in an attempt to simplify the system and increase end user understanding.
  2. We will avoid creating attribute types that replicate existing FOAPAL hierarchy functionality which Banner and our reporting environment already leverage.  For example, there is no need to specify an attribute for expense budget pools because we can use a report based on Account Level 2 for this purpose.  Likewise, the Org hierarchy lends a lot of flexibility to reporting based on various levels of responsibility.

Banner Forms

FTMATTT - Attribute Type Maintenance Form - where the attribute types.  Types are associated with the FOAPAL elements. 

FTMATTV - Attribute Value Maintenance Form - where you define the values for the attribute types.  In essence you are creating a pick lists of acceptable values.

FTMFATA - FOAPAL Attribute Assignment Form - where can assign attributes to FOAPAL elements.  Can also do through each elements individual form such as FTMFUND, FTMORGN, etc.

 

Other Forms

FTMATTS - Attribute Type Set Maintenance Form - attributes can be grouped into sets. The FTMATTS form is used to define the sets of attribute types. 

FTMCOAS - Chart of Accounts Code Maintenance Form - You must define on the FTMCOAS form, by FOAPAL element, if you will use sets.  For instance, you can mandate the use of sets for the Fund element but not the Account.

FTIFATA - FOAPAL Attribute Association Query Form - allows users to query by FOAPAL element or attribute type associated values.

FTQATTS - Attribute Type Selection Form - is used in FTMFATA form to show types assigned to FOAPAL elements.

The FOAPAL validation forms (FTVFUND, FTVORGN, etc.) were changed to provide an assign attributes option. 


The official version of this information will only be maintained in an on-line web format. Any and all printed copies of this material are dated as of the print date. Please make certain to review the material on-line prior to placing reliance on a dated printed version. 

This page last updated Wednesday, May 31, 2017. For information on the adoption and effective dates of policies please see explanation on the OLPM Main Menu.