Transcript Kuali PowerPoint

Creating an Extended Attribute
Evelyn Portee, Michigan State University
Lauri Thornhill, Michigan State University
Mike Criswell, Michigan State University
Vince Schimizzi, 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
PK
ACCOUNT NUMBER
CHART CODE
ACCOUNT NAME
FISCAL OFFICER
ORG CODE
SUB FUND CODE
HIGHER ED CODE
Etc.
Account Attributes (green)
CHART
PK
CHART CODE
ACCOUNT
CHART NAME
CHART MANAGER
REPORTS TO CHART
PK
PK
ACCOUNT NAME
FISCAL OFFICER
ORG CODE
SUB FUND CODE
HIGHER ED CODE
Etc.
ORGANIZATION
PK
ACCOUNT NUMBER
CHART CODE
ORG CODE
ORG NAME
CHART CODE
ORG MANAGER
REPORTS TO ORG
SUB FUND
PK
SUB FUND CODE
SUB FUND NAME
FUND CODE
FUND
HIGHER ED
PK
HIGHER ED CODE
HIGHER ED NAME
PK
FUND CODE
FUND NAME
RPRT SORT CODE
Account Extended Attribute (blue)
Extension Table
CHART
PK
ACCOUNT_EXT
CHART CODE
ACCOUNT
CHART NAME
CHART MANAGER
REPORTS TO CHART
PK
PK
ORG CODE
PK
PK
ACCOUNT NUMBER
CHART CODE
ACCOUNT NAME
FISCAL OFFICER
ORG CODE
SUB FUND CODE
HIGHER ED CODE
Etc.
ORGANIZATION
PK
Extended Attribute
Tables
ORG NAME
CHART CODE
ORG MANAGER
REPORTS TO ORG
HIGHER ED NAME
YY CODE
YY NAME
YY MANAGER
YY CODE
XX CODE
XX
PK
PK
SUB FUND CODE
FUND
PK
XX CODE
XX NAME
XX PURPOSE
SUB FUND
HIGHER ED
HIGHER ED CODE
PK
ACCOUNT NUMBER
CHART CODE
SUB FUND NAME
FUND CODE
PK
YY
FUND CODE
FUND NAME
RPRT SORT CODE
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
CHART
PK
CHART CODE
ACCOUNT
CHART NAME
CHART MANAGER
REPORTS TO CHART
PK
PK
ACCOUNT NAME
FISCAL OFFICER
ORG CODE
SUB FUND CODE
HIGHER ED CODE
Etc.
ORGANIZATION
PK
ACCOUNT NUMBER
CHART CODE
ORG CODE
ORG NAME
CHART CODE
ORG MANAGER
REPORTS TO ORG
ACCOUNT_EXT
PK
PK
ACCOUNT NUMBER
CHART CODE
REVENUE SOURCE
REVENUE SOURCE CODE
PK
REVENUE SOURCE NAME
SUB FUND
PK
SUB FUND CODE
SUB FUND NAME
FUND CODE
HIGHER ED
PK
HIGHER ED CODE
HIGHER ED NAME
FUND
PK
REVENUE SOURCE CODE
FUND CODE
FUND NAME
RPRT SORT CODE
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 Source
Extension Table = Account _ Extension
Values:
FD = Federal
ST = 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 Rule
Error 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=docHa
ndler</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
KFS 3.0 & Kuali Identity
Management
KIM works by combining the attributes of user,
groups, roles, and permissions
• Users can have multiple roles (in different systems)
• Groups are collectors of persons
• Roles aggregate permissions or responsibilities
• Permissions are associated with roles
The functional development of workflow rules can be
the same but KIM may change the process of how
the rules are put into KFS.
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?