Audience: This is for those who are familiar with OpenText VIM.

Introduction

OpenText VIM is packaged solution for managing invoices. With OpenText VIM one can better
manage the workflow of the invoices, pay correct amount to vendors, create various types of
invoices, get the aging report, keep check and various validations (document type, invoice
information etc.), elimination of errors and duplicate check. Having a highly configurable design
allows VIM to accommodate various business scenarios and cater needs to various organizations.

VIM preprocess data before creating SAP document. Once system validates all the business rules
and pass the document then document in SAP is created. DP comprises of following:

Components Description
Document Type Highest level attribute. It determines screen layout and SAP
transaction to be called.
Process Type Each document type needs at least one process type. It affects the
process flow. It determines initial actors and collaboration options
available to actors.
Business Rules Sets of logical conditions required for validating data from external
systems.
Roles Grouping of actors in various categories
Options and The two basic options are: Actions and Referrals. Actions are based
option types on transactions or workflow tasks.
Duplicate Check For configuring different duplicate check logic
infrastructure

Configuring DP document types

OpenText provides standard document types for most of the scenarios however one can create
a custom document type by following below steps:

1. Create SAP ArchiveLink Doc Types: Go to T-Code OAC2 and create new SAP ArchiveLink
document type by providing values for Document Type, Description and Document Class.
It is recommended to maintain one SAP ArchiveLink for each DP doc type even if the process is
same as it allows separation of database and custom functions.

2. Create new DP Doc Type:

a. Go to T-code /n/OPT/VIM_1CX1

b. Click on ‘New Entries’ button (In case you wish to edit existing one then double click on the
document type)

c. Enter following details: Description, Document Index Type (Indexing using OCR, Online
Indexing, No Indexing, and Indexing using IDOC), Invoice Type, Number Range, SAP FI Doc type,
Archive Doc Type, Line Item Data, Duplicate Check Group, Duplicate Check Role, Default
Process type, Posting Role, Rescan Role, Check Display Index Data checkbox, Check Skip
Dashboard checkbox and Check Display Image checkbox.
NOTE: Indexing is a process of filling up the invoicing details in the DP document.

3. Define Process Type:

a. Got to T-Code /n/OPT/VIM_1CX1. Select the created DP Document Type

b. Double Click on Document Process and select the process type. Click on Details button
 c. Check the Active checkbox button. Select the value of BDC transaction ID and Background
Tran ID (BDC transaction ID is used to process an SAP transaction to create SAP document in
user context. Background Tran ID is used to process SAP transaction to create SAP document in
background). Enter value of Autopost flag (X: for background processing) and parking reason.

4. Configure Index screen option:

a. Go to T-Code /n/OPT/VIM_1CX1. Select the created DP Document Type.

b. Double click on Index Screen Option and click on New Entries Button.

c. Provide following details: Process Type, Description, Current Role (Role which processes
the Work Item), Check on Allow Changes check box, check Show Duplicates check box, select
Initial Tab (Dashboard and Index Data), Select Enable Simulate in case you want to skip certain
business rules, check Disable Obsolete check box in case you want to hide obsolete button in
dashboard and check Disable Rescan check box in case you want to hide Rescan button in
dashboard.

5. Configure Automatic Image Display:

a. Go to T-Code SM30 and enter /PTGWFI/Z_CONST in Table/View and Click Maintain.

b. Under product code 005 double click constant DASHBOARD_IMAGE_AUTO. Enter value X
and save.

6. Define Process Type determination sequence:

a. Go to T-Code /n/OPT/VIM_1CX1. Select the create document type and double click on
Proc. Type. Det. Sequence.

b. Enter following details: Step Id, Process type, check Exclude from Simulate checkbox to
exclude business rule from simulation and check Bypass possible checkbox to enable bypass
of business rule

c. Select the step and double click on Sequence Steps. Enter value for Step Sequence, Field
Name for the field that needs to be validated, check type (Table Field, Check Function, Constant
Value, Required Field)
7. Maintain PO line Determination: When data is captured from external system then PO line
number might not be supplied thus this step helps to determine the PO line number in such
scenario.

a. Go to /n/OPT/VIM_POL

b. Enter PO Line Det. ID (should start with 1), Check Function (custom function to determine
PO line number. It is blank by default and OpenText standard function module is used).

c. Double click on PO Line Determination Fields and maintain fields you to bed used for PO
line determination and save.

d. Go to /n/OPT/VIM_1CX1. Double click on Document Type and enter the value for
Determination Logic ID. Save.

8. Maintain Tax Code Determination:

a. Go to T-Code /n/OPT/VIM_1CX1. Double click on Document Type and select the radio
button for required option. In order to get the tax code from vendor master then select ‘Tax
Code from Vendor Master’.

b. In case tax is determined using OpenText tax table (table: /OPT/VIM_TAX_CFG) use t-code
/n/OPT/VIM_BL_TAX_CFG
 c. Select applicable checkbox for tax calculation (Auto Calculate Tax, Allow Zero Tax Rate, and
Allow without Rate).

9. Configure Duplicate Check: This is to check in case a duplicate document is created. After
identifying the document can be routed back to the predefined role for further processing.

a. Go to T-Code /n/OPT/VIM_1CX5

b. Click on New Entries button and enter the Duplicate Check Group number, Description,
Duplicate Check Type (Function Module and Index Data Field) and Ext. Dup. Check Function.
Select Run Duplicate Check in Central System
 c. Select the created group and double click on group field and mention the fields for
duplicate check

10. Determine PO invoices by Vendor Table: Table /OPT/VT_DOC_DET contains vendors that
send PO based invoices. Vendor can send invoices without providing PO number. If vendor is
not found in this table then system checks for PO number.

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

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 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.
Above screen shot is of the old CoA. T-code /n/OPT/VIM_7CX1

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

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