OpenText VIM: Basic configuration for Document Processing (DP) document types

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 externa

systems.

Roles

Grouping of actors in various categories

Options and option The two basic options are: Actions and Referrals. Actions are based
types
transactions or workflow tasks.
Duplicate Check
infrastructure

For configuring different duplicate check logic

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.

OpenText VIM: Invoice Approval Process

and Chart of Authority
Introduction:
The document provides the overview of invoice approval process cycle in OpenText VIM for both PO
and Non-PO invoices along with important configuration steps involved. It also covers linkage of
process types and chart of authority in invoice approval process along with their configurations.

Invoice Approval Process:

OpenText VIM provides the facility to approve the invoices before they are created in SAP. The
approval system is easily configurable and highly customized with provision of multi-level approval.
Approval process is available for both PO and Non-PO based invoices. Non-PO invoices support
multilevel approval. PO invoices have only one step approval but can be customized for multilevel
approval. Approval can be delayed by sending the invoice to AP Processor first. Approval process
ends when the invoice is approved and posted or deleted or rejected.

Important roles involved in invoice approval process:

1. Coder: Person responsible for entering accounting data.

2. Requester: Person who has requested the goods or services.
3. Approver: Person responsible for approving the invoices.
4. AP Processor: Member of Accounts Payables team responsible for dealing with invoices.
NOTE: Above mentioned roles are the basic roles involved in the IAP however one can create
additional roles.

Figure 1: Invoice Approval Process

Approval can be handled at two stages:

1. DP processing stage: Process type needs to be configured accordingly (steps to configure the
process type are written below). Approval workflow can be started by clicking Submit for
Approval option.

2. After conversion of DP document into SAP parked invoice: Appropriate parking reason has to
be provided. Create parking reason if required. Based on the parking reason workflow starts.
Approval workflow is triggered by changing the parking reason. Trigger points can be
configured for this by going to /n/opt/spro > Configuration > Non PO Processing > Invoice
Approval Process > Approval Workflow > Additional Configuration Web Approval. Below is
the screen shot.

Figure 2: Configuration for document parking reason

BLOCKRSN 9 is for PO based invoice and V is for Non-PO based invoice. Start Approval
Immediately starts the workflow immediately without delay.

Configure Process type: A process type needs to be created for approval when approval is required
at DP processing stage. Process type can be defined using transaction /n/opt/vim_8cx1. Below are
the important fields:

Process type number: 5 digit unique number.

Process type: Description of Process type.

Initial Actor: User that gets the work item.

Initial Actor Function: If no initial actor is available then it is picked from the function module
specified here.

Is Exception: If this check box is selected then process type will be not be relevant for
automatic document processing.

Auto Start: If this check box is not checked then Initial Actor manually starts the workflow else
it is automatically started.

Create SR: If this is checked then automatic service request is created.

Country Check: Checks country specific configurations.

Workflow Type: Opentext Approval Workflow or External Workflow can be selected for this.

Task ID

Binding Function

Max Retry Counter

Retry Time (Minutes)

Mail Config ID

Function Module for Rcvr Email

Function Module to send email

Logical System: Enter the name of the system where the external workflow is supposed to
run.

Figure 3: Process Type

To receive and send email the configurations are done in the process type for respective function
modules.

IAP Process Configuration:

Below are the important steps involved in the invoice approval configuration.

Defining Multi Level Approval: For PO invoices a custom extension is required. If the approver
rejects the invoice then it is send back to previous approver. If the first approver rejects the
invoice then it is send to AP department. The user from AP department has the option to
select the approver if process is started from DP dashboard. Approvers are maintained in
Chart of Authority.

Driving the Approval Flow for DP Invoices: The process starts when invoice gets the process
type for approval or Submit for Approval button is clicked. For Non-PO invoices the initial
approver is usually entered in the indexing screen in the Email ID field. For PO invoices the
approver is the requisitioner.

Driving the Approval Flow for Parked Invoices: The process starts when document is parked
or Submit for Approval button is clicked.

Defining Approval Hierarchy and Approval Level: Approval hierarchy can be implemented by
either using OpenText delivered approval hierarchy table or customization as per business
needs. OpenText delivered approval hierarchy table allows defining the approver, coder and
respective hierarchy for them along with approval amount, currency, company code and plant
for which the user is authorized to approve.

Defining the Expense Type: For few expenses (Marketing Expense, Office Supply,
Communication, Utility, etc.) a different path might be required and for this expense types are
configured which allows defining different approval limits for different expense types. Expense
type can be created by going to /n/opt/spro and then to LiveLink VIM - Configuration > Non
PO Processing > Invoice Approval Process > Setup Approval Chain > Expense Types >
Maintain Expense Types. Create the expense type, provide description and indicate if
approval is required for the expense type.

Figure 4: Expense Types

Defining Approval Access Rights: Some of the access rights are: Approve, Coding,
Coding_Display, Coding_Delegation, Override, Look_ahead and Configuration

Configuring the Email Notification: Approvers will receive email notifications if any new invoice
is waiting for their approval for this method Get_Approver_List of business object type
/ORS/INVAP is used to get the approvers and method SENDEMAIL is called to send the mail.
The actual function to create the send request is /PTGWFI/CP_SENDMAIL. The body of the
mail can be easily configured.

Configuring the Certify Message: When approver approves the invoice then a message is
displayed. This can be configured at /n/OPT/SPRO transaction and follow LiveLink VIM
-Configuration > Non PO Processing > Invoice Approval Process > Technical General >
Invoice Approval Configuration. Maintain the text id here that needs to be shown post
approval.

Figure 5: Certify Message Configuration

Configuring General Ledger Fields and Search Help for Web Screen Fields: This can be done
at LiveLink VIM - Configuration > Non PO Processing > Invoice Approval Process > Financial
Processing > Online Coding > GL Titles.

Figure 6: General Ledger Fields and Search Help for Web Screen Fields

Chart of Authority:

Chart of Authority (COA) is required to setup the approval hierarchy for Non-PO invoices. In case of
PO
invoices
baseline
implementation
determines
the
requester as the first approver and is the only approver unless a customization is done for PO
approver. In COA one can configure the approval hierarchy, the approval limit and coder for the
invoice approval process. T-code to access the COA is /n/opt/vim_7cx1. There are three views
available in COA.

User Details View: It contains the general details for all the users like user id, users manager
id, if user is allowed for bulk approval or not, department of user, email address, telephone
number, default coder etc. If the requirement is to allow the approval to go first to the approver
and then to the manager then maintain the manager for the user in this view without manually
entering the user in COA Details View. The data for the user is automatically populated in
COA Details View.

Figure 7: User Details View

COA Details View: In this view the data for approval are maintained like approval amount up
to which approver can approve, currency for which approver is allowed to process approval,
company code and cost center for which approver is authorized etc. Thus it basically controls
the approver limit and scope of approval.

Figure 8: COA Details View

Coder Details View: This is where coders are maintained for the requester. Thus due to
this configuration the system knows from where to pick the coder for a particular requester. If
the Default check box is ticked then it means that user is always a coder.

Figure 9: Coder Details View

The user details contains all the users and the managers to whom invoice will go for approval. The
approval limit is set in COA details and corresponding coder can be determined from coder details.
Thus process type helps to know is approval is required or not and COA helps to know who will be
approving.