OpenText VIM: Roles creation By Pankaj Pareek

Roles in VIM is different from SAP workflow roles. Role in VIM is used to classify the users based on the
business activity they are involved in. In VIM roles are based on the product code. VIM offers following
product codes:
1. 005: Product code for Document Processing (DP) based activities
2. LIX: Product code for Logistic Invoice Verification (LIV) process (PO parking or PO blocking)
3. PIR: Product code for Non Purchase-Order parking workflow

Below are the scenarios for the better understanding of the relationship between roles and product codes.
Scenario 1: The document should get blocked if there is price discrepancy for PO based DP document.
The document should go to Account Payables Processor (Role will be AP_PROC) to review and approve
the price discrepancy. Which product code will be used in this scenario?
Solution: Role AP_PROC will be created against product code LIX as LIX is for PO blocking.
Scenario 2: If there are any issues with DP document where it violates any business rule (say currency
mismatch) then the document should go to Account Payables Processor (Role will be AP_PROC) for
further processing. Which product code will be used in this scenario?
Solution: Role AP_PROC will be created against product code 005 as 005 is for DP processing.
Following steps are involved in role creation:

Define Roles: Roles can be defined by using T-Code /n/OPT/CP_9CX5 and by providing following inputs:
1. Product Code: 005 or LIX or PIR
2. Role: It is the responsible party or role that we want to create.
3. Description: It is the description of the role.
4. Function Module: If any FM is applicable
5. Key Determination: Uncheck it if the role will be based on organization data such as Company
Code, Plant etc.
6. Object Type
FM, Key Determination, and Object Type are used based on the template. Please refer Role Template for
more details on them.

Define Role Templates: Template helps to determine the role applicable in a workflow. Roles
can be Static, Semi-Dynamic or Dynamic. If the role is determined only on the basis of certain
parameters like Company Code or Plant then the template is Static. If it is determined based on
a certain structure like Organization Hierarchy then it is Semi-Dynamic and if it is determined
based on function module then it is Dynamic. Role template can be maintained by using T-Code
/n/OPT/CP_9CX2.
Following parameters are provided:
1. Template ID: ID of the template that you wish to create
2. Description: Description of the template
3. Type (Static, Semi-Dynamic or Dynamic). Based on the type we select Key Determination (for
Static), Org Unit (for Semi-Dynamic) and FM (for Dynamic).
4. Allow Org:
5. Agent Type
6. Agent ID
7. Function Module

Template fields are then maintained so that system can determine the role based in runtime on
the fields mentioned in the template. Following parameters are provided:
1. Field ID: Fields that will be used to determine the role
2. Ref. Table: Table which will be referred for fetching the field

3. Ref. Field: Technical name of the field in the Ref. Table

4. Search Help
5. Allow Range
6. Wild Card

Since templates can be reused for different product codes or roles hence template field
details are maintained by providing product code, object type, and Attribute.

Assign Templates to Role: We have now defined roles and templates. We now have to
assign templates to the role so that the role can be determined based on the template which
is assigned to it. A role can be assigned with more than one template however at a time only
one template can be active. This can be done by using T-Code /n/OPT/CP_9CX2 and
maintaining values for following:
1.
2.
3.
4.

Product Code: Either 005, LIX or PIR

Responsible Party: These are the roles what we have defined.
Key Determination: Template ID
Active: Checking this box will make the template ID active.

Maintain Role Determination Settings: We have now mapped roles and

template but we still need to define the values that will be used in runtime for role
determination. This is carried out by using transaction /n /OPT/CP_9CX4. For each
role under a product code, we need to maintain the values of the fields or Org unit
or FM (depending upon if they are Static, Semi-Dynamic or Dynamic type) which are
defined in the template.

Maintain Chart of Authority (CoA): I have given a brief explanation on CoA in my

previous document (please refer: http://scn.sap.com/docs/DOC-57917). In version 7
invoice approver can be determined based on two logics:
1. Simple approval: It is same as the old version i.e. gross amount and
managers information.
2. Level based approval: Approvers are determined based on levels and packs.
Levels are defined for approval limits i.e. each level will have different
amount range that can be approved by that level. For example: We can have
different set of approvers for amount ranges: $0 $5000, $5000 $10,000,
$10,000 $20,000 and so forth. Also, they can be further divided based on
cost center. For example: for the amount range level of $10,000 to $20,000
we can have different approvers for different cost centers.
NOTE:

1. CoA is used for Non-PO scenarios. For PO scenarios, CoA is not used. The approver (first and
only) in PO scenario is determined based on baseline implementation.
2. CoA can be configured to include complexities like approvers can be determined based on
amount limit, company code, cost center etc.
3. One can only define the user details in CoA and use a custom logic to determine the approver. In
such a scenario all the approvers should be maintained as users in CoA and other tabs in CoA
(Coder and CoA details) can be left empty.

Prerequisite: Cost objects are maintained for view /OPT/BL_T401V and fields for view
/OPT/BL_T402V.
T-code to access old CoA is /n/OPT/VIM_7CX1 and to access new CoA is
/n/OPT/VIM_APPR_COA. In new CoA, there is a tab for approval limit. In this tab, we can
maintain level based approval configuration.