Beruflich Dokumente
Kultur Dokumente
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
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.
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.