Kuali Rice 2.0.0-m6 User Guide

Below the list of search results, there are links for exporting the search results list to a different format. Click:

The Ad Hoc Recipients tab allows you to interrupt the normal workflow routing of a document and include other individuals or groups in its routing path. Ad Hoc Routing does not replace the normal workflow routing of the document; it adds people or groups to the normal routing.

The Ad Hoc Recipients tab has two sections: Person Requests and Ad Hoc Group Requests. Use one or both of the sections to route the document to an additional person, group, or both.

Figure 1.1. Ad Hoc Recipients Tab

Figure 1.2. Person Requests Section of the Ad Hoc Recipients Tab

When you click the Add button, Rice adds this person to the routing path for this document.

Figure 1.3. Ad Hoc Group Requests Section of the Ad Hoc Recipients Tab

Follow the same guidelines as the Person Requests Section of the Ad Hoc Recipients Tab, using a group instead of a person.

The Document Overview tab contains the short description for a document and two other optional fields. This tab is used for many documents.

The Notes and Attachments tab has fields for user notes, attachments, and system-generated remarks about the document. The number of notes and/or attachments for the current document is displayed on the tab, in parentheses next to the tab title.

The Route Log tab displays details of the workflow status.

Figure 1.4. ID Section of the Route Log Tab

Figure 1.5. Future Action Requests Section of the Route Log Tab

Once a document is Saved or ENROUTE, this section shows the action requests that Workflow will generate in the future, based on the information currently on the document.

Future requests appear in the order in which they are to occur.

As described above, you can use the Action List Preferences page to tell KEW to automatically update (refresh) the information on your Action List on a regular schedule, such as every 15 minutes. You can also click the Refresh button near the top of your Action List page to update the page at any time.

If you have a large Action List, the Filter function can help you by displaying only action requests of certain types. To use the Filter function, click the Filter button in the top right corner of your Action List page:

This displays the Action List Filter page:

When you have used a filter on your Action List, you can see a Clear Filter button at the top of your page:

Click this button to display all of your action requests again.

Remember, you can click the Filter button at the top of your Action List page to return to the Filter page and change or Reset your filters.

In KEW, you may delegate, or give, your request authority to other people. For example, if Joe is the fiscal officer for an account but he doesn't actually approve documents, he may delegate his approval authority to Jane. Both Joe and Jane can now take actions on Joe’s action requests

If Jane approves a document as Joe’s delegate, Joe's action request is satisfied. If Joe approves the document, Jane's action request is satisfied.

You can combine a role request with a delegate. In fact, in the previous example, the action request that is sent to Joe as a fiscal officer is really a role request. The action request tree for that scenario is:

This tree is three levels deep and shows a role delegating to a user. You can also have a role delegate to another role.

When action requests are created, they are in the Initialized state. They stay in this state until KEW determines that they need to be Activated. When a request becomes Activated, it appears in the user's Action List.

When action requests are created, they can be set to ignore previous actions or not.

During request activation, if the Ignore Previous flag is false and KEW determines that a previous action satisfies the current request, it will Deactivate the request instead of Activating it. Activation begins at a root request, but Deactivation begins at the request where KEW finds that a satisfying action has occurred if that request is set to not ignore previous actions.

When a user takes action on a document, that action may start the deactivation of other action requests on the document. For example, if Joe has a pending request and he takes an Approve action on it, his request is deactivated. Request deactivation changes the status of the request from Initialized or Activated to Deactivated.

If Joe’s action taken causes other action requests to be Deactivated, his action taken is associated with all of the requests that it Deactivates.

Unlike Activation, Deactivation always starts at the request that was satisfied by the action taken. For example, if Joe is delegating to Jane and Jane issues an Approve action on her request, Deactivation starts at Jane's request. However, if Joe issues the Approve action, Deactivation starts at the parent.

If there are no roles set to "All Approve" on an action request, one action can Deactivate the entire request tree. This is because KEW works up and down the tree, Deactivating requests as it goes.

However, when there is an "All Approve" role, requests for all parties within the role must be Deactivated before the parent role request is Deactivated. For example, if we have an "All Approve" role request with three children requests, when one of the users takes action, their request is Deactivated, but since there are two other requests that still need to be satisfied, the Deactivation cannot go back to the parent role request. When the last of the three users has taken action, the parent role request is Deactivated.

Use this action to satisfy an Acknowledge action request. When you take an Acknowledge action, it usually means that you have examined the document. Acknowledgement provides no real authority over the document; you can only take the Acknowledge action on this document.

When you take an Acknowledge action, KEW finds all pending acknowledge requests for that document that are routed to you and Deactivates them. It then records an Acknowledge Action Taken and associates it with the Deactivated requests. You may take an Acknowledge action even if you have no Acknowledge Action Requests.

Use this action to satisfy an Approve or Complete action request. When you use an Approve action, it means that you have looked at the document and approve that transaction.

When you use the Approve action, KEW Deactivates all pending approve or complete requests that have been routed to you for this document. You may take an Approve action even if you have no Approve or Complete action requests.

Use the Blanket Approve action to force a document to complete a set of action requests. This allows certain users to "push" a document through its routing. To take this action, you must have the appropriate KIM Permission (or be in the Blanket Approve Group which is set in the Document Type, but that is a deprecated feature). Unless you select a specific node (point in the document’s routing path) when you take a Blanket Approve Action, KEW finds all pending Approve or Complete requests at the current level in the request tree and Deactivates them. It records a Blanket Approve Action Taken and associates it with each of the Deactivated requests.

Then, KEW sends Acknowledge action requests to each person whose action request was satisfied by the Blanket Approve. It does this for all levels in the request tree until it reaches the end point set in the Blanket Approve Action or it reaches the end of the request tree.

Use this action when a document is no longer valid and you need to cancel it. You must have a pending Approve or Complete action request on the document before you can Cancel it. Cancelling a document is similar to Disapproving it except that the Cancel action does not send out notifications.

When you take a Cancel action, KEW finds all pending requests on the document and Deactivates them. It records a Cancel Action Taken and associates it with the Deactivated requests. Then it sets the document's status to CANCELLED and the document is effectively dead.

Use this action to satisfy an FYI action request. You usually get an FYI just to notify you about a document. You don’t need to take any action on an FYI request, but if you want to remove that FYI and document from your Action List, take the Clear FYI action.

When you take the Clear FYI action KEW locates all pending FYI requests on this document that are routed to you and Deactivates them. It then records an FYI Action Taken. You must have a pending FYI request on a document to use the Clear FYI action.

Use this action to satisfy an Approve or Complete action request. When you use a Complete, it means that you have looked at the document and completed any of the necessary information on the document so it can proceed. Complete action requests are typically created as the result of a Save action or in response to an Exception Routing request.

When you use the Complete action KEW finds all pending Approve or Complete requests that are routed to you and Deactivates them. If the document is in the Exception state, it changes it back to Enroute. It then records a Complete Action Taken. You may take a Complete action even if you have no Complete or Approve action requests.

This action creates a new document in KEW of the chosen Document Type. This action does not record an Action Taken of any sort but simply begins a new document and assigns a document ID to it. The document begins in Initiated status. The Document type determines how the document is routed and what must be done for it. For example, an expense report might be routed (sent) to two or three different people for approval before it is paid.

When you have an Approve action request, you use a Disapprove action if the document does not meet the approval criteria. You must have a pending Approve or Complete request on the document before you can Disapprove it. Disapproving a document is similar to Cancelling it, except that Disapproval sends out notifications.

When you Disapprove a document, KEW finds all pending requests on the document and Deactivates them. Next, it creates Acknowledge notification requests to all users that had Approve or Complete action requests at the current node and all previous nodes. It also sends an Acknowledge notification request to the initiator of the document. Then the document's status is set to Disapproved and the document is effectively dead.

This action simply enters a message on the document. It records an Action Taken but it is never associated with any action requests. This action displays a message on the document in the Route Log.

This action moves a document either backward in the route path or forward. Moving the document backward works like the Return to Previous Node action and moving the document forward works like a Blanket Approve action. The difference between these is that the Action Taken is recorded as a Move action.

Use this action to move a document to a previous node in the route. You must have a pending Approve or Complete request on the document before you can use this action.

When you use this action, KEW Deactivates all pending requests on the document and sets the current node on the document to the previous node that you requested (this is called the target node). It records a Return to Previous Node Action Taken and associates it with the Deactivated requests. Any requests on nodes between the current node and the target node are removed, effectively erasing them. KEW then sends the document through again to recreate requests on the target node. This way a document is "returned" to a previous node, rolling it back to its previous state at that point in the route.

Use the Route Document action to route an Initialized or Saved document to other users. Only the initiator of the document can take this action unless the user has an "Initiate Document" KIM permission (or initiator_must_route policy is set to false in the Document Type, although this feature is deprecated). The Action Taken for a Route Document action is Complete.

When you use the Route Document action, it Deactivates all pending requests for the initiator of the document and it associates a Complete Action Taken with the Deactivated requests. The document’s state is then set to Enroute.

Use this action to put a newly created document in the Action List of the document’s initiator. You can only use this action on a document in an Initiated status. When you use this action, KEW creates and Activates a Complete action request for the document’s initiator and then changes the document’s status to Saved.

Superuser actions let you move a document past workflow nodes where it may be held up because another user is unavailable to take action on it or due to a system problem. Superuser actions are an administrative tool and safety net. Superusers are designated with a KIM Permission (or they are listed in the Document Type, but this feature is deprecated).

To use the Superuser functions, go to Document Search (it is a link in the left menu) and click the Superuser Search link.

Now, do a normal document search for the document on which you need to perform a Superuser action. When you find the document, click the Document/Notification Id link. If you are authorized to perform a Superuser action on this document, this takes you to the Superuser page. Otherwise, KEW displays a message that you are not authorized to take Superuser action on this document.

This action fully approves a document, Deactivating all remaining routing requests. KEW also records a Superuser Approve Action Taken and associates it with the Deactivated requests. The document's state changes to Approved and the document is scheduled for processing. The document status automatically changes to Final when it goes into the Workflow Engine.

This action approves the document through all nodes up to (but not including) a specified node. When the document gets to the specified node, requests are created as usual. This action is exactly the same as Blanket Approve except that no notification requests are created from the Superuser Approve Node action.

This action approves a single pending Approve or Complete action request. This works the same way as a standard Approve action except that the Superuser is acting in place of the responsible user.

This action cancels the document. This action works exactly the same way as the standard Cancel action except that the Superuser does not need to have a pending request to Cancel a document.

This action disapproves the document. This action works the same way as the standard Disapprove action except that the Superuser does not need to have a pending request to perform the action. Also, on a Superuser disapprove, KEW does not send notification requests.

This action returns the document to a previous node in the route path. This action works exactly the same way as the standard Return to Previous Node action except that the Superuser does not need to have a pending request to perform the action.

You can go to the eDocLite Lookup by:

On the eDocLite lookup page, users can search for an eDocLite document based on several criteria:

You can use the above criteria to limit your search results. A search will produce a list of one or more results that look similar to the following:

Clicking Create Document on any line takes you to the eDocLite document screen where new documents can be created. The line item you choose will result in that document being used as a template for the new one you are creating. More information on this follows in the section called Create New eDocLite Document.

Clicking any underlined Id will take you to the eDocLite Inquiry screen for that document.

Standard in KEW there is one eDocLite for electronic routing, and new eDocLites can be added based on business requirements. Some of the functions that eDocLites are used for in business include:

The Document Header contains the following fields:

This portion of the document is where the user identifies the routing and complete business function.

This area is used to add annotation and choose action to be taken on this eDocLite document. Annotation is the comments associated with the routing process. You can add them to different nodes of the routing process and take actions on an eDocLite by adding annotations. The annotation appears in the route log of eDocLite as comments. Notes are the comments associated with this specific eDocLite form and appear with the form and not in the route log.

The following is one example of an eDocLite form:

eDocLites are highly customizable. New eDocLites can be designed for new business and functional requirements. The document header and routing annotation and notes parts will be same or similar, the form will be different.

eDocLites can be designed to include following functions:

The Routing Rule Delegation screen you see when creating a new Rule has eight tabs:

The Delegation Details, Delegate Rule, Persons, and Groups tabs are discussed in the sections that follow. The remaining four tabs are commonly used throughout Rice and are described in the Common Features and Functions section of the User Guide.

The Delegation Details tab is where you associate a Parent Rule with a Delegate Rule. It is also where you assign the Reviewer role.

The Delegation Details screen is displayed differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

The information displayed is a copy of the information for the Parent Rule. Descriptions of these fields are below. Change this information as needed, then click the submit button to create this new Rule.

The version you see when editing or copying a Rule looks similar to this:

When you first see this version, the information in both columns is the same. You can modify the information in the fields in the right column, but not the left column. After changing the information appropriately in the right column, click the submit button to save your changes to this Rule.

The fields are the same in both versions of the screen:

The Delegate Rule tab is displayed differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Enter the appropriate information for your new Delegate Rule in these fields. There are descriptions of each of these fields below.

The version you see when editing or copying a Rule looks similar to this:

When you first see this version, the information in both columns is the same. You can modify the information in the fields in the right column, but not the left column. After changing the information in the right column appropriately.

The fields are the same in both versions of the screen:

Rice displays the Persons tab differently, depending on whether you are creating a new Rule or editing/copying a Rule. This tab lets you add people to the Rule and set the type of Action each person needs to take under this Rule. The version of the Persons screen that you see when creating a new Delegate Rule looks similar to this:

Enter the appropriate information for the Persons section of your new Delegate Rule in these fields. There are descriptions of each of these fields below.

The version you see when editing or copying a Rule looks similar to this:

Use the top portion of this tab to add a new Person to this Rule and set the Action that Person needs to take and its Priority. Use the lower portion of this tab to change existing values for this Rule.

The Groups tab differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Enter the appropriate information for the Groups section of your new Delegate Rule in these fields. These fields are described below.

The version you see when editing or copying a Rule looks similar to this:

Use the top portion of this tab to add a new Group. Use the lower portion to change existing information for a Group.

In the default implementation of Rice you can find the link to the Routing Report on the "Main" tab of the portal inside the "Workflow" pane. If for some reason the link is not visible on the "Main" tab you can still directly navigate to the Routing Report. To access the tool directly, replace the last part of the Rice Portal URL (portal.jsp) with kew/RoutingReport.do (for example, http://my.kuali.host/kuali/portal.jsp would become http://my.kuali.host/kuali/kew/RoutingReport.do). The following page is displayed:

The first thing to do is select the rule template to use for the test from the drop-down list. When you select a template the page will update to show the routing data that you need to enter to run the test:

The data entry fields for the routing data use the standard controls described in the Standard Buttons on Lookup Screens document. Here is the example with the routing data:

The specific information you need to enter is specific to the rule template you selected. Once you have entered the information, click the button to display the report:

The upper section of the report (labeled “ID: 0”) contains the basic document information fields as if this was an actual document; several fields are blank since there is no actual document.

The lower section of the report (labeled “Pending Action Requests”) contains the routing that the document would be given. Clicking the button on any action displays more detail of the action:

The Rule Maintenance Document Type Document screen you see when creating a new rule is composed of seven tabs:

The screen you see when you are editing an existing Rule includes an additional tab called Roles.

The Rule, Persons, Groups and Roles tabs are unique and are discussed in the sections that follow. The remaining four tabs are commonly used throughout Rice and are described in the Common Features and Functions section of the User Guide.

The Rule tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

The version you see when editing or copying looks similar to this:

The Persons tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

The version you see when editing or copying looks similar to this:

The Groups tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

The version you see when editing or copying looks similar to this:

The top portion of this tab is used to add a new Group while the lower portion is used to change existing values.

You can go to the Person Lookup screen from many Kuali screens by clicking the field search button next to a Name-related field. How you get to the Person Lookup screen and your Role in Kuali determine what you see and what you can do there.

If you have permission to use the Administration screens in Rice, you can go directly to the Person Lookup screen:

Only people with the appropriate role can initiate routing for Person documents.

The Person Document includes Document Overview, Overview, Contact, Privacy Preferences, Membership, Ad Hoc Recipients, and Route Log tabs.

The Document Overview tab combined with the Overview tab identifies the Person as a unique combination of Entity and Principal ID.

Additional information on the Document Overview Tab can be found in the Common Features and Functions section of this User Guide.

The Overview tab identifies the Person as a unique combination of Entity ID and Principal ID. It also contains information about how this Person is affiliated with your institution. Two types of affiliations—Staff and Faculty—contain additional data fields to further define a person’s relationship with your institution.

The instructions below assume that you are manually entering this information. Many institutions either have this data fed from an existing Person database or simply override this information with existing Person data.

The Contact tab records the names, addresses, phone numbers, and email addresses associated with this Person. Any Person record can store multiple contact information records of each type (name, address, phone number, and email address). You must select one value of each type as the default for that Person record.

The Privacy Preferences tab allows you to suppress the display of (hide) fields on the Contact Tab.

The Membership Tab allows you to associate a person with groups and roles and, by extension, with KIM permissions and responsibilities. Assigning a person to a role is the most direct way to give him or her KIM permissions and responsibilities.

The Membership tab is divided into two sections, one for managing assignments to Groups and another for Roles.

For information on these fields please refer to the Group Maintenance section that follows.

If you are creating a new Group and have clicked the Create New button on the Group Lookup screen, Rice displays the KIM Type Lookup screen. Before Rice can generate a new Group document, you must search for and select an existing Type for the new Group.

The search results list includes the same fields as the Lookup screen. The search results are displayed below the search fields on the Lookup screen.

To select the Type you want to use for your new Group, click the return value link for that Type. KIM will copy the Type information to use in creating your new Group.

The KIM Type Lookup screen displaying a search result:

The Group document includes these tabs:

The Overview and Assignees tabs are described below. Information on the others can be found in the Common Features and Functions section of this User Guide.

This screen may have three or four tabs of information, depending on the Role. The first three tabs are Overview, Permissions, and Responsibilities. KIM only displays the fourth tab, Assignees, when Assignee information is associated with this Role.

Information on the fields in all of these tabs can be found in the Role Maintenance section of this user guide.

The Role document includes eight tabs:

Those contains unique information are addressed below. For more information about the Document Overview, Ad Hoc Recipients and Route Log tabs, please see the Common Features and Functions document.

The Campus Lookup screen provides detailed information about the campuses defined in your system.

To get to the Campus Lookup function, click Campus on the Rice Administration Menu.

This takes you to the Campus Lookup screen where you have the option to create a new Campus by clicking the create new button in the upper right corner under the Login box or to perform a search of campuses already defined in Rice. If you choose to create a new Campus, KIM displays the CampusMaintenanceDocument, which is discussed in the Campus Maintenance section below.

Another way to get to the Campus Lookup screen is to click the Field Lookup button next to the Campus Code field on any screen where it appears. If you do this, you see the Campus Lookup screen without the create new button.

Enter information in one or more of the fields on the Campus Lookup screen and then click the search button to see a list of Campuses that fit your search.

If you did NOT begin your Campus Lookup from the Administration menu, your list of search results looks like this:

If you did begin your search from the Administration menu, you see edit and copy as links for each Campus instead of return value. These options are explained in the Campus Maintenance section below.

Click one of the underlined column titles on the search results list to sort the list by that column. Click it again to sort the list in the opposite order.

You can also export the search results list in CSV, spreadsheet, or XML format. Click the appropriate link at the bottom of the search results list to do this.

If you did NOT begin your Campus Lookup from the Administration menu, the Return Value column has a return value link for each campus. Click this return value link for the Campus Code for which you need information and Rice goes back to the screen you were on before and automatically enters the information about that campus on the screen for you.

You can find information about the fields on this screen under Edit Campus Tab in the Campus Maintenance section of this User Guide.

Display this screen by clicking Campus Code in the search results list after you do a Campus Lookup:

You can find information about the fields on this screen in the Edit Campus Tab section under Campus Maintenance, below.

Use a Campus document for each of the different fiscal and physical operating entities of an institution. A campus may be identified as a fiscal entity, a physical entity, or both.

The Campus Type Lookup function displays detailed information about specific Campus Type Codes.

To display this screen:

There are two ways to search for information using this screen:

You can export the search results list in CSV, spreadsheet, or XML format. Click the appropriate link at the bottom of the search results list to do this.

The Return Value column has a return value link for each Campus Type Code. Click this return value link for the Campus Type Code you need, and Kuali goes back to the screen you were on before and automatically enters the information about that Campus Type Code on the screen for you.

Field information on this screen can be found in the Edit Campus Tab section above.

Use the Campus Type Inquiry screen to see the Campus Type Code and Name and the Active Indicator for a particular campus.

To display this screen:

Field information on this screen can be found in the Edit Campus Tab section above.

To create or perform maintenance on a Campus Type, click Campus Type on the Administration Menu.

From the Campus Type Lookup screen, you may either create a new Campus Type or search for an existing one.

When you search for and find an existing Campus Type (see instructions above), you have the option to edit or copy it. After you click the create new, edit, or copy button, KIM displays the Campus Type Maintenance document. This document lets you add and update Campus Types.

The Postal Code Lookup screen provides detailed information about the postal codes (zip codes) defined in KIM.

You access the Postal Code Lookup screen by clicking Postal Code in the Identity section of the Administration menu.

A search produces a list similar to the example below.

Descriptions of the fields in this list can be found in the Postal Code Maintenance section below.

Clicking edit takes you to the Postal Code Maintenance screen.

Clicking copy also takes you to the Postal Code Maintenance screen and populates some of the fields in the Edit Postal Codes tab with information from the item you copied.

Clicking a Country Code from the list takes you to the Country Code Inquiry screen.

Clicking a Postal Code from the list takes you to the Postal Code Inquiry screen.

Clicking a State Code from the list takes you to the State Code Inquiry screen.

Information about these fields can be found in the Postal Code Maintenance section below.

The Postal Code Maintenance Document defines the postal (zip) code by city and state. When you click the Postal Code option on the Administration screen, KIM displays the Postal Code Lookup screen. At this point you can perform a lookup and select a postal code to edit or click the create new button, KIM displays the PostalCodeMaintenanceDocument screen.

To create a new Postal Code, enter information in the required fields in the Document Overview and Edit Postal Codes tabs, then click the submit button at the bottom of the screen.

The County Lookup screen provides information on counties defined in KIM.

Access the County Code Lookup screen by clicking County in the Identity section of the Administration Menu.

Click the create new button to go to the County Maintenance function, where you can create a new County in Rice.

Conducting a search from this screen returns a list similar to this:

Clicking the edit or copy link in the Action column allows you to edit the county information you selected or to create a new county in Rice, beginning with a copy of the information from this county. This link takes you to the County Maintenance Document.

Clicking a Country Code takes you to the Country Inquiry function for that code.

Clicking a County Code takes you to the County Inquiry function for that code.

Clicking a State code takes you to the State Inquiry function for that code.

This screen provides a snapshot of the important information about a County:

You can find information about the fields on this screen in the County Maintenance section below.

Use the County Maintenance document to assign specific identifying codes to county names. When you click the County option on the Administration screen, KIM displays the County Lookup screen. After you select to edit a county or click the create new button, KIM displays the CountyMaintenanceDocument screen:

To create a new County, enter valid information in the required fields in the Document Overview and Edit Counties tabs, then click the Submit button at the bottom of the screen.

The State Code Lookup function provides a convenient way to find key information pertaining to states that are defined in Rice.

You can display the State Code Lookup screen by clicking State on the Rice Administration menu.

Enter information in one or more of the fields on the State Code Lookup screen and then click the search button to see a list of States that fit your criteria.

Click edit or copy in the Actions column to go to the StateMaintenanceDocument screen, where you can edit the existing State or use a copy of it as a base for establishing a new State in KIM.

Click an underlined Country Code to go to the Country Inquiry screen for that Country Code.

You can also export the search results list in CSV, spreadsheet, or XML format. Click the appropriate link at the bottom of the search results list to do this.

The State Inquiry screen provides a snapshot of the most important information defined in Rice for a State.

The State document defines the U.S. Postal Service codes used to identify states. When you choose the State option on the Administration menu, KIM displays the State Code Lookup screen. After you click edit for a State or click the create new button, KIM displays the StateMaintenanceDocument.

This screen provides information about Country Codes and is accessed directly off the Administration menu.

Performing a search on a Country Code produces results similar to this:

Selecting edit or copy in the Actions column takes you to the Country Maintenance Document screen, where you can edit the existing Country Code or use a copy of it as a base for establishing a new Country Code.

Selecting an underlined Country Code takes you to the Country Inquiry screen for that Country Code.

You can also export the search results list in CSV, spreadsheet, or XML format. Click the appropriate link at the bottom of the search results list to do this.

The Country Inquiry screen displays details about a Country in Rice. You get to this screen by clicking a Country Code in the list of search results after you do a Country Lookup.

The Country document is used to assign specific identifying codes to country names.

When you choose the Country option on the Administration menu, KIM displays the Country Lookup screen. After you select a country or click the create new button, KIM presents the CountryMaintenanceDocument screen.

Getting to the Parameter Maintenance screen requires that you have permission to use the Administration screens in KRice. You can go directly to the Parameter Maintenance screen by:

KNS Parameters can be created and edited by selecting the Parameter option on the Rice Administration screen.

After selection you will be presented with the Parameter Maintenance Document screen. The picture below is the complete screen with all tabs hidden. By default the Document Overview and Edit Parameter tabs are shown (i.e. open) when this screen is first accessed.

The system will automatically assign a new document number every time this screen is accessed. The Initiator, Status and Created information will also automatically be filled in.

The Notes and Attachments tab, the Ad Hoc Recipients tab, the Route Log tab, and the buttons at the bottom of this screen perform standard functionality as described in the Common Features and Functionality document found in the Global section of the User Guide.

The following descriptions apply to the fields in the upper right hand corner of the screen.