Creating an Extended Attribute Vince Schimizzi, Michigan State University Evelyn Portee, Michigan State University Lauri Thornhill, Michigan State University.

Creating an Extended Attribute

Vince Schimizzi, Michigan State University

Evelyn Portee, Michigan State University

Lauri Thornhill, Michigan State University

Agenda

I. What is an Extended Attribute?

II. Why create an Extended Attribute?

III. How do I create an Extended Attribute?

IV. Assigning functionality to an Extended Attribute• Business Rules• Workflow Rules

I. What is an Extended Attribute

• Attribute: An object associated with and serving to identify an

entity. In the Kuali Financial System (KFS) an attribute is a field, delivered with the system, to which values can be assigned (e.g. account name, account number, account expiration date, etc.).

• Extended Attribute:Custom, table-driven business object attribute that can

be established by implementing institutions and added to KFS without modifying the delivered functionality.

How is your institution unique?

- Special reporting requirements?

- Out of the ordinary accounting policies or rules?

- Complex workflow needs?

II. Why create an Extended Attribute?

• In the event your institution is unique and requires additional attributes, the KFS allows you to add extended attributes to your maintenance tables for the following purposes:

• Reporting

• Business Rules

• Workflow Rules

Account

ACCOUNT

PK ACCOUNT NUMBERPK CHART CODE

ACCOUNT NAME FISCAL OFFICER ORG CODE SUB FUND CODE HIGHER ED CODE Etc.

Account Attributes (green)

ACCOUNT

PK ACCOUNT NUMBERPK CHART CODE

ACCOUNT NAME FISCAL OFFICER ORG CODE SUB FUND CODE HIGHER ED CODE Etc.

CHART

PK CHART CODE

CHART NAME CHART MANAGER REPORTS TO CHART

ORGANIZATION

PK ORG CODE

ORG NAME CHART CODE ORG MANAGER REPORTS TO ORG

SUB FUND

PK SUB FUND CODE

SUB FUND NAME FUND CODE

FUND

PK FUND CODE

FUND NAME RPRT SORT CODE

HIGHER ED

PK HIGHER ED CODE

HIGHER ED NAME

Account Extended Attribute (blue)

Extension Table

Extended Attribute Tables

ACCOUNT_EXT

PK ACCOUNT NUMBERPK CHART CODE

YY CODE XX CODE

YY

PK YY CODE

YY NAME YY MANAGER

XX

PK XX CODE

XX NAME XX PURPOSE

ACCOUNT

PK ACCOUNT NUMBERPK CHART CODE

ACCOUNT NAME FISCAL OFFICER ORG CODE SUB FUND CODE HIGHER ED CODE Etc.

CHART

PK CHART CODE

CHART NAME CHART MANAGER REPORTS TO CHART

ORGANIZATION

PK ORG CODE

ORG NAME CHART CODE ORG MANAGER REPORTS TO ORG

SUB FUND

PK SUB FUND CODE

SUB FUND NAME FUND CODE

FUND

PK FUND CODE

FUND NAME RPRT SORT CODE

HIGHER ED

PK HIGHER ED CODE

HIGHER ED NAME

Extension Table

• The extension table can hold a collection of extended attributes.

• The extension table acts as a bridge between the account and the extended attributes. This relationship allows the system to treat the two tables, account and account extension, as one. This design facilitates assigning business rules or workflow rules to the newly created extended attributes.

• The extension table and the parent table have the same primary keys, creating a one to one relationship that enforces data integrity.

• The different types of attributes - direct, associated and extended - allow your institution to leverage their relationships in order to customize KFS to meet just about any reporting, business rule or workflow rule need your institution may have.

III. How do I create an Extended Attribute?

• Configuring KFS to add an Extended Attribute involves both functional and technical resources.

Functional Issues to Consider/Decisions to Make

• Determining the functionality of the extended attribute is a major step and will directly affect the technical aspect.

• Take a global approach when creating an extended attribute (usually not created to meet the needs of a specific unit).

• Assess the level of data governance needed

• An Extended Attribute should be created to serve one purpose

• Required or Optional

User Interface Options

Option 1 - Text Field

Advantages • User-defined values• Unlimited and immediate creation of values• Flexibility on reporting

Disadvantages • Limited data integrity (lowest)• Increased potential for input errors

User Interface Options – cont’d

Option 2 - Values Not Supported by a Table

Advantages • Institution-defined values • Enforces integrity of data (highest)

Disadvantages • Limited flexibility on reporting• Time to add or remove values (highest)

User Interface Options – cont’d

Option 3 - Values Supported by a Table

Advantages • Institution-defined values• Assign attributes• Enforces integrity of data

Disadvantage

• More time to set up

Prepare a Functional Specification Document

• Document functional justification and intentions for future reference.

• Describes functionality of the new extended attribute.

• Bridges the communication gap between the functional and technical teams.

• Request should be reviewed by a business analyst.

Technical Steps

Step 1 – Update the Data Model Oracle Database – add tables

ACCOUNT

PK ACCOUNT NUMBERPK CHART CODE

ACCOUNT NAME FISCAL OFFICER ORG CODE SUB FUND CODE HIGHER ED CODE Etc.

CHART

PK CHART CODE

CHART NAME CHART MANAGER REPORTS TO CHART

ORGANIZATION

PK ORG CODE

ORG NAME CHART CODE ORG MANAGER REPORTS TO ORG

SUB FUND

PK SUB FUND CODE

SUB FUND NAME FUND CODE

FUND

PK FUND CODE

FUND NAME RPRT SORT CODE

HIGHER ED

PK HIGHER ED CODE

HIGHER ED NAME

ACCOUNT_EXT

PK ACCOUNT NUMBERPK CHART CODE

REVENUE SOURCE CODE REVENUE SOURCE

PK REVENUE SOURCE CODE

REVENUE SOURCE NAME

Technical Steps (cont’d)

Step 2 – Update the Data Dictionary

Create new maintenance form

Update the associated forms (lookup, global, etc.)

Step 3 – Application Recognizes the Extended Attribute

Add to Application Document Type

Add to Workflow Document Type

MSU Example

Enhancement Request:

Create new extended attribute named “Revenue Source” on an account maintenance document. The new attribute will capture the levels of government that provide funding to the institution. The attribute should have full search capabilities and have the ability to support both business and workflow rules.

Extended Attribute Table = Revenue SourceExtension Table = Account _ Extension

Values: FD = FederalST = State

Etc.

Maintenance Tab

Access to the new Extended Attribute’s maintenance document will appear in the Chart of Account’s section on the Maintenance Tab.

Extended Attribute Main’t Doc

Functions the same as other KFS maintenance docs

Values – Revenue Source

Institution Defined Values

Account Maintenance Form

Appears on Associated eDocs

Account Lookup Document

Search Lookup and Search Results

Security Rule

Restrict access to the Extended Attribute maint doc

IV. Assign Functionality to an Extended Attribute

• Creating Business Rules and Workflow

- Exploring the functionality

- Translating the functionality

- Technical from 30,000 feet

Creating a Business Rule

• Decide on what document(s) the business rule will apply.

• Translate the functionality of the rule in clear-cut terms

• Decide when you want the business rule to apply• The decision you make here affects how the

document cycles and may impact user frustration.

Exploring the functionality of the business rule (MSU example)

MSU Business Rule in Standard English

(Normal English Narrative)

• MSU wants to prevent federal monies on Michigan State University Extension (MSUE) funds from being used to pay for scholarships on the Distribution of Income and Expense document.

Translating the functionality of the business rule (MSU example)

MSU Business Rule in Structured English(More easily transferred into programming logic)

On the Distribution of Income and Expense Financial Document:

If Revenue Source Code = FD (Federal), and SubFund Group Code = MSUE (MSU Extension),

Then Object Subtype Code ≠ SC (Student Scholarships)

Technical Steps – Business Rule

• Step 1: Create parameters related to the values defined in the if/then statement.

Technical Steps – Business Rule

• Step 2: Create the business rule class that corresponds to the parameters set up in

step 1.

• Step 3: Add the name of the business rule class into the data dictionary of Distribution of Income & Expense document.

Remember – 30,000 feet

MSU Business RuleError Message

• If Revenue Source Code = FD, and

SubFund Group Code = MSUE,

• Then Object Subtype Code ≠ SC

Workflow

Workflow rules must be created in order for the financial processing document to route on the extended attribute.

Workflow

• Similar to business rules, you need to create a functional description of workflow rule to be established.

• Translate the functional description for the technical personnel

Translating the functionality of the Workflow Rule

(MSU example)

On a Distribution of Income & Expense eDoc:

If Revenue Source Code = ST (State), and SubFund Group Code = MAES (Michigan Ag Experiment Station)

Then, document routes to MAES_MSUE_ADMIN workgroup for approval.

Workflow (technical)

Step 1: Create a Rule Attribute Specify the attribute fields on which to base the rule template.

Workflow (technical)

Step 2: Create a Rule Template Incorporate the rule attribute(s).

Workflow (technical)

Step 3: Add the route node

• In the XML code of the Distribution of Income & Expense document type:

- the route node must be added

- the rule template must be added

Workflow (technical)

<name>DistributionOfIncomeAndExpenseDocument</name> <parent>KualiFinancialDocument</parent> <label>Distribution Of Income And Expense</label> <postProcessorName>org.kuali.workflow.postprocessor.KualiPostProcessor</postProcessorName> <superUserWorkgroupName>KUALI_ROLE_SUPERVISOR</superUserWorkgroupName> <blanketApproveWorkgroupName>KUALI_ROLE_ADMINISTRATOR</blanketApproveWorkgroupName> <defaultExceptionWorkgroupName>KUALI_ROLE_SUPERVISOR</defaultExceptionWorkgroupName> <docHandler>${application.url}/financialDistributionOfIncomeAndExpense.do?

methodToCall=docHandler</docHandler> <active>true</active> <routingVersion>1</routingVersion> <routePaths><routePath> <start name="Adhoc Routing" nextNode="Account Review" /> <requests name="Account Review" nextNode="Org Review" /> <requests name="Org Review" nextNode="Subfund" /> <requests name="Subfund" nextNode="Award Workgroup" /> <requests name="Award Workgroup" nextNode="SubFund and Revenue Source Routing" /> <requests name="SubFund and Revenue Source Routing" />

Workflow (technical)

Adding the route node automatically updates Rule Quicklinks

Workflow (functional)

Step 4: Create the rule.

Workflow (functional)

Step 4: Create the rule (cont’d)

MSU Workflow Demo

MSU Workflow Demo

Final Thoughts

Making the functional decision involves a variety of stakeholders and may be a time-consuming process.

In our MSU example, after the functional decision was made, from the technical to resolution and completion was approximately 40-80 hours.

The level of complexity of the extended attribute’s functionality will directly affect the amount of technical time required.

Take Aways

• When and why you might want an extended attribute.

• The ease that Kuali provides to create the extended attributes.

• The ease of creating business rules.

• The ease of creating workflow rules.

Questions?