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:

/wp-content/uploads/2016/04/1_933444.jpg

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.

/wp-content/uploads/2016/04/1_1_933594.jpg  

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

/wp-content/uploads/2016/04/2_933585.jpg

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

/wp-content/uploads/2016/04/3_933590.jpg

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. 

/wp-content/uploads/2016/04/4_933591.jpg

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. Product Code: Either 005, LIX or PIR
  2. Responsible Party: These are the roles what we have defined.
  3. Key Determination: Template ID
  4. Active: Checking this box will make the template ID active.

/wp-content/uploads/2016/04/5_933593.jpg  

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.

/wp-content/uploads/2016/04/6_933595.jpg

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 manager’s 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.

/wp-content/uploads/2016/04/7_933605.jpg

Above screen shot is of the old CoA. T-code /n/OPT/VIM_7CX1

/wp-content/uploads/2016/04/8_933606.jpg

Above screen shot is of the new CoA. T-Code /n/OPT/VIM_APPR_COA


Substitute setup: VIM allows setting up of substitute for other users by executing T-Code /n/ORS/MAIN_SUBS

/wp-content/uploads/2016/04/9_933607.jpg

I hope this document will be useful for basic understanding and working of roles in OpenText VIM

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply