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

2. 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

3. 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.

4. How is your institution unique? - Special reporting requirements? - Out of the ordinary accounting policies or rules? - Complex workflow needs?

5. 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

6. Account

7. Account Attributes (green)

8. Account Extended Attribute (blue) Extension Table Extended Attribute Tables

9. 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.

10. III. How do I create an Extended Attribute? Configuring KFS to add an Extended Attribute involves both functional and technical resources.

11. 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

12. 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

13. 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)

14. 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

15. 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.

16. Technical Steps Step 1 – Update the Data Model  Oracle Database – add tables

17. 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

18. 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.

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

20. Extended Attribute Main’t Doc Functions the same as other KFS maintenance docs

21. Values – Revenue Source Institution Defined Values

22. Account Maintenance Form Appears on Associated eDocs

23. Account Lookup Document Search Lookup and Search Results

24. Security Rule Restrict access to the Extended Attribute maint doc

25. IV. Assign Functionality to an Extended Attribute Creating Business Rules and Workflow - Exploring the functionality - Translating the functionality - Technical from 30,000 feet

26. 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.

27. 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.

28. 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)

29. Technical Steps – Business Rule Step 1: Create parameters related to the values defined in the if/then statement.

30. 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

31. MSU Business Rule Error Message If Revenue Source Code = FD, and SubFund Group Code = MSUE, Then Object Subtype Code ≠ SC

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

33. 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

34. 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.

35. Workflow (technical) Step 1: Create a Rule Attribute Specify the attribute fields on which to base the rule template.

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

37. 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

38. Workflow (technical) DistributionOfIncomeAndExpenseDocument KualiFinancialDocument Distribution Of Income And Expense org.kuali.workflow.postprocessor.KualiPostProcessor KUALI_ROLE_SUPERVISOR KUALI_ROLE_ADMINISTRATOR KUALI_ROLE_SUPERVISOR ${application.url}/financialDistributionOfIncomeAndExpense.do?methodToCall=docHa ndler true 1

39. Workflow (technical) Adding the route node automatically updates Rule Quicklinks

40. Workflow (functional) Step 4: Create the rule.

41. Workflow (functional) Step 4: Create the rule (cont’d)

42. MSU Workflow Demo

44. 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.

45. 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.

46. Questions?