3-2102-163-00 - Vendor Invoice Management For SAP Solutions Administration 16.3

Vendor Invoice Management for SAP
Solutions Administration 16.3
OpenText Suite for SAP Solutions

The software described in this Workbook is furnished under a license agreement or non-disclosure agreement (the “Agreement”)
with Open Text Corporation or one of its affiliates (“Open Text”). The software may be used or copied only in accordance with the
terms of the Agreement. The information contained in this Workbook is the valuable property of Open Text and represents trade
secrets of Open Text. No part of this Workbook may be copied, reproduced, translated or transmitted in any form or by any
means without the prior written consent of Open Text.
The information contained in this Workbook is subject to change without notice. If this Workbook is provided in both printed and
electronic form, the electronic form will govern in the event of any inconsistency. Open Text makes no representations or
warranties concerning such information or the software described in this Workbook except as expressly set forth in the
Agreement.
Copyright © 2019 Open Text. All rights reserved. Trademarks owned by Open Text.
OpenText Vendor Invoice Management for SAP Solutions Administration 16.3 - First Edition: March 2019
Comments or suggestions about this manual can be sent to LearningContentDev@opentext.com.

Based on OpenText Vendor Invoice Mangement for SAP Solutions 16.3.1
Developed by OpenText Learning Content Development and Learning Services
Course Name: Vendor Invoice Management for SAP Solutions Administration
Course Number: 3-2102
Part Number: 3-2102-163-00
ii V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Welcome
Vendor Invoice Management (VIM) 16.3 for SAP Solutions is a component of the OpenText ECM Suite
for SAP Solutions. VIM is built on top of the SAP Solution and utilizes much of its underlying
technology. For this course, it is essential that you have a solid grasp of the concepts that are found in
the SAP technical space. Many of the features introduced by the latest release of VIM are covered
from a configuration standpoint.
The main objective of this course is to teach the participant how to install and configure the VIM
Baseline system, with special emphasis on pointing out opportunities for customer enhancements.
Participants will become familiar with accessing OpenText development and configuration tables for
VIM. On completion of this course, you should feel confident that you can successfully configure
Vendor Invoice Management 16.3 for SAP Solutions.
Thank you for participating in this course. Should you require any further information, please contact
us at OpenText Learning Services.
Good luck, and enjoy your learning experience.
OpenText Learning Services
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion iii

iv V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Table of Contents
1. Vendor Invoice Management overview

Objectives ........................................................................................................................... 1-1
OpenText Vendor Invoice Management for SAP Solutions ................................................ 1-1
Accounts Payable challenges ....................................................................................... 1-1
What is Vendor Invoice Management for SAP Solutions by OpenText? ............................ 1-5
What does AP invoice processing look like with VIM? ................................................. 1-5
VIM process overview .................................................................................................. 1-6
Product overview .......................................................................................................... 1-7
Version 16.3 ................................................................................................................. 1-9
What is new in VIM 16.3 ............................................................................................. 1-14
Summary........................................................................................................................... 1-14
2. Landscape and Architecture

Objectives ........................................................................................................................... 2-1
Setting up the landscape .................................................................................................... 2-1
Landscape definition ..................................................................................................... 2-3
Business Center and VIM: Two products, one architecture ......................................... 2-5
SAP vs OpenText reseller: ICC, VIM, and BC .............................................................. 2-8
Summary............................................................................................................................. 2-9
3. Installation and upgrade to VIM 16.3 SP1

Objectives ........................................................................................................................... 3-1
Installation procedures ........................................................................................................ 3-1
General guidelines ........................................................................................................ 3-2
SAP component .................................................................................................................. 3-2
Pre-requisites ............................................................................................................... 3-2
Installing the VIM SAP component ............................................................................... 3-4
Verification .................................................................................................................... 3-7
Post-installation steps ................................................................................................... 3-8
Upgrading ......................................................................................................................... 3-14
Upgrading to VIM 7.5 .................................................................................................. 3-17
Upgrading to VIM 16.3 ................................................................................................ 3-19
Help from OpenText ................................................................................................... 3-20
Installation troubleshooting and FAQ ................................................................................ 3-21
Exercise: Verifying the installation .................................................................................... 3-21
Exercise: Obtaining the documentation ............................................................................ 3-21
Summary........................................................................................................................... 3-22
4. SAP ArchiveLink Customizing for VIM

Objectives ........................................................................................................................... 4-1
ArchiveLink for VIM ............................................................................................................. 4-1
SAP elements used in ArchiveLink ............................................................................... 4-3
SAP tables in detail ...................................................................................................... 4-4
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion v

SAP ArchiveLink configuration............................................................................................ 4-5
Building blocks .............................................................................................................. 4-5
Basic customizing steps ............................................................................................... 4-8
ArchiveLink basic customizing ...................................................................................... 4-8
Archiving scenarios ........................................................................................................... 4-14
Early Archiving ............................................................................................................ 4-14
Scenario-dependent customizing for Workflow................................................................. 4-15
Workflow Document Types ......................................................................................... 4-15
Set up of a Workflow Document Type ........................................................................ 4-16
Presettings .................................................................................................................. 4-31
OAWD ........................................................................................................................ 4-32
Exercise: Customize an ArchiveLink Document Type for Workflow ................................. 4-33
Exercise: Link additional SAP Object Types to your Workflow Document Type............... 4-34
Summary........................................................................................................................... 4-34
5. VIM Role Framework

Objectives ........................................................................................................................... 5-1
What is the VIM Role Framework? ..................................................................................... 5-1
Roles ............................................................................................................................ 5-1
Step by step: Create a Role ......................................................................................... 5-2
Role Templates ............................................................................................................ 5-4
Step by step (optional): Create a Role Template ......................................................... 5-5
Step by step: Assigning Templates to Roles ................................................................ 5-6
Role Determination or Resolution ................................................................................. 5-8
Exercise: Identifying Template definitions......................................................................... 5-11
Exercise: Creating two new Roles .................................................................................... 5-11
Exercise: Connect your New Roles to a Template definition ............................................ 5-12
Exercise: Connect the new Roles to Agents ..................................................................... 5-12
Summary........................................................................................................................... 5-13
Test your knowledge ......................................................................................................... 5-14
6. Business Center Inbound Configuration

Objectives ........................................................................................................................... 6-1
Overview ............................................................................................................................. 6-1
Architecture......................................................................................................................... 6-2
Customizing Inbound Configuration ............................................................................. 6-2
Channels ..................................................................................................................... 6-6
Document Handlers ...................................................................................................... 6-7
Service Modules ........................................................................................................... 6-7
Registration Types ........................................................................................................ 6-8
Data Mapping ............................................................................................................... 6-9
e-invoicing scenario .......................................................................................................... 6-10
e-mail specific configuration ....................................................................................... 6-11
The Document Pipeline..................................................................................................... 6-12
EDI configuration .............................................................................................................. 6-12
Integration with the SAP Adapter for the Ariba Network ................................................... 6-13
Integration with Vendor Invoice Management ............................................................ 6-13
Advantages of VIM/Ariba Integration .......................................................................... 6-13
Integration Scenarios .................................................................................................. 6-13
vi V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Exercise: Perform Inbound Configuration for your new ArchiveLink Document Type ...... 6-16
Summary........................................................................................................................... 6-17
7. Document Processing
Objectives ........................................................................................................................... 7-1
Document Processing Overview......................................................................................... 7-1
Customizing Document Processing .............................................................................. 7-2
Main concepts ..................................................................................................................... 7-3
Product Codes .............................................................................................................. 7-3
Best practices for document processing ....................................................................... 7-3
Document Types .......................................................................................................... 7-3
Process Types ............................................................................................................ 7-11
Configuring Auto-Post determination .......................................................................... 7-19
Processing Logic Modules .......................................................................................... 7-20
Business Rules ........................................................................................................... 7-24
Business Rules Framework ........................................................................................ 7-28
Process Options ......................................................................................................... 7-30
Exercise: Creating a Document Type and a Process Type .............................................. 7-38
User Process Options ................................................................................................. 7-39
Summary of DP objects .............................................................................................. 7-44
The Index screen ........................................................................................................ 7-45
Global Configuration parameters for Document Processing ...................................... 7-52
Characteristic specific rules and configuration ........................................................... 7-54
Exercise: Creating User Process Options and Changing the Indexing Screen ................ 7-60
Other Configuration options ........................................................................................ 7-63
Exercise: Maintaining Duplicate Check Logic and Reason Codes ................................... 7-67
Summary........................................................................................................................... 7-67
8. Invoice Processing configuration

Objectives ........................................................................................................................... 8-1
Baseline invoice handling ................................................................................................... 8-1
Reason Codes ............................................................................................................. 8-1
Invoice processing customization ....................................................................................... 8-1
Rollout Criteria for Triggering PO Blocking Workflow ................................................... 8-1
PO Parking specific configuration ................................................................................. 8-4
Non PO Parking specific configuration ......................................................................... 8-4
Configuring parked processing ..................................................................................... 8-5
PO Blocking specific configuration ............................................................................... 8-5
Technical configuration ....................................................................................................... 8-7
Exercise: Change the blocked invoice display .................................................................... 8-8
Summary............................................................................................................................. 8-8
9. Invoice approval configuration

Objectives ........................................................................................................................... 9-1
Invoice approvals ................................................................................................................ 9-1
Features of the IAP ....................................................................................................... 9-1
What starts the approval process? ..................................................................................... 9-3
DP approval .................................................................................................................. 9-3
Configuring the IAP process ............................................................................................... 9-4
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion vii

Approval specific Process Types .................................................................................. 9-4
Multi level approval ....................................................................................................... 9-5
Approval flow ................................................................................................................ 9-7
Defining the approval hierarchy and approval levels .......................................................... 9-8
Simple approval ............................................................................................................ 9-8
Level based approval ................................................................................................... 9-9
Approval Flow Settings ............................................................................................... 9-14
Expense Types ........................................................................................................... 9-19
E-mail notification ....................................................................................................... 9-20
Configuring fields for the invoice approval screen ...................................................... 9-21
Roles ................................................................................................................................. 9-26
The Coder ................................................................................................................... 9-26
The Approver .............................................................................................................. 9-27
Approver Personas ..................................................................................................... 9-30
Substitution ................................................................................................................. 9-32
Rejection ..................................................................................................................... 9-33
Resubmit .................................................................................................................... 9-34
Bulk Approval ............................................................................................................. 9-36
Custom Classes ................................................................................................................ 9-37
Exercise: NEW COA ......................................................................................................... 9-37
Exercise: Approval Configurations .................................................................................... 9-38
Summary........................................................................................................................... 9-38
Test your knowledge ......................................................................................................... 9-39
10. Customizing Business Center Capture

Objectives ......................................................................................................................... 10-1
Business Center Capture .................................................................................................. 10-1
History ........................................................................................................................ 10-1
BCC architecture............................................................................................................... 10-2
OCR integration in VIM ..................................................................................................... 10-4
Business Center Capture for VIM ............................................................................... 10-5
Architecture ................................................................................................................ 10-7
BCC customizing client ............................................................................................. 10-11
Applications .............................................................................................................. 10-15
Optimizing OCR recognition ........................................................................................... 10-20
Classical methods .................................................................................................... 10-20
Continuous Self Adaptive methods .......................................................................... 10-20
Invoice data extraction process ................................................................................ 10-30
An optimized invoice accelerator application ............................................................ 10-35
Configuring SAP for BCC ......................................................................................... 10-38
Administering BCC for VIM ....................................................................................... 10-42
Evaluating BCC ........................................................................................................ 10-44
Exercise: Change your existing DP Document Type (ZNPO##INV) to BCC specific ..... 10-46
Summary......................................................................................................................... 10-48
Tips, tricks, and traps ...................................................................................................... 10-49
11. The Fiori Task App

Objectives ......................................................................................................................... 11-1
The Fiori Task App............................................................................................................ 11-1
Fiori architecture ......................................................................................................... 11-2
viii V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Configuring the Fiori Task App ................................................................................... 11-3
Setting up launchpad content ................................................................................... 11-10
Summary......................................................................................................................... 11-11
12. Optional VIM Configuration

Objectives ......................................................................................................................... 12-1
Special topics .................................................................................................................... 12-1
Return to Vendor............................................................................................................... 12-2
PDF Log ............................................................................................................................ 12-9
Incoming IDocs ......................................................................................................... 12-10
Extended ECM ......................................................................................................... 12-10
Supplier Self Service ................................................................................................ 12-12
Supplier Relationship Management (SRM) .............................................................. 12-14
Business Warehouse Content ........................................................................................ 12-19
Integration with the SAP Adapter for the Ariba Network ................................................. 12-20
Integration with Vendor Invoice Management .......................................................... 12-20
Advantages of VIM integration ................................................................................. 12-20
Exercise: Viewing the PDF Log Profiles ......................................................................... 12-21
Summary......................................................................................................................... 12-22
13. Administration and troubleshooting

Objectives ......................................................................................................................... 13-1
VIM administration ............................................................................................................ 13-1
General maintenance tasks .............................................................................................. 13-2
SAP AP processes............................................................................................................ 13-4
Mass change of Posting Date utility ........................................................................... 13-5
Month End reporting: parked invoices ........................................................................ 13-6
Year End reporting: parked invoices .......................................................................... 13-6
Technical upkeep of the software ..................................................................................... 13-7
Workflow administration .................................................................................................... 13-8
VIM tables for Administrators .......................................................................................... 13-11
Troubleshooting .............................................................................................................. 13-12
Role resolution .......................................................................................................... 13-12
Workitem Role flow ................................................................................................... 13-13
Authorizations ........................................................................................................... 13-14
Invoice Approvals ..................................................................................................... 13-14
Workflow triggering ................................................................................................... 13-15
EnterpriseScan ......................................................................................................... 13-15
Archive Center log files ............................................................................................. 13-16
The Application Log .................................................................................................. 13-16
OCR related issues .................................................................................................. 13-16
OpenText Support........................................................................................................... 13-17
Summary......................................................................................................................... 13-18
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion ix

x V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Text Conventions
This workbook uses the following conventions:
Convention What it is Used For
Italic Italics are used for Workshops and Exercises.
Monospace Monospaced text is used to represent sample code.
Bold In instruction steps, indicates the action to be taken. In text it

indicates emphasis
<> Angle brackets (<>) represent an element of syntax you must

substitute with a specific value.
This icon represents a lesson symbol where the student watches the
instructor.
This icon represents a lesson symbol where the student follows along
with the instructor.
This icon represents a lesson symbol where the students perform the
exercise on their own.
This icon represents an optional or advanced lesson symbol where

the students perform the exercise on their own.
This icon represents a note that supplies additional information.
This icon represents a tip that supplies additional shortcut

information.
This icon represents a collection of Tricks, Tips, and Traps that is

used the end of a chapter.
This icon represents a caution that supplies warning information.
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion xi

xii V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Vendor Invoice Management for SAP
Solutions Administration 16.3
Student Attendance Form
Training Date:
Instructor:
Location:
Student Name:
Position:
Management  Technical  Other 
Implementation  End User  Administrator 
Industry:
Federal Government  Legal 
Other Government  Manufacturing 
Education  Financial/Insurance 
Integrator  Other 
Company:
Street Address:
E-mail:
Phone Number:
C hapte r 1 . V endor Invoi ce Manage ment o verview
1. Vendor Invoice Management overview
Objectives
On completion of this section, participants should be able to:

 Describe the challenges a typical Accounts Payable department faces
 Explain how VIM is suited to solve these issues
 Describe the latest VIM functionality
 Compare Simple and Classic VIM modes
OpenText Vendor Invoice Management for SAP Solutions

Vendor Invoice Management for SAP Solutions (VIM) provides a quality,
functionally rich Accounts Payable application, which is easy to deploy. Its
functionality is geared towards medium to high volume invoicing scenarios
and works in tandem with shared service centers. Next, we discuss the
common Accounts Payable challenges, which drive the need for a VIM
solution.
Accounts Payable Accounts Payable is typically a labor intensive and time consuming set of
challenges processes. It involves the ingestion of hundreds, up to tens of thousands, of
invoices a month. The invoices are often paper-based, or they are
electronic and arrive alongside attachments that reflect the original paper-
based layout. These invoices are often the result of purchase orders that
also create their own paper trail. Together, this multitude of paper,
electronic images, and electronic transmission must pass through many
gates in order for the payment process to occur. Therefore, each document
must pass through many hands and might be copied or altered, as well as
being stored multiple times during its journey.
This process is wrought with many opportunities for error, loss, and delay.
The typical process is described next.
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pa ge 1- 1

Cha pter 1. Ven dor Invoice M anagement over view
Figure 1-1: AP business process flow without VIM
AP business process As the figure illustrates, a normal invoice to pay process might look like the
flow without VIM following:
1. The mailroom or other recipient receives the incoming paper invoices
and sends them to Accounts Payable (A/P).
2. A/P parks the invoice in SAP. A parked invoice or document is a
temporary document. It is not included in the General Ledger A/P
liability account but does display in the Vendor account detail screen.
Alternatively, A/P may send the invoice to the approver prior to parking.
3. A/P informs the originator of the purchase (by e-mail, inter-office mail,
phone call, sticky note, etc.) to verify and approve the invoice. A/P may
also send a copy of the invoice to the originator.
4. The originator or a separate approver approves or rejects the invoice
and notifies A/P of the decision. The originator may keep a copy of the
invoice.
– If the invoice is rejected, A/P must process the parked document.
They can delete it or request additional information from the vendor.
If waiting for vendor information, A/P must track the parked
document.
– If the invoice is approved, A/P makes any requested changes and
posts the invoice.
Various users may keep copies of invoices and information requests

throughout the process. Therefore, there is a risk that people do not have
the most up-to-date copy of the invoice.
Pag e 1- 2 V endor In voice Mana gement for SA P Solut ions A dminist rat ion
Correspondence between the involved parties must be captured and

tracked manually. This is a typical process for manual invoice verification.
Many departments may be involved. When the departments are in different
cities, countries, and time zones, communication and accuracy become
very challenging.
Challenges in traditional In summary, the following challenges are often seen in a typical A/P
invoice processing process:
 There is a large amount of manual activity for approvals and exception
processing.
 Duplicate payments and postings are misplaced and invoices get lost.
 There is an unpredictable variation in workloads due to cyclical volume
increases.
 Audit and compliance concerns arise due to contradictory
documentation.
 There is low visibility of volume data, throughput statistics, and
bottlenecks.
 Lengthy cycle times are common.
 A highly skilled workforce ends up performing low valued tasks.
Figure 1-2: Typical statistics: AP challenges
Manual keying of invoice data and resolution efforts involve time-consuming

historical research, communication with the vendor, process
documentation, requests for additional information from multiple parties,
manual routing, and the labor-intensive process of monitoring and providing
update reports on the status of unpaid invoices.
AP staff resources can spend a large amount of time addressing these

problems, while vendors and buyers experience a wide range of
disincentives and disadvantages.

Effects by Role Many roles are involved in the invoice process. In the next figure we
visualize the different roles which are affected in each area of the
organization.
Figure 1-3: Parties involved in invoice processing
Within these different areas, there are different organizational challenges

which must be addressed:
 Strategy & Operations - Management’s View
– High A/P cost per transaction
– A need for better reports to improve the process
– Regularly missed discounts
– Duplicate invoice processing
 Finance & Procurement - Buyer’s View
– Not their core job
– Resolving invoice issues is not a high priority
– Not automated nor a value-add process
 Finance & Procurement - Accounts Payable’s View
– Takes too much time - manual, labor-intensive
– A/P blamed for late payments, lost invoices
– No time for root-cause analysis to reduce problems
– Storing massive amounts of paper is inefficient and costly
 Lines of Business - Approver’s View
– Manual approvals take too much time
– Paper invoices are lost or misplaced
 Business Partners - Supplier’s View

– Limited insight into the status of an invoice
– Misinformation about invoice status
– Inability to properly plan for payment
What is Vendor Invoice Management for SAP Solutions by OpenText?

Based on the challenges presented, the limited resources that companies
employ, and the need for streamlining inefficient processes when possible,
OpenText Vendor Invoice Management for SAP Solutions (VIM) is a logical
choice for AP departments that run SAP.
Simplify – Transform – VIM makes it easy for clients to implement the solution and transform their
Accelerate AP process to gain efficiencies, thereby improving supplier relationships
and saving time and resources.
VIM is a prepackaged composite application that acts as an add-on to the

SAP ERP system. It can be leveraged to simplify the processes in the
lifecycle of purchase orders and invoices.
As an option for VIM, OpenText Business Center Capture for SAP Solutions
(BCC) further extends VIM’s capabilities automating the capture of paper
invoices. BCC uses optical character recognition (OCR) to extract invoice
data. The combination of BCC with VIM enables end-to-end automation of
paper invoice processing.
The objectives in a VIM implementation are for invoices to be processed

more efficiently, problem invoices to be more quickly brought to resolution,
approvals to be expedited, and payments to be on time.
What does AP invoice In order to accomplish these objectives, VIM has been designed to fully
processing look like automate the invoice process with as little manual intervention as possible.
with VIM? When manual intervention is required, it is also captured in the digital record
of the invoice process. VIM conducts an invoice from ingestion through to
payment and keeps track of it along the way, thereby reducing the errors
and complexities introduced by manual processing.

A high-level look at this new digitally-focused processing is pictured next.
Figure 1-4: The invoice process with VIM
VIM process overview When VIM is integrated into the Scan to Payment process, it can be viewed
in several stages. The following must be completed:
 Image capture
 Key data capture
 Validation of the data
 Creation of the SAP document
 Posting of the SAP document
Image capture Typically, companies will receive invoices via mail or via e-mail. In both
cases, the invoice image must be saved and SAP must be notified that an
invoice has arrived. For ingesting the invoice, companies can use a
scanning device that then invokes Enterprise Scan software. It
subsequently calls SAP. Or, they might employ an SMTP interface that
routes e-mail invoices from the e-mail server to the SAP VIM application. In
both cases, OpenText Archive Center (or another third-party long term
archiving solution) is used to store the incoming invoice image. This image
is now available in the archiving solution and is linked to the new VIM
Document Processing (DP) document.
Key data capture Now that the invoices are reflected in SAP, it is time to extract the key data
fields from the image. There is a pre-defined job running in SAP which looks
for the notification that an image has been archived and is queued in SAP
for processing. When a new invoice is detected, the BCC server is invoked
(if BCC is being used) and the OCR process begins. All fields which are
identified during extraction are saved with the Document Processing
document that was created in the previous step.
Validation of the Now, the document becomes ready for validation by the company
document personnel. At this stage, another job has run which notifies the persons
responsible for checking the invoice extraction (or for manual extraction in
the case where OCR is not employed). The document is opened by the
coder, the fields in the invoice are either validated, corrected, or
complemented.
Creation of the SAP Once completed, the invoice is saved. If it is deemed to not be a duplicate
document invoice, then the business rules for invoices are applied to the data being
submitted. If it passes all of these rules, an SAP document is created and
the next step of the workflow is invoked.
Posting of the SAP Now the Document Processing document and the respective SAP
document document are available for the levels of approval that are necessary in this
company. (this is configurable). After approval, the SAP document is then
posted in SAP.
Product overview Vendor Invoice Management is part of a larger group of OpenText products:
OpenText Suite for SAP Solutions.
Figure 1-5: OpenText Suite for SAP Solutions
VIM is a packaged business solution that is developed and tested in

coordination and partnership with SAP. It is built using ABAP, Fiori, SAP
Netweaver Portal, and SAP Workflow technologies. VIM is a technical
solution, but it is built on years of experience and best practices in the
industry.

Commercial offering: SAP and OpenText both sell the VIM solution. It is branded differently
SAP vs OpenText according to which party is selling it:
 SAP - SAP Invoice Management by OpenText
 OpenText - Vendor Invoice Management for SAP Solutions
For this course, we refer to it exclusively as VIM as sold by OpenText. To

further segregate the offering, VIM has two different product offerings which
are being concurrently developed and maintained.
VIM 7.5 VIM 7.5 is the evolution of the VIM solution from its inception. This version is
currently being further developed (i.e. it has not reached an EOM status).
VIM 16.3 VIM 16.3 is OpenText’s latest release of the VIM product. It runs exclusively
on the SAP S/4HANA system, starting with release 1610.
The following figure shows the various versions of SAP and the version of
VIM which it can work in conjunction with.
Figure 1-6: VIM/SAP version matrix
Both versions can be run in the private Cloud. Ongoing, OpenText will work
jointly with SAP to develop VIM for the public cloud offering.
This course uses VIM Version 16.3 SP1 in conjunction with

Business Center and BCC Version 16.3.1 running on SAP S/4
HANA 1709 as the reference system.
Figure 1-7: Business Center/SAP version matrix
To understand which VIM version supports which SAP version, read SAP
Note 2339256.
Version 16.3 In version 16.3, the product has been delivered with two modes for
operation. They are technically supported by the same foundation, yet, they
support different methods of invoice processing. They are the Simple and
the Classic Mode.
Classic Mode Classic Mode is to a large extent compatible with previous VIM versions 7.0
and 7.5. It offers proven architecture and a configurable framework and
many options to extend the pre-delivered invoice management logic.
For VIM 16.3, the classic approach was updated and extended to meet SAP
S/4HANA requirements and optimizations and to follow SAP strategy to
post all invoices through one invoice transaction: VIM Baseline
configuration (discussed in later chapters) uses transaction MIRO for all
invoice types including Non-PO invoices.
Classic mode is the choice for organizations upgrading from SAP ECC and
older VIM versions who want to gradually adopt to new SAP S/4HANA
concepts and maintain their approach to invoice processing.
Classic mode provides powerful SAP GUI/Webgui based tools like VIM
Workplace and the VIM Analytics report, a web portal for invoice coding and
approval, which can be integrated with SAP NetWeaver® Portal and SAP
Fiori Apps for different tasks like simple coding, approval, and confirming
price and quantity on PO-related invoices.

VIM’s Classic Mode is made up of components that provide different pieces

of the process as shown in the next figure:
Figure 1-8: Components of VIM 16.3 Classic Mode
 Invoice Entry
– These are the options for introducing an invoice into the VIM
system. This includes paper-based invoices which are scanned and
invoices which arrive electronically (EDI, Ariba Network, SAP Idoc,
e-mailed invoice images, etc.)
 OCR (Optical Character Recognition) with BCC (Business Center
Capture)
– This component automates the capture of invoice data fields by
using OCR technology
 Inbound Channels
– These make up the processing framework for inbound invoices
 Document Processing
– This component captures invoice metadata, handles suspected
duplicate invoices, and collaborates with the other components
 Invoice Approval
– This component receives a list of invoices to be approved, checks
for appropriate approvers, and allows those users to code and
approve the invoices
 Web Portal
– This is a Java based Approval Portal infrastructure running on SAP
NetWeaver Application Server (Java stack). It is similar to the GUI
Invoice Approval but has a Web interface
 Fiori Apps
– These apps allow the user to perform multiple invoice-related tasks,
using standard SAP Fiori technology
 Exception Handling (Invoice Exception)
– This component allows for the handling of exceptions that arise
before the SAP document is created.
 VIM Reporting / VIM Analytics / BW extractor
– VIM Reporting uses various reports to analyze the status of invoices
in the SAP system.
– VIM Analytics overlooks the invoices in progress in a unified
dashboard
 Unblocking Workflows
– This component determines the agents necessary to rectify a
blocked invoice and to carry it through to completion
 Auto Post and Manual Post
– This component distinguishes between invoices which can be auto-
posted and those which cannot
 SAPGUI Workplace
– This component, commonly referred to as the VIM Workplace, is the
main GUI UI for a super user of Vendor Invoice Management
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pag e 1- 11

Simple Mode Simple Mode provides a new invoice process designed which embraces
SAP S/4HANA concepts like: simplification, principle-of-one, digitalization,
cloud-first, and a new user experience from the start. The SAP S/4HANA
environment is the basis for a next-generation invoice automation solution
that focuses on streamlined and simplified invoice processing.
Figure 1-9: Components of VIM 16.3: Simple Mode
Simple Mode philosophy While the Classic Mode provides many configuration options, the Simple
Mode philosophy is about a uniform best practice approach based on a few
invoice scenarios:
 Invoices that can be processed through automation by their nature and
structure (Automate)
 Invoices that can be processed through automation with limited manual
intervention (Semi-Automate)
 Invoices that need manual processing and may use specific features of
SAP’s Fiori App: Manage Supplier Invoices (Manual)
Simple Mode Vendor Invoice Management (simple mode) provides the following:
functionality
 Invoice automation built around SAP’s Fiori App Manage Supplier
Invoices
 End-to-end Fiori user experience
 Capture of scanned paper invoices and PDF invoices through OCR
cloud service with automated optimization through constant feedback
(other invoices are received from networks like Ariba or classic IDocs or
other channels)
 Cloud OCR as the default option - on premise OCR will also be
supported
 Advanced machine learning features to optimize data capture
(feedback from SAP process and SAP posting to the data extraction
service)
 Leverage SAP invoice drafts as a container to store preliminary invoice
data (instead of separate header and line items tables of Classic Mode)
 A Fiori based “automation” screen for capturing core invoices fields
which includes Single Click Entry and Table Auto-completion
 Minimum set of mandatory configuration based on pre-delivered best
practices settings
 Limited classical customizing
 Increased number of settings made available through key user
configuration
 New “smart” and self-adapting features like intelligent coding defaults,
dynamic auto-classification of vendors into black, grey and white lists,
and others
 Extension points in Business Center process framework to meet
customer specific requirements
Vendor Invoice Management 16.3 provides the first version of the new
Simple Mode. A number of features are not yet released and there are
further limitations.

What is new in VIM With the latest release of VIM, OpenText has introduced several new key
16.3 functionalities. Some of these features have been introduced already,
others will be expanded upon in separate chapters.
 Support for SAP S/4HANA 1709
 Classic Mode (based on VIM 7.5)
 Updated baseline configuration (which uses MIRO for all invoices)
 Document Processing component which supports parked and held
documents
 Reduced use of batch input (blacklisted technology at SAP)
 Simple Mode
 Business Center add-ons delivered as a part of the VIM ISO image
Summary
In this chapter the challenges of an Accounts Payable department were
presented, along with how Vendor Invoice Management is able to meet
those challenges. A breakdown of stages was shown so that the student
can further visualize how VIM automates the complex series of exchanges
in the Scan to Payment process. Newly introduced functionality was
highlighted.
C hapt er 2. L andscape and A rchit ectur e
2. Landscape and Architecture
Objectives

 Explain how VIM supports multi-system landscapes
 Recognize some of the extraneous components for a VIM landscape
 Explain the technical dependence between VIM and Business Center
 Recognize the various product names and interoperability
Setting up the landscape

Vendor Invoice Management can be run on SAP landscapes where there is
only one SAP instance or where there are multiple SAP instances.
Single system The most typical scenario is the Single system landscape, where one SAP
landscapes instance is utilized. An example of this logical landscape is shown in the
next figure.
Figure 2-1: Single System
Multi system landscapes VIM can also be deployed in a scenario where there is more than one
stand-alone SAP system. In this scenario, the following VIM resources
might be used on the Central SAP instance:
 Invoice entry point, which includes scanning with Business Capture
Center (BCC)
 Archive to archive all incoming invoices
 Controlling point for management, which uses Central Reporting

Cha pter 2. Landscap e and Ar chitect ure
A multi system landscape is made up of a central system with multiple

satellite systems for invoice entry and procurement logistics. The next figure
shows one possible example for a multiple backend system.
Figure 2-2: Multi system VIM landscape
System Determination Procedures - In a multiple system landscape the

system determination procedure to determine in which system the VIM
workflow should start is defined. This can be defined according to simple
evaluation of company code, archive document type, or by more complex
means via a custom function module.
Although the system landscape configuration must be done after

installation, the topic is covered first as the design of the landscape should
be finalized prior to installation.
All configuration for both scenarios can be done under transaction code
/OPT/SPRO within the OpenText™ IMG. Navigate to Vendor Invoice
Management -> Document Processing Configuration -> General
Configuration -> Multi-Backend Scenarios.
For both scenarios, the following set up is required:

 System Landscape Directory - In this step all the systems with whom a
connection has to be performed (including the system itself) must be
defined. This is shown in the installation chapter.
The following tasks are only required for Multi System Landscapes:
 RFC Destinations - In this step, RFC destinations for each of the logical
systems is defined.
 Logical Systems - In this step, the logical systems in the distributed
system are defined.
 Assign client to logical system - In this work step, a client is assigned to
each logical system.
Landscape definition As discussed in the previous section, there are different landscape options.
The landscape architecture should be defined and well documented prior to
installation. Next, a more detailed view must be decided on, according to
which functionality the customer is employing. An example of a possible
architecture is shown next.
Figure 2-3: Simple VIM landscape with Fiori

In the previous figure the following components are illustrated:

 SAP S/4HANA server - This is the SAP application server, which will be
the base for the VIM and BC product Add-Ons. Business Center add-
ons are required for VIM as described later in this chapter.
 Fiori server - this will be the base for the UI Add-ons
 Clients - Desktops, laptops, or mobile devices which will access
functionality via a web browser (or via installed client software
However, the actual architecture gets more intricate as functionality, such

as OCR extraction, scanning, and document management are introduced.
This results in a landscape that might look like the next figure.
Figure 2-4: Detailed VIM landscape
In this figure, the following are introduced to the landscape picture:

 Document Pipeline - an OpenText product used for queuing,
manipulating, and managing documents prior to their archival
 Archive Center - an OpenText long term storage solution (this is
required, but is not shown in the previous diagram for simplification
purposes)
 Business Center Capture - an OpenText OCR solution, which has an
Invoice Accelerator option to be used with VIM. Other OCR products
can be used as well
 WebViewer/Brava Viewer - The Brava Viewer has been introduced to
work with VIM and other OpenText products. The WebViewer is also still
available as an add-on from OpenText.
 Enterprise Scan - an OpenText solution for scanning, indexing, and
converting files prior to archival
 SAP GUI - SAP client software
 OCR Validation - OpenText BCC client software, for VIM the Invoice
Accelerator add-on is introduced (covered in a later section). This is
validation client software for the checking and correction of incoming
invoices.
 xECM (Extended ECM for SAP Solutions by OpenText) add-on - this is
an optional integration in order to plug Extended ECM (Enterprise
Content Management) Content into the VIM process. This would
include digital content such as documents, correspondence, contracts,
etc. which would be available via the add-on interface.
 Scan client - an install on the desktop for the resource responsible for
the scanning or quality assurance of incoming documents
Business Center and As the previous architecture diagrams have shown, Business Center and
VIM: Two products, Business Center Capture are two products which are a part of OpenText’s
one architecture Suite for SAP Solutions. These two products, along with Vendor Invoice
Management and Invoice Capture Center are digital processing solutions
which can be used independently or in tandem. A customer can choose to
use one, none, or both. However, in order to use VIM and ICC, some
components of BC and BCC are required.
For VIM and ICC installations, some components of BC and BCC

respectively are required.

Although the purchase and use of these products is distinct, their technical
make-up is more complex. They are sold separately from a commercial
standpoint, but they share some components from a technical perspective.
Please see the next figure as an illustration of the high level distinction
between these four products:
 Vendor Invoice Management
 Business Center
 Invoice Capture Center
 Business Center Capture
Figure 2-5: Business Center, VIM, ICC & BCC: Commercial products vs technical components
In this figure, the top level represents the commercially available products.
The second level represents the functionalities which are associated with
each product. The last level represents the technical components
supporting this functionality.
It becomes obvious that to run the latest version of Vendor Invoice

Management, a customer must employ some of the technical components
of the Business Center product. As an example, upon installation,
component OTBCBAS is required. This component supports the BC
Framework which is used by VIM for Inbound Processing. It is used even if
the customer did not purchase Business Center.
For a more detailed break down of the VIM and ICC products, the next
figure is provided.
Figure 2-6: Detailed breakdown of commercial vs technical product components
For a detailed break out of commercial and technical components for

Business Center, please see the next figure.
Figure 2-7:Business Center: Commercial product vs technical make up

SAP vs OpenText In delineating how these products are developed and sold, there should
reseller: ICC, VIM, and also be clarity between the names of the products when sold by either SAP
BC or OpenText. This minimizes confusion when having discussions in support
or sales situations. The following table defines the product names used in
the marketplace.
SAP base product OpenText product and version When sold by SAP
ERP OpenText Vendor Invoice SAP Invoice Management by OpenText

Management for SAP Solutions
7.5
ERP OpenText Invoice Capture Center OCR Add-on for SAP Invoice Management by
for SAP Solutions 16.3 OpenText (16.3)
ERP OpenText Business Center for SAP Digital Content Processing by OpenText
SAP Solutions 16.3 (16.3)
SAP S/4HANA OpenText Vendor Invoice SAP Invoice Management for SAP S/4HANA by
Management for SAP Solutions OpenText (7.5 or 16.3)
(7.5 or 16.3)
SAP S/4HANA OpenText Invoice Capture Center OCR Add-on for SAP Invoice Management by
for SAP Solutions 16.3 OpenText (16.3)
SAP S/4HANA OpenText Business Center for SAP Digital Content Processing for S/4HANA by
SAP Solutions 16.3 OpenText (16.3)
SAP S/4HANA Not available SAP S/4HANA Invoice Processing by OpenText

Cloud
Invoice Capture Center The recommendation from OpenText is to move to Invoice Capture Center
version 16.3.
It should also be noted that ICC is now a technical add-on to the Business
Center OCR product: Business Center Capture. Akin to the Business
Center foundation being required for the Vendor Invoice Management
functionality. Business Center Capture is now the foundation for the
Invoice Capture Center add-on.
Going forward, all new installations and upgrades should be using ICC 16.3,
which is:
 compatible with VIM 7.5 SP6+ and VIM 16.3
 supported for deployment in MS Azure and AWS
The next version of BCC and ICC will be an Information Extraction Service,
which will:
 enable public cloud deployment
 enhance current machine learning offering
ICC and it’s unified deployment with BCC is covered in more detail
in a later chapter.
Summary
This chapter reviewed potential VIM landscapes. It provided general
guidelines for the products used and the architecture of a VIM solution.

C hapt er 3. I nstalla tion and u pgrad e to VI M 16.3 SP 1
3. Installation and upgrade to VIM 16.3 SP1
Objectives

 Find the required documentation for installation of VIM 16.3
 Identify the main procedural steps in installation
 Perform the post installation and upgrade checks necessary for validation of the system
 Locate upgrade specific information
 Plan and execute an upgrade of their existing landscape
Installation procedures
At a minimum, the customer should install SP1 for VIM 16.3. The VIM
16.3 SP1 release delivers two possible scenarios for installation. Classic
and Simple modes. This chapter and the rest of the course will focus on
Classic Mode. Please see the OpenText Knowledge Center for
appropriate documentation for Simple Mode installation.
In addition to the core SAP S4/HANA components, VIM can extend it’s
functionality with additional components. For the purposes of this manual,
steps for installing the following optional components will not be covered:
 Approval Portal
 Mobile Approval Portal
 KPI Dashboard
 Netweaver Gateway
 Supplier Self Service
 Ariba Integration
 Vendor Invoice Management SAP NetWeaver Business Warehouse
(VIM BW)
For detailed instructions on the installation of each of the

components of VIM 16.3, please refer to the OpenText Knowledge
Center document entitled OpenText Vendor Invoice Management
for SAP Solutions 16.3 SP1 Installation Guide.pdf.

Cha pter 3. Inst allati on and upgr ade t o V IM 16 .3 S P1
General guidelines This course will deliver an overview of the installation process for VIM 16.3
SP1. It is not meant to be used as a comprehensive installation guide.
The OpenText Vendor Invoice Management for SAP Solutions

16.3.1 Installation Guide can be found at: https://
knowledge.opentext.com/knowledge/piroot/vim/v160301/vim-igd/
docovw.xml
SAP component
Pre-requisites The basic installation of VIM requires that certain other pieces of software
are already in place. The most obvious of these is SAP. For VIM 16.3, the
earliest release of SAP that can be used is SAP S/4HANA 1610 (S4CORE
101). The Support Package Manager in SAP (transaction SPAM) should be
run to ensure that the support pack level is at least 66.
SAP Note 2339256 “SAP Invoice Management by OpenText support for

SAP products” should be checked to understand SAP/VIM product
version compatibility. OSS notes are obtained via the SAP Marketplace.
Obtaining the software Customers can obtain the VIM solution via a download via the OpenText
Knowledge Center. Support Packages along with all of the most recent
documentation should be retrieved from the OpenText Knowledge Center. If
a customer requires instructions for a fix (hot fix) for a single issue, this
should be remedied via OpenText support tickets.
Workflow set-up VIM also requires that the SAP Workflow engine is configured to run
workflow tasks. This can be checked via the SWU3 transaction. With this
transaction, the relevant tasks should be verified as complete (denoted with
the Green Check mark). Most critically, it should be confirmed that RFC
destinations have been configured.
Figure 3-1: Workflow set up confirmation
There might be some tasks which have a red ‘X’ indicating they
are not configured completely, such as ‘Edit Additional Settings
and Services’ and ‘Guided Procedures’. This is acceptable.
Ensure the Configure RFC Destination is configured (indicated by
a green check mark to the left of the task).
ArchiveLink The ArchiveLink interface must also be active in the SAP system for
communication with the storage system to be enabled.

SAINT The SAP Add-on Installation Tool (SAINT) will be used for installation.
SAINT requires PAT files (extension *.PAT), which are collections of
transport files or packages. The product is archived into SAPCAR files
(extension *.SAR). The different SAPCAR files are located in a DATA folder
below the respective package folder, named according to package and SAP
release.
File names must be in upper case. File names with lower case characters
will not accepted by transaction code SAINT nor SPAM.
Installing the VIM SAP In order to install the VIM Basis package (which will in turn install the basic
component VIM components), the following steps should be carried out on the
SAP S/4HANA server:
1. Obtain all relevant SAR files for each VIM add-on component. You will
also need all relevant Support Packages for these installation files. For
example:
– Component OTBCBAS has a SAR file named
OTBCBAS_INST_UPG_0700_004.SAR. It also has a Support
Package file named OTBCBAS_SP01_0700_004.SAR. You require
both for each component.
These can be extracted using the SAPCAR command line tool.There is
also a required password that must be supplied to SAINT when VIM is
installed or upgraded. These are found in the installation guide.
2. Copy the respective SAPCAR files from the aforementioned site to the
target SAP Application Server. The file should be placed in /usr/sap/
trans/EPS/ with the following command:
 SAPCAR -xvf<name of SAPCAR file>.
Figure 3-2:
Installation files on the

application server
3. Collect the latest post-installation transports. These include:

– Standard layouts
– Fiori perspectives
– Launchpad content
4. Download the language packs required for your installation.

5. Carry out the import according to the documentation, utilizing SAP

Transaction SAINT.
Figure 3-3:
Transaction SAINT
6. There are various operations available within SAINT, one menu path for
installing components is pictured next:
Figure 3-4: Menu path option within transaction code SAINT
7. Ensure all required components appear in the Installed Components

tab.
Figure 3-5:
Result of SAINT
installation process
When a transport is imported, there is a possibility that a warning might be

issued due to the version the development was done in. This is
acceptable and you must select the Ignore invalid component version
check box.
Verification In order to verify that the system has the correct components and sufficient
support packages installed, the following steps should be taken:
1. Navigate to the top menu of SAP.
2. Click the System -> Status menu item.

3. Under the SAP System Data section, click on the Magnifying Glass
icon.
Figure 3-6: OpenText component check
4. Under the column marked Component, there should be a row for

OTEXVIM. This add on should have Release number 81610_104 and
Level 0001.
5. The OTEXBAS component should also be in the list. The Release
number should be 0700_004 with Level 0001.
6. Check all components are listed, according to the installation guide.
Post-installation steps The following post installation activities should be performed:

 Import the transport with Fiori layouts - this is necessary for the Fiori
apps to have the correct perspectives
 Install the transport with layout variants - this provides the layouts for
the VIM Analytics report, it is client-specific, so this transport should be
imported into all clients
 Activate the Business Configuration Sets - this loads the baseline
configuration into the configuration tables and should be activated in the
all clients which use VIM functionality
Figure 3-7: OpenText BC Sets
Ensure you use Expert Mode within transaction SCPR20 to perform this
activation.
 Configure the workflow dialog tasks - Configures the General Task in

the PFTC transaction
 Refresh the SAP workflow runtime buffer - Must be done in order for
proper operation. Use transaction SWU_OBUF
 Configure the object services - this allows for the GOS (Generic Object
Services) to be called from MIRO and FB60. Maintain the SGOSATTR
table via transaction SM30
 Maintain the number ranges - this is used to define the numbering
range of certain objects created in SAP by VIM (for example the DP
Doc ID)

Figure 3-8:
Number Range object for

DP Doc ID
 Create a number range for each of the required objects, using

transaction SNRO (each should have an interval of ‘01’ as pictured in
the next figure):
– /PTGWFI/RI - CP Document
– /OPT/DOCID - Document Processing
– /ORS/STACK - Invoice Approval
– /ORS/USRMP - Invoice Approval Usermap
– /OPT/REGID - Incoming Document Handling (IDH) framework
Figure 3-9:
Number Range interval
 Link the events for VIM workflows - SAP events are trigger points for
VIM workflows. For example, when a logistic invoice is posted, SAP
S/4HANA generates the event POSTED from the business object
BUS2081. The event is linked to trigger the VIM workflow solution for
blocked invoices if the invoice is blocked. Event linkages are not
activated automatically. You must add the event linkages manually. This
is done via transaction SWE2.
 Maintain the SAPscript form for approval - this standard SAPScript form
must be copied from client 000 to all clients and modified accordingly
 Maintain the standard text - Standard Texts are used to build letters
such as the Return to Vendor e-mail which gets set in the RTV process.
This is done via transaction SO10. Standard texts should be maintained
for this particular e-mail functionality:
– /OPT/VIM_SIGNATURE_RTV - this is for the e-mail footer
– /OPT/VIM_RTV_EXAMPLE - this is for the e-mail body and is
provided as an example. It should be renamed for the customer’s
usage
Figure 3-10:
Example of the Standard

Text for RTV process in
transaction SO10
 Set the background user parameters for Non PO invoice posting - this is
for setting a PID specific to user WF-BATCH. WF-BATCH is a user the
system can utilize while performing tasks in the background, such as
workflow oriented tasks or posting.
 Install the transport for extended VAT date support - this is a BADI
implementation which should be activated if required.
 Maintain the Business Transaction Events - A BTE has a predefined
interface and allows you to attach additional functionality in the form of
a service function module.There are two BTEs which should be called
for VIM. These should be configured via transaction BF42.
 Configure the system landscape - transaction /OPT/VIM_SLD will allow
you to set up the system landscape directory.

Figure 3-11: System Landscape Directory in transaction /OPT/VIM_SLD: Single System landscape
 Fiori: Activating services - Two services must be activated for the Fiori
Task App:
– OData Service -The Fiori Task App communicates with the ABAP
backend using a dedicated OData service
(/OTX/PS33_DATA_SRV).Set up version 0003 of OData service
using the /IWFND/MAINT_SERVICE transaction.
Figure 3-12: OData Service maintained in transaction /IWFND/MAINT_SERVICE
– UI Service - This must be activated for both VIM and BC. Both of
these services are located via the SICF transaction in SAP. The
VIM and BC UI services are shown in the next figure within
transaction SICF.
Figure 3-13:
VIM and BC UI Services

which must be activated
for Fiori

 Fiori: Set up the Launchpad content - This is to configure the Fiori

Launchpad so that the proper tiles are available for the user. The
general launchpad configuration instructions should be referenced from
the Business Center Configuration Guide (see section 9.1.1) Then,
within the Fiori Launchpad Designer, the tiles for each piece of VIM
functionality must be set up. An example for the Fiori VIM Approval App
is shown in the next figure. The following values are used in the
Parameters field of the configuration. Each tile will have its own
respective parameters.
– nodeId: PS03_VIM_APR_INV
– wobjType: PS03_PRC_VIM_APR
– workplaceId: WP_INBOX
Figure 3-14: Configuration of VIM Approval tile for the Fiori Launchpad
Upgrading
Customers should consider several factors when making a choice about
which VIM solution they will upgrade to or implement next. Factors include
the customer’s:
 Current SAP landscape (version and database) and road map
 Current version of VIM
 Desired components or functionality within each VIM product version
 OCR strategy
 End of Maintenance targets for each product
 Resources and time frame available for the project
This type of decision can not be dictated within the limits of a manual,
however, several pieces of information are given in order to aid the
customer in making such a decision.
Figure 3-15:
VIM versions
In the previous figure, the various versions of VIM which are now available
are shown. And in the following figure, the compatibility of these versions of
VIM according to the SAP product and version is presented.
SAP Product/ VIM Compatibility Recommended VIM Comments

Version Version
SAP S/4HANA 1709 VIM 16.3 VIM 16.3 SP 1 See SAP Note: 2533336
SAP S/4HANA 1610 VIM 7.5 SP 5 and VIM 16.3 See SAP Notes: 2392527, 2401972
on prem VIM 16.3
SAP S/4HANA 1511 VIM 7.5 SP 3+

on prem
SAP S/4HANA VIM 7.5 SP 4+ See SAP Note: 2235354

Finance 1605
SAP Simple Finance VIM 7.5 SP 1+ VIM 7.5 SP 3+ See SAP Notes: 2100133, 1920804
1503
SAP Simple Finance VIM 7.5 SP 1+ VIM 7.5 SP 3+ See SAP Note: 1920804
1.0
SAP ERP 6.0 EHP 8 VIM 7.5 SP 3+
SAP ERP 6.0 EHP 7 VIM 7.5 SP 1+ See SAP Notes: 1896062 ,1920804
SAP ERP 6.0 EHP 0 - VIM 7.5 SP 1+ Minimum required SAP Basis SP
6 level per installation guide

SAP Product/ VIM Compatibility Recommended VIM Comments

Version Version
SAP ERP Suite on VIM 7.5 SP 1+ 7.5 SP 3 See SAP note 1855666
HANA
SAP R/3 4.6c, SAP Not supported by Versions of VIM 5.1.6 to 7.0 should
R/3 4.7 Enterprise, any VIM version, follow upgrade paths which are
SAP ECC 5.0 which is currently mapped out distinctly for them.
under maintenace However, a general path to upgrade is
shown in the next section for these
situations
SAP S/4HANA Cloud Not currently Add-in solution is Co-developed by SAP and OpenText,
supported available: SAP S/ this product can be purchased from
4HANA Cloud for SAP
invoice processing by
OpenText
Although this course is focused on VIM version 16.3, we recognize that

many customers might still be on the path to 7.5. For this reason, upgrade is
segregated into two main upgrade scenarios.
Upgrading to VIM 7.5 The General guideline is to use VIM 7.5 for installations on SAP ERP 6.0
and SAP S/4HANA on Premise Edition 1511. In this scenario, the customer
is choosing to stay on VIM 7.5 and therefore is planning to be on SAP ERP
or SAP S4/HANA (but not later than 1511). VIM 7.5 does not support SAP
S/4HANA 1709 and higher.
Upgrading to VIM 16.3 A customer should use VIM 16.3 for installations on SAP S/4HANA 1610
and higher.In this scenario, the customer is choosing to move to the latest
version of SAP S4/HANA. VIM 16.3 does not support SAP ERP 6.0 and
SAP S/4HANA on Premise Edition 1511.
Upgrading ICC The general guideline for Invoice Capture Center is to use the latest version
of 16.3 for all installations. ICC 16.3 supports VIM 16.3 and VIM 7.5 (SP6
and higher).
BCC component Use Business Center 16.3 for all versions of SAP ERP and S/4HANA.
SAP R/3 4.6c, SAP R/3 Enterprise 4.7, SAP ECC 5.0 are no longer
supported by any VIM version that is under maintenance.
Upgrade The general recommendation from OpenText is that customers should

recommendations for out move to VIM 7.5 SP8 or VIM 16.3 SP1 at a minimum. The following chart
of maintenance VIM represents the versions a customer might currently be on, the suggested
versions Service Pack level, and possible paths for upgrading to 7.5.
These paths are only general depictions of how a customer might reach a
certain patch level. OpenText Professional Services should be contacted
to tailor a strategy and approach for such an upgrade. Please see the
respective Installation and corresponding Upgrade Guides for further
detail on exchange upgrades and upgrade steps.
Current VIM Recommended Start Potential Paths Comments

Software Level
Release
5.1.6 5.1.6 -> 6.0 SP1 -> 7.5 This is the first version resold
by SAP.
5.2 VIM 5.2 SP6 5.2 -> 7.5 VIM 5.2 SP 6 and 6.0 SP1 are
5.2 -> 6.0 SP1 -> 7.5 almost identical, so upgrade is
low risk and straightforward.
6.0 VIM 6.0 SP1 6.0 -> 7.5 This effort is a true upgrade
project.
7.0 VIM 7.0 SP3 7.0 -> 7.5
Upgrading to VIM 7.5 VIM 7.5 introduced new features, obsolete functionality, migration of
Process Types, Logic Modules, and a new approval workflow. These should
be considered when deciding if the target VIM release level is 7.5. They
include:
New features  New baseline DP document types

 New VIM Analytics report which is designed for HANA DB as well
 Business rule frame work and Logic modules
 Single click entry integration (relevant for ICC customers)
 Line based approval
 Enhanced matching algorithm for background posting scenarios
 Invoice references for credit memos
 Business Center used for inbound processing
 Usage of Fiori Apps (approval, Info provider, simple coding, PO
exception)
 Enhanced integration between central and satellite systems with
Analytics and Workplace

Obsolete functions With the release of VIM 7.5 SP2, there are some obsolete functions to
consider.
 Simple approvals - These are obsolete for Non-PO approvals. However,
for PO-based processing, OpenText will still support the customer.
However, this support for old/simple PO approvals will be phased out in
upcoming SP releases.
 Integrated Invoice Cockpit - The data from the ICC tables must be
downloaded and moved into the VIM Workplace tables.
 Old Indexing Screen - If the customer is moving from a version pre-VIM
7.0 or has retained the old indexing screen, then these settings should
be migrated.
 Old VIM Analytics Report(/opt/vim_analytics) - An initial data load must
be scheduled and new appropriate authorizations must be assigned for
the New VIM Analytics report to the user base.
 Old COA (Chart of Authority, which is used in the Approval functionality)
tables and procedures (a new COA was introduced with 7.0)
 Old approval Workflows (new approval workflow was introduced with
7.0, SP1/2)
 Integrated Invoice Cockpit (IIC) - replaced by the VIM workplace
 Old Web UI of the Approval portal
 VIM Inbound process will not be supported in the long term
Migration of Process As some Process Types have been migrated to Logical Modules, old
Types Document Type Process Types must be verified. The following checks can
be done:
 Simple check: Firstly, compare your Process Type list against the VIM
7.5 Baseline Standard Document Types. If it is still present in the
standard, then it should work without changes. Otherwise, verify:
– Is it a Business Rule? If yes, this remains as a Business Rule. Verify
that it is enabled for the Document Type.
– Does it update the data? If yes, then it should be migrated to a
Logical Module.
Logical Modules Some processing logic, which was called directly before, is now
encapsulated in logical modules. An example of this is the mapping logic for
additional costs.
New approval workflow Once the COA (Chart of Authority) has been migrated, the customer needs
to continue processing the open workflow tasks.
If they run as-is, the behavior will be unpredictable. The correct approach is
a mass recall and mass resubmit. The new Workflow works with the new
COA.The drawback to this is that approval steps have to be repeated.
The recommendation from OpenText is that customers who are upgrading

should move to VIM 7.5 SP2 (at a minimum) - but to the most recent SP if
possible.
Two different ways in There are two separate approaches for upgrading VIM:
order to upgrade VIM
 Technical upgrade
– A technical upgrade of VIM is minimally invasive to the customer’s
business continuity
– This might include usage of the new index screen and reports such
as new VIM analytics
– VIM Workplace might be used
– VIM Process and logic will be untouched (except the approval
process flow)
 Functional (Full) upgrade
– A full upgrade would include the technical upgrade and would
embrace the functionality changes
– This would Include usage of new features such as the Business
Rule Framework and Logic Modules
– Old custom Business Rules might be needed to be adapted
– New process functions could be activated via a dedicated constant
variable: VIM_VERSION_SWITCH = 7.5
Upgrading to VIM 16.3 There are a couple of variations for upgrading VIM to version 16.3:
 Upgrading from VIM 7.5 SP5 (or later) on SAP S/4HANA
 Upgrading from any VIM version on SAP ERP
Please consult the Installation Guide version 16.3.1, Chapter 6 for

detailed upgrade information.

Help from OpenText Starting with VIM 7.5 SP2, OpenText delivers:
 An Upgrade Guide
 Reports to populate data for the new VAN report and VIM Workplace so
that they work with workflows started before the upgrade.
 Migration tools for:
– Migration of document type and indexing screen settings
– Migration of old COA to new COA
– Mass recall and resubmit of approval workflows
Figure 3-16:
OpenText upgrade
approach
 OpenText Professional Services - Professional Services can be

employed to ensure a successful upgrade, garnering the most value
and most efficient upgrade experience. The previous figure outlines the
following categories:
– Analyze
• Analysis of current VIM configuration
• Sandbox tests
• Analyzing release notes
• Workshop for process changes and new functions
• Proposals for process changes, list of mandatory changes
– Realize
• Change or migration of business rules (logic modules)
• Change screens, user exit, BTE‘s
• Process changes (back to OT standards)
• Improvements of current process
– Utilize
• Documentation
• End user tests and user training
• Upgrade production environment
• Hyper care
Proceed to prepare and perform the upgrade according to Section 7.4 of the
Installation Guide.
Installation troubleshooting and FAQ

Some of the following questions might arise during a new installation:
1. Does VIM consist of any standard SAP objects/repairs?
 No
2. Does VIM consist of any Z objects?
 No
3. How do I check whether installation is successful?
 Refer to the Verification section in this chapter.
4. What is the name space?
 SAP assigns name spaces for its partners; by doing so the changes
to these objects are protected.
5. Can I repair the OpenText objects?
 It is not recommended to repair OpenText objects. Contact
support@opentext.com before making any repairs; OpenText might
have already issued a patch for the intended repair and the same
functionality can be achieved by using appropriate user exits.
6. There is an error when starting the workflow.
 Make sure the standard task is defined as a general task.
Exercise: Verifying the installation
Check the Add-on Installation
1. Navigate to the System -> Status menu from the SAP base menu.
2. Click on the Magnifying Glasses icon in the SAP System data section.
3. Verify the OTEXVIM add on is listed with the correct release number.
Exercise: Obtaining the documentation
Find the VIM 16.3.1 Installation Guide
1. Connect to the OpenText Knowledge Center.

2. Find and download the OpenText Vendor Information Management
16.3.1 for SAP Solutions - Installation Guide.

Summary
This chapter introduced the high level tasks associated with installing and
upgrading the VIM SAP system, along with some detailed information about
upgrades to VIM 7.5. It provided general guidelines along with a link to the
comprehensive installation guide for 16.3 which is provided by OpenText.
Chap ter 4. SA P A rchive Link C ustomizin g for V IM
4. SAP ArchiveLink Customizing for VIM
Objectives

 Find the tables and link tables necessary for ArchiveLink
 Summarize the objects needed to customize ArchiveLink
 Traverse the SAP IMG in the space for ArchiveLink
 Perform the basic steps necessary to customize ArchiveLink
ArchiveLink for VIM

ArchiveLink is a universal interface to integrate external, compliant archive
systems with the SAP system. It enables many scenarios for the integration
of documents directly with business processes. It is an easy and fast
implementation, as the processes are pre-released and standardized.
These ArchiveLink features can be taken advantage of in the VIM context
after customizing is completed.
Figure 4-1: ArchiveLink Customizing for VIM

Cha pter 4. SA P A rchi veLink C usto mi zi ng f or V IM
In this chapter we will do a conceptual review of ArchiveLink and then move

into the actual system steps required for getting started with ArchiveLink
configuration.
ArchiveLink is part of SAP standard basis functionality, but

historically, has had its own release schedule. As such, its
functionality is dependent on its version.
Figure 4-2:
Overview of SAP
ArchiveLink functionality
ArchiveLink leverages the SAP components to provide the following

functionality:
 Archiving from SAP to Archive Center
 Archiving from scanning client
 Archiving of SAP data
 Viewing of documents
 Administration of document links
The advantages of this functionality are:

 It provides an universal interface to integrate every external, compliant
archive system with SAP (such as OpenText Archive Center).
 A complex customer-specific storage system application is not needed.
 Many scenarios, which integrate documents directly with business
processes, are provided.
 It is especially easy to use when integrating SAP Business Workflow.
 It enables an easy and fast implementation because of many released
standard processes.
 Web access to Business Documents via an HTTP interface is provided.
 ArchiveLink compliance certification by SAP guarantees full
ArchiveLink-related functionality of the archive system.
SAP elements used in The SAP-delivered functionality of ArchiveLink is built using foundational
ArchiveLink objects in standard SAP. Database tables, function modules, and the GUI
interface are all key elements in any SAP functionality. The same is true
with ArchiveLink.
Database tables SAP uses database tables and their relationships to each other for housing
master and transactional data that represents the business and its
underlying processes. It also uses them to hold configuration data, which
tells the system how to behave when executing certain processes. In
ArchiveLink the following types of tables are utilized:
 Customizing tables (“meta tables”) - these tables hold information about
the objects that describe the ArchiveLink scenario.
 Link tables - these tables hold the key to linking a document to an SAP
object.
The specific tables used in ArchiveLink will be discussed in detail later in

this chapter.
Function modules A function module in SAP is a set of lines of ABAP code that has a definite
interface. In these modules of code, there are input parameters and output
parameters, tables of data that can be passed back and forth, and explicit
outcomes that can be reported back. These modules are called from certain
places in the system and can be re-used multiple times. ArchiveLink
employs function modules for the following tasks within ArchiveLink:
 Queries for customizing settings
 Document archiving
 Document display
 Document retrieval/download

SAP tables in detail Understanding the SAP database tables and their relationships to each
other is key to understanding any SAP functionality. Here, we will present
several key tables which we utilize for controlling ArchiveLink functionality.
The table names are included here for reference, but the table
contents are created separately via transaction codes which will
be covered later.
Customizing tables and  TOAVE - Document type definitions

the data they store
 TOAAR - Logical archive definitions
 TOAOM - Document type / logical archive linkage
 TOAPR - Pre-settings for document archiving with workflow
Link tables  TOA01 - Links documents associated with SAP data records (objects)
 TOADL - Links print lists; different structure
These are a few examples of tables in the SAP database which are
exclusively used in conjunction with ArchiveLink. The names of most tables
begin with 'TOA', meaning “Table for Optical Archiving”.
When a document is archived and shall be linked to an SAP object, this link
is not stored as part of the object information in the applicable application
module. Instead, some central ArchiveLink link tables hold all object-to-
document link information. This structure yields some advantages:
 Application modules do not have to deal with archive document
information; therefore, documents can be linked to all types of objects
without further preconditions on the application side. However, this does
not imply that all archiving scenarios are applicable across all
applications.
 Multiple documents can point to the same SAP object.
The structure and application of link tables TOA01-03 and TOAHR is

detailed on the following pages.
ArchiveLink provides multiple link tables with the same structure in

order to enable the administrator to distribute table entries to
different database table spaces. ArchiveLink customizing
determines in which table to store link entries for each document
type individually.
SAP ArchiveLink configuration
Figure 4-3: ArchiveLink in VIM
Building blocks The main building blocks for archiving in SAP are: the SAP document class,
the SAP document type, and the SAP object type.
SAP Document Class This category can also be thought of as the technical document class and is
used to distinguish between archive formats (ALF, ASCII, FAX, PDF, DOC).
SAP Document Type This category places an SAP document class in context and serves as an
identifier for similar documents in SAP (FIINVOICE, SDOORDER, D01,
etc.). It is the semantic descriptor for the documents role. Many standard
document types are delivered with SAP. Differing document types are often
handled by differing workflows.
SAP Object Type This category specifies the type of business object that the document will
relate to and the nature of the object itself (i.e. BKPF, PREL, DRAW, FIPP).
It will describe the internal format, key entries, and properties of the SAP
data sets. These are usually predefined and used within one SAP module.

Content Repository The Content Repository (some places in SAP it is still referred to as the
Archive ID) is defined in SAP. It represents the logical place within the
archiving solution, where the archived document will reside. In SAP, the
nomenclature for Content Repository is upper case and two characters in
length. It must match the actual name of the Logical Archive within the
archiving solution.
These concepts come together, along with Document ID and Archive ID to

form the complete identification of a document that is being archived. This is
most easily seen in an example of one such entry in an SAP Link table. The
instructor will log on to the SAP system and show the following structure
within SAP itself.
Figure 4-4:
An entry in link table

TOA01
The above entries are described as:

 Mandt - the SAP Client.
 SAP Object - the SAP Business Object that this document is being
linked to.
 Object ID - the identifier for the above SAP Business Object.
 Archive ID - the Content Repository (also referred to as the Logical
Archive) where the document is stored.
 Archive Doc ID - the Archive Server ID for the image.
 Archive Object - the ArchiveLink Document Type which describes the
scenario.
 Archive Date - the initial date of storage for the image.
 Reserve - the technical description of the file - or the Document Class.
Table TOA01 - Document Elements in the Link Table
1. To view table contents in SAP, the instructor can use transaction SE16
or SE16N. This is called the Data Browser (an example of the SE16
interface is shown in the previous figure).
2. To retrieve an entry in the table, the instructor will populate some of the
fields on the selection screen presented. This might include Client, SAP
object type, SAP document type, or SAP document class.
3. Once an entry is presented on the result screen, it can be highlighted by
clicking on the grey square on the left-most side of the row. The
eyeglasses icon can then be used to look at the full contents of this
record.
In the below figure, the relationship of the link tables and the SAP object
type is depicted.
Figure 4-5: Tables, Object Types, and Link Tables
An SAP table stores a set of static attributes for each archived document.
The archive ID and doc ID that are created for an archived document are
linked using its unique set of static attributes in the link table (e.g, TOA01).
This requires an SAP object type (illustrated above).

Basic customizing For ArchiveLink set up, basic customizing has to be done almost every time
steps a new type of document is prepared for archiving.
Figure 4-6:
Customizing for
ArchiveLink
However, the mentioned steps do not need to be carried out each time. An
existing logical archive may be reused for a new document type, provided
that the logical archive is used appropriately (for example, has the proper
document retention period).
An existing document type included in SAP standard may also be used. In

this case, setting up a new one is not required. But the link of the document
type to the designated logical archive is required.
ArchiveLink basic So far, the focus has been on understanding the conceptual elements of
customizing ArchiveLink - how it works behind the scenes. The rest of the chapter will
deal with configuring ArchiveLink within the SAP system, in preparation for
a VIM project. There are several tasks that must be completed. The
following can be used as a check list for ensuring you have completed all of
the necessary steps:
1. Create/check SAP document class with transaction OAD2 - This is only
necessary if a non-standard document class must be used for
archiving. For example, ASCII is a non-standard document class for
archiving document lists.
2. Create SAP document types with transaction OAC2 - An SAP
document type must be created for each different kind of document to
be archived. For example, one document type for fax invoices and
another one for invoices from document lists.
3. Create link information with transaction OAC3 - Link the SAP object
type and an SAP document type with an Archive ID and a Link table.
The following figure helps to reiterate the relationship between each of the
elements being created.
Figure 4-7: Object relationships in ArchiveLink basic customizing
There are several different menu paths or transaction codes that might take
the user to the same place in the SAP system. Throughout this course,
transaction codes will be primarily used. However, it should be noted that
whenever a customizing task is being performed, if a transaction code can
be used then there is also a corresponding menu path within the SAP IMG.
The SAP IMG can be reached as follows:
1. Type /nSPRO in the command field of the SAP GUI (the /n instructs the
system to open a “new” session and closes the current session. In order
to open an additional session, replace the “n” with an “o”).
2. Click the SAP Reference IMG button. This is the root of the SAP IMG.
3. Drill down to the appropriate level of the IMG to find the configuration
step you need.
The SAP IMG houses all configuration steps for all functionality
within the SAP system. It can be daunting and it is easy to get lost.
The best remedy is to click on the binoculars at the top of the
screen, type in a familiar phrase (for example, ArchiveLink) and
the system will return a hit list of menu paths where the
configuration steps contain the word ArchiveLink.

Transaction SPRO All of SAP customizing is performed in the IMG.
Figure 4-8: The SAP IMG: ArchiveLink Activity
The IMG is generally broken down into sections by functionality and tends
to correspond to the roles of those configuring the system. For instance,
technical communication and system parameters would generally be a task
for an SAP Basis expert, and this is in a distinct location in the IMG. Other
examples would be separate configuration areas for VIM consultants,
ArchiveLink consultants, Netweaver portal consultants, and functional
business consultants.
ArchiveLink customizing might also be reached via the OpenText

IMG, which is transaction code: /n/opt/spro. From there, navigate
to Cross Component Configuration -> SAP ArchiveLink
Configuration. A third alternative is to access SAP transaction
code OAM1 and then to navigate to the menu Customizing ->
Basic Customizing.
For the purposes of customizing the basic ArchiveLink settings required for
this course, the steps will be carried out on a transaction by transaction
basis, which is described next.
Transaction OAD2 This transaction is necessary if a non-standard document class must be

used for archiving. For example, ASCII is the non-standard document class
for archiving document lists. If a new Document Class is required, press the
New Entries button and proceed.
OAD2 is useful when an additional document class is required. In

this case, it is important to add the correct mime type so that the
browser can distinguish which application to start when opening
the images.

Figure 4-9: Transaction OAD2
Transaction OAC2 The next customizing table manipulated by the wizard is the list of
document type definitions (illustrated in the next figure). You can access it
via transaction OAC2. It stores the document type name, description, and
document class (from OAD2) assignment. A fourth attribute “status” is also
included, but it has no significance in the context of ArchiveLink archiving.
For an existing document type, you may alter the description and document
class here. Moreover, you can add descriptions in other languages than the
one used for creating the document type. This is strongly recommended for
companies operating SAP in multiple languages.
You may also choose to create a new document type directly here. To do
this, click the New Entries button to invoke the New Entries: Details of
Created Entries dialog, then enter the requested document type attributes.
If you do so, do not forget to link the document type to a logical archive
afterwards (described in the next step).
Figure 4-10:
Transaction OAC2
Transaction OAC3 This transaction is used to establish a link between the given SAP object
type, document type, and the logical archive. You can review and alter this
information using this transaction. The screen that appears contains an
overview of all the links defined (illustrated below). The fields have the
following meanings:
1. Obj. type - The SAP object to which an archived document of the
specified document type (see below) becomes linked.
2. Doc. type - The archived document to be processed according to this
link information entry.
3. S (“status”) - Effectiveness of the link customizing entry. ‘X’ means
active, everything else means inactive.
4. Content R. ID of logical archive - (content repository) that will receive
documents of the specified document type.
5. Link - Name of the link table where this association is stored in the SAP
database.
6. Ret. per. - Retention period of an archived document (only for
documentation); interpreted as number of months.

Figure 4-11: Transaction OAC3
For editing existing entries, you first have to switch from display
mode to change mode by clicking the Pencil and Glasses icon.
After this, you may also create new entries by clicking the New
Entries button.
Archiving scenarios
Before we discuss the more complicated aspect of customizing the
scenarios which require workflow, it is prudent that we discuss the archiving
scenarios themselves.
Early Archiving In VIM there will be multiple document types that flow through the Early
Archiving Scenario. For each document type, a distinct storage scenario
can be stipulated. There are four storage scenarios available for Early
Archiving:
 Storing for subsequent entry
 Storing for subsequent assignment
 Store and enter
 Store and assign
Storing for subsequent entry is used in VIM processing. This

indicates that the storage of the document happens before its
associated business object is entered.
Scenario-dependent customizing for Workflow

Customizing document archiving with workflow comprises elements of basic
customizing for SAP ArchiveLink (as all scenarios do) as well as scenario
specific parts. In VIM it will be necessary to invoke workflow. Therefore, in
this section we will discuss how to integrate workflow customizing on top of
the basic layer of customizing.
The ArchiveLink document type customizing wizard merges all involved

document type-related customizing steps into a single action, relieving you
of walking through all necessary steps yourself (i.e. you can still use the
wizard for workflow document types).
You can only use the wizard to link the ArchiveLink Document
Type to one SAP Business Object. Therefore, you will need to do
additional customizing (OAC3) after using the wizard.
Workflow Document Setting up a document type for archiving with workflow is therefore
Types mentioned in the next figure as a single customizing step that is shared
between the basic customizing and scenario dependent customizing blocks.
Figure 4-12:
Scenario dependent
customizing
In this customizing scenario, workflow-specific values must be populated.

These are the object method, the workflow task, and the workflow
parameter.
Object Method This tells the system what will happen to the object when the first workflow
step is executed.
Workflow Task Tasks are a part of the SAP Workflow component. They direct certain steps
or an activity in the system in the overall workflow definition.
Workflow Parameters Parameters may be passed for the object method that is called. These are
not necessary in the VIM context.

Agents In addition to the work item recipient specification in the context of

ArchiveLink customizing, at least one agent must be assigned to a workflow
task — meaning that only the assigned agents are allowed to execute this
task. This implies that, performing document archiving with workflow, the
work item recipient determined by ArchiveLink customizing must also be
assigned to the workflow task implied by the document archiving step
(otherwise, archiving the document will fail).
Set up of a Workflow Let’s take an example for illustration. The information that SAP requires
Document Type when setting up a document type is stored in multiple configuration tables.
However, there is no need to maintain each manually. Instead, ArchiveLink
provides a document type customizing wizard that automates editing of the
involved tables into a single dialog sequence. During this sequence, you are
queried for all of the document attributes discussed in previous steps.
For the Store for Subsequent Entry scenario, for incoming invoices, handled
by the SD module, the following values would be used for the workflow
parameters (Agent may be handled with the wizard or without per the
following instructions):
Store and Enter Values All incoming documents
Object Method IDF - Registration of Object
Workflow Task WS00297300
Workflow Parameters N/A
Steps 1. Invoke the customizing wizard by entering transaction OAD5. In the

initial screen, click the Continue button.
2. Enter the name of your new document type and a meaningful
description for it. The name must begin with Y or Z.
3. You are queried for a document type template. If you know an already
existing document type whose attributes you would like to use as
suggestions for your new document type, you can enter its name here.
Normally, you can leave this field empty. Press Continue.
4. Select option Workflow document type (this is critical). Press Continue.
5. Enter the document class (file format) that documents of this type
should have. For scanned documents, this is usually FAX, but other
choices are possible.
6. Enter the SAP object type that the document type is to be linked to.
Furthermore, most of the workflow-related parameters discussed before
are to be entered here:
 Entry section: Only needed for preparing ‘Store and Enter’ and/or
‘Storing for Subsequent Entry’.
 Assignment section: Only needed for preparing ‘Store and Assign’
and/or ‘Storing for Subsequent Assignment’.
If you are preparing “Store and Assign” only, nothing outside of the
object type needs to be entered. The wizard will display a warning
in case you have omitted one ore more entries, but this is okay,
confirm it to continue.
7. The workflow parameters dialog appears only if you have filled out the
Entry section of the previous dialog. It presents a list of possible
workflow parameters for the chosen SAP object type and method. Fill in
the parameter values, if required. (this is not required during this
training class) Press Continue.
8. Enter the basic customizing attributes of the document type: Content
Repository ID (logical archive ID), link table, and document retention
period (number of months). Recall retention period is purely for
documentation purposes in this dialog. Click Continue.
9. This and the remaining dialogs let you decide which presettings (lists of
available document types for archiving; usually grouped according to
departments or business areas) you want to include your document
type in. If you want to add your document type to one or more of the
existing presettings, mark them in the list presented here. If you want to
create a new presetting to add your document to, you may enter one (or
more) at the next screen. Make the following entries:
 ID: A unique four-character, alpha-numeric identifier. Since the list
of presettings is presented in alphabetical order of these IDs, your
identifier will decide the position at which your new setting will
appear within the presettings list.
 Name: The presettings description that will be presented to the user
when he is about to store a document.
You should choose at least one existing entry or specify at least

one new presetting in this step.
10. For each presetting chosen, specify here the workflow agent
responsible for processing a stored document of the given type. Make
the following entries and then click Continue:
 OT (“object type” — left column): The type of the target agent.
 ID: The specific agent for this document type. The value must be an
existing one with regard to the chosen agent type OT.
You may leave the two aforementioned fields empty. In this case,
the SAP user who archives a document is automatically chosen
as the responsible agent for this document. In this training class,
these fields will be left empty.

11. Lastly, enable the desired storage scenarios by making checkmarks in

the corresponding columns. (For viewing the complete column
headings, you may widen the columns by dragging them with the
mouse). For this training class, we will use ‘Storing for subsequent
entry’.
12. Confirm the final wizard dialog by pressing the Complete button.
Agent assignment Agent assignment is performed outside of the customizing wizard.
If you do not want to restrict a workflow task to specific agents,

you can declare it as a “general task”. This indicates that everyone
is allowed to execute it. This is the recommended configuration for
cases without special restriction requirements.
If it is required that a task must have a specific agent assignment:

1. Enter transaction PFTS; the Maintain Standard task screen appears.
2. Enter the number of the task to be maintained in entry field Standard
task, i. e. 30001128 for the default “document entry” task and click the
Display (glasses) button; the Standard Task: Display screen appears.
3. Choose menu item Additional data -> Agent assignment -> Maintain;
the Standard task: Maintain Agent Assignment screen appears.
4. To assign a specific agent, continue as follows: Click the displayed task
name and choose menu item Agent assignment -> Create; the Choose
agent type (possible values in next table) dialog appears. Choose an
agent type. Depending on the chosen type, a selection dialog appears
where you can search for and select a specific object.
5. To declare the task as a “general task”: Click the Properties button; the
Task: (task name) dialog appears. Select option General task and
confirm with the Transfer button.
Label Name Description Examples
US User Single SAP User as JOESMITH

maintained in SAP user
management
P Person Employee as maintained Joe Smith,

in SAP HCM Personnel #123
S Position The SAP user with this Director of Sales

position maintained Finance Manager
C Job All SAP users with this job Material Handler

assigned Line Worker
O Organizational Self defined set of SAP Payroll

Unit users Administration
NA Sales Group
Label Name Description Examples
A Work Center Members of a certain Plant 1000

aspect of the company QA Inspection A-1
Empty none The user who archives the

document
The above table shows the possible types of workflow agents for document
archiving with workflow.
Most of the types assume a set of multiple SAP users as possible work item
executors. All included executors can access the work item in their
respective workplace inboxes; as soon as the first one opens the work item,
it automatically disappears from all others’ inboxes.
Since it is almost always reasonable to have a group of users as a workflow

agent, “organizational unit” is the most commonly used agent type.
Example of setting up a Here, we show the steps used in invoking the customizing wizard to create
Workflow Document an ArchiveLink Document Type.
Type: using the Wizard,
transaction OAD5 1. Invoke the customizing wizard by entering transaction OAD5.
Figure 4-13: Transaction OAD5
2. Click the Continue button.

Figure 4-14: Create the ArchiveLink Document Type
3. Enter the name of the new document type and a meaningful description
for it. The name must begin with ‘Y’ or ‘Z’. Click Continue to proceed.
Figure 4-15: Document Type template option
4. If there is an existing document type whose attributes could be used as

suggestions (“template”) for the new document type, it could be entered
here. Normally, this field is left empty. Click the Continue button.

Figure 4-16: Activating Workflow
5. Select the Workflow document type check box. Click the Continue
button.
Figure 4-17: Document Class
6. Choose the Document Class FAX. Click the Continue button.

Figure 4-18: Business Object and Workflow specifics
7. Enter the type of SAP objects that documents shall be linked to. Begin
with /OTX/PF01R, which is for the incoming Document. Also, enter the
Workflow Method and Task which correlate to the scenario you are
customizing:
– Method: IDF- Registration of document
– Task: WS000297300
Press the Continue Button. A warning will pop up, click on the Green
Check mark icon to accept it.
Figure 4-19: Content Repository, Link table, and Retention period
8. Make the following entries:

 Cont. Rep. ID - The ID of the logical archive (use V7 for training)
that shall receive the documents.
 Link - The name of the link table where ArchiveLink shall store
document links. TOA01 is one example.
 Retention per. - Designated document retention period (number of
months). This is only for documentation. Documents will not be
deleted automatically. This parameter can be left empty.
9. Click Continue.

Figure 4-20: Existing Presettings
10. If a new presetting is desired, press Continue. Otherwise, choose the

existing presetting and then click Continue.
Figure 4-21: Create new presettings
11. Optional: Choose an identifier. 0000 would appear as the first entry.
ZZZZ would appear as the last. For this training class, use 00##, where
## is your user number.

Figure 4-22: Choose the Archiving scenario
12. Choose the Archiving scenario using the check box ‘Storing for
Subsequent Entry’ (this scenario and the others are described in the
next section). Click Continue.
Figure 4-23: Complete the Wizard
13. Confirm the final wizard dialog by pressing the Complete button.

Linking additional Now that the ArchiveLink Document Type has been created, the additional
Objects to the SAP Business Objects which will reference your archived image, should be
ArchiveLink Document linked to this ArchiveLink Document Type. Use OAC3 to create new link
Type entries via transaction OAC3.
Figure 4-24: Transaction OAC3
Presettings Presettings are used to pre-populate the values a user needs to start the
archiving scenario. The system allows these to be saved for convenient
reuse. A presetting folder represents a preset group of ArchiveLink
Document Types. The group contains the types that are related by
workplace or by application. Grouping types together in a preset group
provides a more effective overview of ArchiveLink Document Types on the
initial screen of the storage process Store Documents (transaction code
OAWD).
Figure 4-25: Transaction OAWS
Step by step The below steps iterate how to view and/or maintain document archiving
presettings:
1. Enter transaction OAWS; the screen Change View ‘Default setting’:
Overview appears, displaying a list of all defined presettings on the right
window pane.
2. Add, rename, or delete presettings, using the taskbar buttons.
3. To view/edit on document type level, continue as follows:
 Mark the presetting you want to view/edit by clicking into the empty
rectangle button to the left of the list entry.
 In window section “Dialog Structure”, double-click Entries; the
screen Change View ‘Entries’: Overview appears, displaying the list
of document type entries of the chosen setting.
 You may now add, change, or delete document type items, using
the taskbar buttons.

OAWD ArchiveLink provides personalization options for each SAP users archiving
presettings. To maintain your personal view, enter transaction OAWD
(“Store documents”), then choose menu item Settings -> User settings. The
dialog which is shown in the next figure will appear.
Figure 4-26: Transaction OAWD for personalization of PreSettings
Several of these options are explained here:

 Fastpath to storage scenarios: When disabled, no scenario icons are
displayed in the presettings lists (transaction OAWD). To select a
scenario, you must double-click the document type name; this will bring
up another dialog box giving the choice among the enabled scenarios.
 Display key not long text: Normally, the presettings list will represent
presettings by their names. However, names need not be unique. To
have an unambiguous presettings identifier displayed, select this
option; presettings IDs will then be displayed instead of their names.
 Limit view to: Some users who are archiving documents will never need
to visit more than one specific presetting (that corresponds to their
business activity or department). In this case, this option can be chosen
to jump directly into a setting when a document should be archived,
omitting the intermediate step of choosing one of the available
presettings. In order to activate this option, select the desired presetting
from the list prior to opening the User settings dialog.
Exercise: Customize an ArchiveLink Document Type for Workflow

In this exercise you will create a Workflow-enabled ArchiveLink Document
Type using the Customizing Wizard (transaction OAD5). We will use the
scenario of incoming invoice images that are manually indexed (non-OCR).
Adhere to the following naming conventions:
 Document Type - Z##_INV (where ## is your assigned participant
number)
 Document Class - FAX
 SAP Business Object - /OTX/PF01R
 Workflow Task - WS00297300
 Workflow Method - Registration Incoming Document
Customize an ArchiveLink Document Type
1. Log on to the SAP system with your user. User-## where ## is your
assigned participant ID.
2. Type /nOAD5 into the command field, and press enter.
3. Click the continue button.
4. Enter the name Z##_INV in the field Doc. Type. (## should be replaced
by the participant number - assigned by the instructor).
5. Enter a meaningful name in the name field, and click continue.
6. Leave the template Doc.type field blank, and click continue.
7. Check the workflow document type check box, and click continue.
8. Type FAX in the document class field, and click continue.
9. Type /OTX/PF01R in the Obj. Type field and WS00297300 in the Task
field and click continue.
10. Click the Green check mark when the warning pop up appears.
11. Populate Cont.Rep.Id and the Link fields, with A1 and TOA01
respectively, populate Retention per. = 120(optionally), and press
continue.
12. Do not choose an existing presetting. Click Continue.
13. For your presetting, use ID = 00XX where XX is your participant
number. Populate the Name field with something meaningful, include
your name or participant number for quick reference later. Click
Continue.
14. Choose the ‘Storing for Subsequent Entry’ scenario (the first check
box). Do not populate any other fields. Click Continue.
15. Click the Complete button.

16. When the prompt for a customizing request is presented, click on the
Paper icon to create a new request. Give it a descriptive name. Use the
Save icon and assign your customizing to this request for the rest of the
class.
In this exercise, the steps for the Customizing Wizard are dictated.
However, the single SAP transactions could be employed
alternatively.
Exercise: Link additional SAP Object Types to your Workflow Document Type
In this exercise you will link three additional SAP Object Types to your
Workflow Document Type(s) (created in the previous exercise) using
transaction OAC3:
 Link Z##_INV (manually indexed invoices) with /OPT/V1001, BUS2081

and BKPF.
Link additional SAP Object Types
1. Type /nOAC3 into the command field.

2. Press Enter.
3. Use the Eyeglasses icon to move into the Change View.
4. Find the existing entry for your document type, highlight it.
5. Click on the Magnifying Glass icon to view the details.
6. Click the Copy icon.
7. Change the following field:
a. Object Type
8. Click the Green check mark.
9. Save your entry.
10. Repeat for each object type and document type combination.
Summary
In order to set up the link between SAP and Archive Center, the standard
ArchiveLink interface is used. In order to utilize this interface for VIM, the
concepts of ArchiveLink were introduced. From these concepts we see that
we can link a document to a descriptive document type, to a document
class to describe its file format, to an SAP object to describe its processing,
and to a logical archive to tell where it will be placed on the Archive Center.
In order to invoke the more robust workflow scenarios, we investigated how
to customize workflow settings associated with a document type.
Chap ter 5. VIM Role Fr amewo rk
5. VIM Role Framework
Objectives

 Build a VIM Role
 Explain Role Determination in VIM workflow scenarios
 Identify Baseline Roles
What is the VIM Role Framework?

Roles In Vendor Invoice Management, a role is used to define a group of various
business users who perform the same business tasks within an activity.
Role definition in VIM is configurable by the customer, allowing for unique
business situations to be accounted for. A VIM role will ultimately determine
which SAP Agent will be called for certain workflow tasks. Essentially this
tells the workflow whose inbox to send a workflow task to.
So, VIM Workflow queries VIM Role Resolution in order to determine the
SAP User and their authorizations, which is then sent back to the workflow
for correct routing of tasks. This is depicted in the figure below.
Figure 5-1: Role to Agent interrelationship
At a high level, the VIM role infrastructure:

 Is a thin layer over the SAP workflow rule framework
 Provides one intuitive standard infrastructure for maintenance
 Is used in VIM Central Reporting

Cha pter 5. VI M Ro le Fr amew ork
Baseline Roles Some of the standard VIM roles that are provided out of the box by
OpenText are:
 Scanner
 Indexer
 Duplicate Analyst
 Accounts Payable Expert
 Accounts Payable Processor
 Buyer (PO)
 Requisitioner or Requestor
 Receiver (PO)
 Approver
 Coder
 Vendor Maintenance
 Contract Agent (PO)
 Tax Expert
 Information provider
 Service Requestor
 Service Approver
Step by step: Create a In order to create a Role, the following steps should be followed:
Role 1. Type the /OPT/CP_9CX5 transaction code into the command field.
Press Enter.
Figure 5-2:
Transaction /OPT/
CP_9CX5
2. Select the New Entries button.
Figure 5-3:
New Entries interface
3. Populate the following fields:

– Product Code - Possible values for Product Code are: 005 and PIR.
– Role - The name of the new role.
– Description - The description of the new role.
– Additional Key Determination Function Module - If applicable, enter
the name of the function module which will determine the agent. (In
order to reach the other fields in this interface, the user must scroll
to the right, pictured in the next figure).
Figure 5-4:
Other Fields in the Role

creation interface
– Key Determination - If applicable, select the check box.

A role must have a template assigned to it. A template carries with it

attributes that with the help of template fields and field mappings will
correlate to the SAP business object attributes. This is referred to as the
VIM Role Framework. A visual description of this is depicted in the next
figure.
Figure 5-5: VIM Role framework
To summarize the main concepts of the VIM Role Framework, it is made up

of Roles, Role Templates, and Template Fields. We have covered roles,
now we will look more closely at Role Templates.
Role Templates Each role is based on a Role Template. Role Templates control how a Role
is resolved. One template can be re-used for multiple roles. A template is
usually defined by the Configuration consultant. There are three types of
Role Templates.
 Organizational Unit based - In this type of template, role resolution is
semi-dynamic. This is because this template tells the workflow to send
the task to a certain Organizational Unit. This could be a Work Center or
a Position. Since assignments of personnel to each Organizational
Object can change, the routing can change as well. For instance, if the
template assigned a Work Center to a Role, all of the personnel who
are attached to that Work Center (perhaps Tax Agents) would be the
recipients of that workflow task.
 Function module based - In this type of template, role resolution is

dynamic. Custom logic or baseline logic can be incorporated into a
function module that is assigned to the template. An example of this
would be logic that determines that the Buyer (Role) is the PO creator.
The PO creator is determined by a function module which extracts the
PO creator from the Purchase Order.
 Field based - In this type of template, role resolution is static. This used
to be referred to a Key Determination type. This type of template is
made up of template fields pointing to multiple business object
attributes. This type allows for easy maintenance without the need for
programming.
Figure 5-6: SAP Role Template definition overview screen
Step by step In many cases, a standard delivered Role Template from OpenText will
(optional): Create a meet the needs of the customer. However, if a need arises for a custom
Role Template Role Template, the following series of steps can be followed:
1. Type the /OPT/CP_9CX2 transaction into the SAP command field.
2. Press Enter.
3. In the Product Role Templates Configuration Overview screen, double-
click Template Definition in the navigation pane.
4. In the Template Definition Screen, populate the following fields:
 Template ID - A descriptive character string for the new template.
 Description - The description of the new template.
 Type - Function Module Based, Org Unit, or Field Based.
 Object Type - For org unit based templates only. The Organizational
Unit type (i.e. Position, Work Center).
 Agent ID - For org unit based templates only. The organizational
units identifier (ie. Position number or Work Center number).
 Function Module - For function module based templates only.

Creating Role Template Role Template Fields must only be maintained for Field-based templates.
Fields and Field Details Template Fields enumerate they key fields used in role determination. Once
the Fields and their value sets are populated, the Field Details should be
maintained. This distinguishes how each field behaves according to Product
Code. For more information on how to create the Fields and Field Details,
see the VIM 16.3.1 Configuration Guide.pdf.
Step by step: Once a template definition is created, it can be assigned to multiple VIM
Assigning Templates roles.
to Roles 1. Type transaction code /OPT/CP_9CX2 into the SAP command field.
Alternatively, navigate to the VIM-specific Easy Access menu, expand
the Roles folder, and highlight Template Maintenance.
Figure 5-7:
Template Maintenance
menu path
2. Double-click this entry.
Figure 5-8:
Transaction /OPT/
CP_9CX2
3. Click on New Entries.
Figure 5-9:
New Product Role

Template configuration

4. Specify the following fields:

 Product Code
 Responsible party
 Template ID
 Active check box
If the Active check box is not selected, then the Role to template
assignment will not be used by workflow. This allows for multiple
assignments to be in configuration, but for exactly one to be picked
up by the system at any given time.
5. Save your entries.
Role Determination or At this stage, the Roles have been created (i.e. AP Processor), the
Resolution Templates have been created (i.e ORGUNIT), the Template to Role
assignment has been made (i.e. the AP Processor role in Product Code 005
will be determined by Org. Unit). The last remaining step is to establish
which organizational unit for Product code 005 will be the AP Processors.
This is Role Determination. In this step, you define the runtime values that
the system uses to resolve roles for a given product code.
These values are populated in the following manner:
Step by step: Setting up 1. Type transaction code /OPT/CP_9CX4 into the command line.
Role Determination Alternatively navigate to the VIM Easy Access Menu and choose the
Simple Mode Role Maintenance option.
Figure 5-10:
Menu for launching the

Simple Mode Role
Maintenance
2. Double-click this entry.
Figure 5-11: Role / User Management maintenance transaction
3. Ensure you are in Change mode and on the left pane, highlight the role
that you want to assign values to.

4. In the right hand pane:

– If the template type is Field-based:
• Maintain values for the fields displayed.
– If the template type is Function module-based:
• New Func. Module- Enter the custom function module for role
determination.
– If the template type is Org. Unit, fill in the following fields:
• New Agent Type- Select the agent type (US for user ID, S for
position etc).
• New Agent Id- Depending on the agent type, select the agent Id
(SAP user ID, position etc.).
Fail Safe and Default Key Within the User Assignment Interface, in the last diagram, the fields for Fail
Safe and Default Key were introduced. These are explained further here:
 Fail Safe - If Role Determination fails for this Role, the task is assigned
to the agent in the Fail Safe field.
 Default Key - If a particular user should always be the default agent for
a task, then that agent should be in the Default Key field.
In order to populate these fields, use transaction code /N/OPT/CP_9CX10.
Figure 5-12: Fail_Safe Role / User Management
Figure 5-13:
A Summary of Role
Resolution customizing
in the VIM component
Exercise: Identifying Template definitions

In this exercise, for each of the listed VIM roles, you will identify the active
template ID used and details behind each template definition:
VIM Role Active Template ID Template Details (Business Object attributes,

and Type FM, or Org Unit)
005/INFO_PROVIDER
LIX/RECEIVER
Identify template definitions
1. Enter transaction code /OPT/CP_9CX2 into the command field.

2. Press Enter.
3. Find the listed VIM role, and enter the details into the above table.
Exercise: Creating two new Roles

In this exercise you will create two new roles for product code 005:
 Z##INDEXER
 Z##APPROC
Create two new roles
1. Enter transaction code /n/OPT/CP_9CX5 into the command field, press

Enter (Alternatively you could open the VIM Easy Access Menu, open
the Roles folder, and choose Role Maintenance).
2. After ensuring you are in Change mode, click on the New Entries
button.
3. For the two VIM roles, enter the Product Code, Role, and Description
fields.
Exercise: Connect your New Roles to a Template definition
Connect your roles to one or more template definitions
1. Return to the /OPT/CP_9CX2 transaction code main menu

(Alternatively you could open the VIM Easy Access Menu, open the
Roles folder, and choose Template Maintenance).
2. Highlight the Product Role Template Configuration folder in the left hand
pane.
3. Click on the New Entries button.
4. Populate the relevant fields for each of your new roles and your new
template.
Exercise: Connect the new Roles to Agents
Connect your two Roles/Template assignments to an SAP User, Work

Center, or Organizational Unit
1. Enter transaction code /OPT/CP_9CX4 in the command

field.(Alternatively you could open the VIM Easy Access Menu, open
the Roles folder, and choose Simple Mode Role Maintenance).
2. Press Enter.
3. Highlight the Product Code with Active Template on the left hand pane.
4. Double click this folder.
5. Ensure you are in Change mode.
6. Populate Agent Type and Agent ID (a suggestion would be to use Agent
Type US and your SAP User ID: User-##).
7. Click Save.
8. Repeat for the second Role.
Summary
In this chapter, the concept of the VIM Role framework was introduced. The
concept of a role to define the users responsibilities in the system was
introduced. Templates for assigning certain criteria for role determination
were discussed, along with the eventual assignment of a template to a role.
Lastly, the assignment of values or agents to the Product Role Template
combination was covered. With these three new concepts, the VIM Role
framework is fully defined.

Test your knowledge
1. Which type of template can be used in the following scenarios:
 The Requisitioner should be the value in the field Requisitioner within the PO in the line
item field.
 There are two users who handle all vendor maintenance for the organization. They belong
to the Master Data group.
 Each AP Processor should own one Company Codes invoices.
 Each Buyer should be assigned to handling invoices for a specific Plant.
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
C hapt er 6 . B usiness C ent er Inboun d C onfigu rat ion
6. Business Center Inbound Configuration
Objectives

 Identify the elements of Inbound Configuration
 Monitor incoming documents in Inbound Processing
 Customize aspects of Inbound Processing
Overview
VIM uses Business Center Inbound Configuration for incoming invoices. It is
designed to receive and pre-process documents in many formats. When
used with VIM, it supports scanning, OCR, e-mailed invoices, invoice
upload, and OT Archive Pipelines (batch Load, stand-alone scanning
without OAWD) as input.
Figure 6-1: Business Center inbound processing

Cha pter 6. Busin ess C enter In bound Conf igur ation
Inbound Configuration determines or generates (e.g. manual indexing) all

index data from invoices. Index data is saved in so-called mapping ID's.
From these tables the subsequent processes pick up the index data.
Invoices can be paper, PDF, XML and IDOC formats. It can be extended
through customizing and additional service modules for flexible support of
all incoming formats. This might include for example, rendering of IDOCs
and XML files or extracting data from XLS and other formats.
Architecture
Inbound Configuration is a Business Center component, an OpenText add-
on to SAP (used here for VIM). Invoice input occurs through SAP channels
such as IDocs, the non OCR interface, the global RFC interface, or the
OpenText OCR interface. Once into the system, the framework then hands
the document off to the DP pre-processing steps in order to determine how
it should proceed through the VIM framework.
Figure 6-2:
BC Inbound
Configuration
architecture
Customizing Inbound With Inbound Configuration, customization dictates how a document is

Configuration imported or captured and then dispatched, in the case of VIM to a
subsequent workflow or to archiving.
Inbound Configuration allows the user to configure scenario classification.

Scenario classification registers documents for further processing in
Business Center according to their business context, for example: Sales
Orders, Delivery Notes, or Invoices. The user can also configure how the
documents are processed coming from different channels.
Each document runs through defined process steps, which are indicated by
the inbound handler process. Each process step comprises several service
modules.
These Service Modules which are integrated components of Business

Center Inbound offer specific functionality.
Figure 6-3: Inbound Configuration
Each document runs through defined workflow steps indicated by the

Inbound Configuration process. Workflow steps consist of an ordered
number of Service Modules. These Service Modules are integrated
components of the framework that offer the defined functionality. You can
enhance the Service Modules by adding new entries in customizing. In
order to start customizing, the user should access the transaction code
/N/OTX/PF00_IMG. This will open up Business Center specific
configuration. Navigate to Inbound Configuration, where the main
configuration items are located.
Implemen ting Documen t Mana gement wit h OpenT ext e DO CS D M Pa ge 6- 3

Figure 6-4:
Inbound Configuration
IMG tasks
The following items can be configured from here:

 Channels uniquely identify the source of an incoming invoice to the VIM
system across the landscape. This can be, for example, paper through
scan, fax, email, or IDoc. To configure a channel, you need the
registration type.
 Scenario Classification registers documents for further processing in
Business Center according to their business context. In other words, it
gives a semantic description of the process which should occur for the
incoming data (i.e. Vendor Invoice Management should be triggered for
incoming invoices).
Figure 6-5: Scenario Classification
 Registration Types define the scenario which is used to import

documents. The import can happen, for example, by email, IDoc or
Document Pipeline. Depending on the registration type, standard SAP
customizing is needed, for example, for ArchiveLink or SMTP.
 Document Handlers route the incoming document through the inbound
process. They must be customized to sequentially process the
document, based on the respective document status. This is done via
Service Modules.
 Service Modules define a specific functionality (via a module class) that
can be used by one or more Handlers.

Figure 6-6: Inbound Configuration items configured for VIM
Next, we take a look at each of these more closely.
Channels Channel IDs are maintained in order that the source of a incoming invoice
can be identified. In the case of multiple system landscape scenarios it
becomes critical to maintain Channel ID as the ID is tied to the system
determination procedure.
Figure 6-7: Channels
For VIM, as shown in the previous figure, the ICC channel is used for those
documents which are coming in via OCR. This and the other channels are
pre-delivered. Custom Channels can be created as well.
Document Handlers A Document Handler defines the process which is used to route documents
through the incoming document process, and can therefore be linked to one
or more Channel IDs. It describes a defined order of Service Modules.
Figure 6-8: Delivered Document Handlers
Service Modules A Service Module is essentially a grouping of logic that can be performed on
an incoming document to achieve a certain desired output. Service Modules
are grouped together via the Document Handler. Some examples of Service
Module functionality:
 data mapping
 data transformation
 registration
 archiving
 validation

OpenText delivers predefined Service Modules for the VIM Capture Center
Document Handler (PS03_CAPTU) as follows.:
Function Class Name
Archive documents and /OTX/PF01_CL_MODULE_ARCHIVE

attachments
Linking archived document to a /OTX/PF01_CL_MODULE_LINK

registration object
Register the document in VIM /OTX/PS03_CL_VIM_MODULE_REG
Register extraction /OTX/PF01_CL_MODULE_CC_EXTRAC
Wait for extraction completed /OTX/PF01_CL_MODULE_CC_WAIT
Register validation / processing /OTX/PS03_CL_VIM_MODULE_CC_VAL

(Extraction)
Wait for validation completed /OTX/PF01_CL_MODULE_CC_WAIT
Register processing /OTX/PS03_CL_VIM_MODULE_CC_PRO

(Extraction) after validation
Registration Types Registrations are configured for each incoming document scenario. They tie
all the previously introduced elements together. The corresponding
Channel, Document Handler Module, Classification, and Document Types
must be assigned. For ICC input (and the ZVIM_ARCH Document Type),
an example Registration is available for the Early Archiving scenario. This is
shown in the next figure.
Figure 6-9:
Registration: Early
Archiving
Data Mapping Finally, the mapping of incoming data to VIM data must be done. Mapping
fields on an incoming invoice to the target fields in VIM is accomplished via
the Mapping IDs. A Mapping ID is created to logically group a mapping set
for a particular channel. A Mapping ID is then tied to that Channel.
Figure 6-10:
Mapping IDs
Each Mapping ID is unique as the inbound fields are different, depending on

the medium. For example, for the ICC channel, the following typical fields
are captured and stored by ICC:
 CompanyCode
 InvoiceAmount
 InvoiceCategory
 InvoiceDate
 InvoiceDeliveryDate

Via transaction code /n/OPT/VIM_MAPV, Mapping IDs can be configured.
Figure 6-11: Field Mapping for the ICC Mapping ID
The options for effectuating mapping via configuration are:

 Direct field mapping
 A Function Module for external field mapping in the case where simple
one to one mapping does not suffice (use interface pattern /OPT/
DO_MAPPING)
 Automated Field Enhancement which is used if a function module is
added to implement the enhanced field function
e-invoicing scenario
With this framework, the concept of E-invoicing can be implemented with
VIM. In this scenario discussion, the assumption is that invoices are sent to
the customer via e-mail. First, the VIM SAP system must be prepared for e-
mail input.
The tasks to check for this processing follow.
Preparing e-mail input  Configure the Profile Parameter (Transaction Code: RZ10)
– Edit the Instance Profile with Extended maintenance
– Set the SMTP port to 25
– Check if the SMTP service is active (Transaction Code: SMICM)
 Customize Service User (Transaction Code: SU01)
– Create a user with type Service and assign the profile S_A.SCON.
This is for communication.
 Assign the SAP System Client (Transaction Code: SICF)
– Choose Virtual Host SAPCONNECT
– Enter the logon data of the system user
– Add CL_SMTP_EXT_SAPCONNECT to Handler List
 Administer SAPconnect (Transaction code: SCOT)
– Check if the mail host is configured
– Enter the Default Domain of the SAP system client
– Define Inbound Processing (Settings -> Inbound Processing)
e-mail specific E-invoicing requires some special considerations.

configuration
Initiating Workflow The start of the incoming document workflow can be triggered by specific
information that is extracted from the incoming e-mail. For example, the
type of attached document that should initiate the incoming document
workflow can be specified. If the e-mail has other documents with different
mime types attached, these documents are handled as simple attachments
to the specific work item.
In order to effectuate this, the function module (use default FM

/OPT/C_IDH_CUSTOM_MAIL_HANDLER) would be populated in the
parameter called IDH_MAIL_ATT_HANDLER. This parameter is in the
Webflow Constant Table (/PTGWFI/Z_CONST).
Logging A couple of options exist for monitoring the activity of e-mail based input.
The first is to view logging e-mail data via SAPconnect Inbound send
requests (Transaction Code: SCOT). From the main menu, access Utilities -
> Inbox Overview. The user can also view incoming e-mail data in the IDH
table /OPT/CT_IDH_MAIL. This table data is available as input for reporting
later.
The standard product does not support sending e-mails back to

the sender or forwarding messages to SAP Business Workplace.

The Document Pipeline

Incoming documents can be handled using the OpenText Document
Pipeline. Document Pipeline processing must be linked to the defined
function module of the Inbound Configuration inside SAP. A specific RFC
mode must be set that matches the customizing entry on the remote
Document Pipeline.
Additional information on the Document Pipeline can be found in

the OpenText Business Center for SAP Solutions configuration
Add guide.
EDI configuration
The Electronic Data Interchange (EDI) scenario in VIM is based on the
standard SAP document format Intermediate Document (IDoc). IDocs allow
different application systems to be linked through a message-based
interface. The following list shows some examples of the benefits customers
garner from using IDocs.
 Business documents are exchanged in a structured way in order to
process them automatically.
 The various degrees of structural complexity as displayed by different
application systems can be reduced to a structure which is as simple as
possible.
– Example: The structure of an SAP application document and the
structure of the corresponding EDI message under the UN/
EDIFACT standard.
 IDocs allow for extensive exception handling before the data is posted
to the application.
Incoming IDocs are often the means by which a customer utilizing SAP AP
receives some of their invoices. This can be integrated into the VIM
Process. In order to receive invoices as IDocs and subsequently trigger VIM
processing, the ALE configuration must be done along with configuration
that is specific to VIM.
Please see the OpenText Business Center for SAP Solutions

16.3.1 Configuration Guide for detailed information on how to
configure the EDI Scenario.
Integration with the SAP Adapter for the Ariba Network

Ariba is an e-commerce solution, which allows the customer to collaborate
with their suppliers in an electronic network. For those customers who
already employ the Ariba network, there is now a streamlined way to
integrate the Ariba Network with the Vendor Invoice Management Solution.
Integration with VIM can be integrated with the Ariba Network from the buyer perspective. In
Vendor Invoice this scenario:
Management  Suppliers create invoices within the Ariba Network
 Invoices are sent to the SAP ERP system of the buyer
 The buyer processes all incoming invoices within VIM
Besides local invoice channels (e-mail, or scan, or OCR), the buyer is

connected with the Ariba Network and receives invoices of his suppliers
from this channel.
Advantages of VIM/ With the standard SAP/Ariba integration, invoices are posted or parked
Ariba Integration automatically in the SAP System. If the customer integrated VIM, they have
the opportunity to catch any invoice exceptions, handle them via the DP
workflow, and then to process them to completion.
Integration Scenarios Ariba can be integrated in different ways within the SAP Business Suite.
PI Adapter Scenario In the first scenario, an integration with the SAP NetWeaver Process
Integration (PI) in combination with the Ariba PI adapter is possible. In this
scenario, invoices arrive in IDoc format (INVOIC02) to the SAP system of
the buyer.
Figure 6-12: The Ariba Network integrated with VIM via the PI Adapter

SAP Add-on Ariba In the second scenario, it is possible to connect Ariba with the new SAP
Network Integration for add-on Ariba Network Integration for SAP Business Suite. Technically, the
SAP Business Suite invoices are sent in cXML format.
Figure 6-13: The Ariba Network integrated with VIM via the SAP Add-on
For this second scenario, OpenText delivers a significant amount of

baseline configuration for getting the customer started with this integration.
Included in baseline configuration are the following:
 Ariba Mapping ID
 Ariba Channel
 Supplier Network Processing
The Ariba Mapping ID is shown in the next figure.
Figure 6-14: Pre-delivered Field Mapping
Next, the pre-delivered Channel for Ariba is shown.
Figure 6-15: Ariba Channel

Lastly, the Ariba Supplier Network Processing is shown.
Figure 6-16:
Supplier Network
Processing
Both scenarios allow for the inbound processing of the invoice

data and outbound update of the status of the invoice to the Ariba
Network. Additional details for configuring either of these
scenarios can be found in the VIM for SAP Solutions Configuration
Guide 16.3.1 Chapter 23.
Exercise: Perform Inbound Configuration for your new ArchiveLink Document

Type
In this exercise you will use transaction /n/otx/pf00_img to configure the
inbound scenario to link to your ArchiveLink Document Type.
Perform inbound configuration
1. Type /n/otx/pf00_img into the command field in SAP.

2. Press Enter.
3. Navigate to Inbound Configuration -> Document Handler ->
Registration -> Early Archiving.
4. Double-click this task to execute it.
6. Use the following values to create a table entry:

 Document Type: Z##_INV (your own)
 Channel: OAWD
 Module Handler: INDEXING
 Classification: PS03_VIM_INVC
7. Press the Save icon.
Summary
In this chapter we introduced Business Center’s Inbound Configuration tool.
This tool is used for configuring the system to handle incoming documents
from inception through to the trigger of the VIM system processing. We
introduced main configuration elements and also covered exceptional
inbound scenarios such as e-invoicing and Ariba invoicing.

Ch apter 7. Do cument P ro ce ssing
7. Document Processing
Objectives

 Identify the main concepts of Document Processing configuration
 Configure Document Types, Process Types, Process Options, and Business Rules
 Recognize advancements in Document Processing, coined ‘Best Practices’
 Perform some advanced configuration options
Document Processing Overview

Document Processing can be explained as the pre-processing of all
incoming documents that are to go through VIM. It is an intermediate stop
along the way as a paper or electronic invoice becomes an SAP posted
document. This is a way for invoices to be checked for erroneous or missing
data and duplicates prior to attempting to post the document in SAP. The
input to Document Processing is the paper based invoice, the output is an
SAP document.
Figure 7-1: Document Processing in the VIM

Cha pter 7. Do cu me nt P roc e s si ng
Customizing An overview of the steps involved in customizing the Document Processing

Document Processing follows:
1. Identify and configure the various Document Types
2. Create relationships between Document Types and respective
ArchiveLink Document Types
3. Make determinations about manual versus automated processing of
Document Types
4. Identify any logical modules required for each scenario
5. Identify the process types required for each scenario
6. Identify and configure the indexing screen fields
7. Identify and configure all roles required within each scenario (or
process type)
8. Identify and configure the process options associated with each swim
lane
9. Identify and configure the business rules (process type determination)
10. Configure the Business Rules Framework (BRF)
11. Configure global customization settings
Figure 7-2: Document Processing
Main concepts
Some of the basic concepts of Document Processing are newly introduced.
A detailed explanation of each follows.
Product Codes Product Codes delineate the VIM system according to the functionality.
These codes, when seen in the technical namespace should clue the user
or developer in to where the functionality lies or its use. The following
product codes are typically referred to:
 005 - DP Document Workflow
 LIX - MM Invoice Exception Workflow
 IAP - Invoice Approval Workflow
Best practices for Best Practices are used to support automation and compliance and improve
document processing process control and consists of the following three features:
 Logic Modules - newly introduced
 Business Rules - changed in this version
 Auto Post Determination - newly available
Each element of Best Practices will be further explained in this chapter.
Document Types The DP document type is not the same as the SAP document type. The DP
document type controls how the scanned document is analyzed for
exceptions and routed for resolution. It also determines which SAP
transaction will be called for document creation and the fields available for
indexing. The person doing the scanning must choose the document type
when setting up the scan. If the incorrect document type is chosen, the
incorrect SAP document type and workflow will be initiated. The document
types will map to either an SAP PO invoice, an SAP Non PO Invoice, a
Credit Memo, or a Freight Only Invoice.
Documents types should be used as global templates for invoice

processing; whereas more detailed configuration for processes and
screen layouts can be done at the invoice characteristic level. This will be
discussed later.

Step by step: Setting up As a result of swimlane workshops (discussed in the chapter on

custom Document Types Implementation Methodology), a project team is ready to start the
Document Processing configuration. The main building block for this
configuration is the Document Type. In most cases, OpenText would
recommend copying one global document type as a template for a
customers own Document Type. The following steps outline how to do this:
1. Enter Transaction Code /OPT/VIM_1CX1 in the command field.
2. Press Enter.
3. Alternatively, navigate to Vendor Invoice Management -> Document
Processing Configuration -> Document Type Configuration -> Maintain
Document Types.
Figure 7-3: Maintain Document Types menu path
4. Execute the Maintain Document Types task, by double-clicking on the

Execute icon.
Figure 7-4: Non PO global template for Document Type
5. Highlight one of the existing Document Types (this example will use the
Non PO Processing VIM16.3 (NPO_S4) Document Type) and press the
Copy as icon (two paper documents side by side).
Figure 7-5: Document Type Configuration interface

6. Rename the new Document Type with a Z or Y prefix. Populate the

relevant fields for Basic Configuration:
 Description - A description of the new document type
 Number Range - Maintain the number range which affects the
Document Processing Document Type ID
 Classifier - Choose the classifier from the drop-down list. This
represents special invoice types such as down payments
 Document Index Type - This tells the system the origin of the data
 Invoice Type - This distinguishes between a PO and Non PO
invoice
 Default Archive Doc. Type - If there is a 1:1 relation between the DP
document type and an ArchiveLink document type, select the
ArchiveLink document type defined in the SAP ArchiveLink
process. If you do not have a fixed relationship, you can leave the
field empty and create a mapping relationship later or you can use a
dummy archive document type which is used for all non assigned
DP document types
 SAP FI DocType - Enter a fixed document type or function module
Figure 7-6: Custom Document Type Configuration
7. Save your changes by pressing the Green check mark icon or by

pressing Enter.
Figure 7-7:
Confirmation of copy
8. Click the copy all button.
Figure 7-8: Informational warning pop up

9. Click on the Green check mark.
Figure 7-9: New custom Document Type
Additional fields in The above steps create the framework for a custom Document Type.
Document Type definition However, to affect the Document Type further, additional configuration is
needed. This is explained next.
Figure 7-10: Indexing Screen Configuration
Figure 7-11: Process Configuration section for a Document Type
Populate the applicable fields for Process Configuration:

 Document Posting configuration group
– Default Process Type - Select the Process Type to be used if
no other process type is determined. An example where this is
used is when a document has no errors and should directly be
created in SAP.
 Rescan Data group
– Rescan Role - If the document data is not legible or if it must be
re-scanned, it will be routed as a work item to this role.
 Dialog Posting Step Options group
– Posting Role- Select the role that is responsible for posting the
document (via dialog), if background posting fails.
– Display Index Data- Select this check box to display the index
document in a separate session while document posting so the
user is able to reference the index data.
– Skip Dashboard- Select this check box to skip the dashboard
step.
 Display Image- Select this check box to display the archived image
linked to the document in a separate session when the user
processes the work item.
 Duplicate Check Data group
– Duplicate Check Grp- Select the duplicate check group defined.
– Duplicate Check Role- Select the role that gets the work item if
the system identifies the document as a potential duplicate.

Figure 7-12: Tax and Line Item configuration for Document Types
 Tax Configuration - This is a complex determination and the

nuances of this configuration are covered in detail in the VIM 16.3
Configuration Guide. Please see the subsequent note for an
explanation of the functionality associated with this configuration.
When data flows to VIM from external systems like an OCR

system, the tax code may not be supplied. However, for auto tax
calculation, the tax code is important. Therefore, VIM provides a
tax code determination rule that tries to determine the tax code
corresponding to the supplied tax rate.
 Line Item Configuration

– Line item data- Select the check box if line item data is used
that needs to be managed for the document (for example PO
lines).
 Ignore Items from Ext System - Select the check box to indicate that
no line items should be taken into account. This means line items
are not mapped and not transferred to VIM. This could be used for
NPO invoices where line items are not relevant.
 PO Line Automation - See the Vendor Invoice Management for SAP
Solutions 16.3 Configuration Guide for configuration steps. This
field is described in the subsequent note.
VIM provides a feature to maintain PO line determination. PO line

numbers are important for PO invoices but when data is captured
from external systems like OCR systems, the PO line number
often is not supplied. The Maintain PO Line Determination
Procedures help the system to determine the PO line numbers.
Process Types A Process Type defines what is going to happen to the invoice based on
some criteria. It could spell out specific invoice handling, such as the
Process Type which parks the Non PO invoice in the background. Or it
could dictate exception handling. For example, if a PO is not released or is
incomplete, what does the system do with the invoice next? Essentially,
Process Types define the process flow.
Process Types will specify the Roles that are involved in the defined
process including the initial actor of the process (i.e. who executes this
portion?). Process Types also define the user’s options at this stage of the
process (i.e. Create a New PO). And lastly, Process Types define the
background set up for the Batch Data Communication interface (BDC) that
will be used in creating the resultant SAP document.
Process types correspond one to one with swimlane diagrams. Each

document type requires at least one Process Type. But process types may
be used in more than one document type.
Step by step: Setting up In order to configure a Process Type:

custom Process Types
1. Type the transaction code: /OPT/SPRO into the SAP command field.
2. Press Enter.
3. Navigate to Document Processing Configuration -> Process
Configuration -> Maintain Process Types (typing the transaction code /
n/OPT/VIM_8CX1 into the SAP command field will get the user to this
same spot).

Figure 7-13: Menu Path for Process Type configuration
4. Execute this transaction.
Figure 7-14: Maintain Process Types transaction
5. On the left, highlight the Process Type Definition folder.

6. On the right, highlight the Process Type that is the closest match for the
process you are trying to create.
7. Press the Copy icon.

Figure 7-15: Process Type definition

 Process Type (number): Three digit unique number - use an 800 or
900 series number for custom Process Types, this will distinguish
them during an upgrade for regression testing purposes
 Process Type: A description of the Process Type
 Initial Actor: The initial role that will receive the work item
 Initial Actor Function Module: The custom function module which
determines the initial role, if initial actor is left blank
 Is Exception: This field marks the process type as an exception
(which assumes this is not relevant for background document
posting)
 Charact. Check - This field is relevant for characteristic specific
configuration, for the following kinds of process types:
– Process types that are specific to a single characteristic or
multiple characteristics
– Process types that need to be checked for specific invoice
categories in specific characteristics only
– Custom process types that need to be executed only for certain
invoice categories of a characteristic
The Characteristic check box tells the VIM system to check the
characteristics configuration before the check defined in the
process type is executed on the invoice. Baseline configuration
provides the check box as selected for the baseline process types
that need additional checks to be performed for the characteristic
configuration.
 Create SR - This indicates that the process type will create a

Service Request in Background (only for CRM SSF).
Additional fields are available for Process Type definition. Please

refer to the OpenText Vendor Invoice Management for SAP
Solutions Configuration Guide v16.3.1 in the OpenText
Knowledge Center for a complete list of field descriptions.
9. Press the Copy icon in the application tool bar.
Figure 7-16: Copy Process Type confirmation

10. Choose the copy all button.
Figure 7-17: Confirm dependent entry copy
11. Press the Green check mark and then Save your entries.
Step by step: Assigning a In order to use a Process Type in the configuration for Document Type
custom Process Type to processing, it must be assigned to the Document Type. Follow these steps
a Document Type to assign your new Process Type to your Document Type.
1. Type the /OPT/VIM_1CX1 transaction code into the command field.

Alternatively, navigate to Vendor Invoice Management -> Document
Processing Configuration -> Document Type Configuration -> Maintain
Document Types.

Figure 7-19: Document Type definition screen
3. In the Document Type Definition Overview screen, select the relevant

Document Type.
4. Click on the Magnifying glass icon to display the details.
5. Assign the newly created Process Type as the default Process Type for
this Document Type.
Figure 7-20: Assigning a new Default Process Type to a Document Type
6. Enter the newly created Process Type into the field Default Process
Type.
7. Save your entries by pressing the Save icon.
Configuring Auto-Post In VIM 7.5 and later, there is the capability to dynamically determine
determination whether or not a Document Type is auto-posted.
Figure 7-21: Auto Post determination for VIM Document Types
Configuring Auto-post The criteria for determining whether or not a Document should be auto-
determination posted allows for the use of fields, of data, and of user input.
Figure 7-22:
IMG tasks for Field and

Data Auto-Post criteria

The task ‘Auto Posting Determination - Fields’ has pre-configured values

from Baseline and the option to include customer specific fields. This
configuration indicates which fields will be used to determine documents for
auto-posting.
The task ‘Auto Posting Determination - Data’ does not have pre-configured
values from Baseline, but does have the option to include customer specific
data. This configuration indicates which data will be used to determine
documents for auto-posting.
User Input - There is also the capability to allow the user, during indexing, to
determine whether or not a document should be Auto posted.
Figure 7-23:
User determination for

Auto Posting
Processing Logic Logic Modules are used to streamline document processing by providing a
Modules mechanism for adding or subtracting from the data that is available,
according to logical processing (code based class methods).
Business Rules Vs. Logic In the past, this was accomplished by Business Rules. Yet now, there is a
Modules clear separation. Business Rules are for checking data. And Logic Modules
are for changing data.
The Logic Module data enrichment is scheduled before the

business rules run or at the start of a process, but can be triggered
to run at additional times.
G_HEAD_006: Example A straightforward example of a Logic Module is one delivered with baseline
Logic Module which determines Vendor Name from the value in the field Vendor Number.
In the figure that follows, several other examples of Logic Module
functionality are shown.
Figure 7-24: Logic Module example use cases
Step by step: The main tasks for configuring Logic Modules are found under the VIM
Customizing Logic specific IMG, transaction code /n/OPT/SPRO. Navigate to Document
Modules Processing Configuration -> Document Type Configuration -> Logic Module
Processing.
Figure 7-25:
Defining Logic Modules

in the IMG

 Step 1: Module Definition - This is the first IMG task, called Logic
Module Processing in the VIM IMG. Execute this task to display existing
Modules or to create new ones. There are many pre-delivered Modules.
A single Module is further defined by a Class Method.
Figure 7-26: Pre-delivered Logic Modules
 Step 2: Processing Definition (clustering module IDs) - This is the

second IMG task. Here, the Modules defined in the previous step are
grouped (or clustered) together to form a sequence of data operations.
This step also defines when each Logic Module gets executed.
Figure 7-27: The clustering of Module IDs into Process IDs
The concept of clustering these Modules IDs into Process IDs is

depicted in the next figure.
Figure 7-28:
Grouping Module IDs

into Process IDs

 Step 3: Processing Mapping - This steps maps the Process IDs to the
Document Types, according to certain criteria.
Figure 7-29: Performing Processing Mapping
Business Rules As previously mentioned, Business Rules are the set of rules that describe
the operations, definitions and constraints that apply to an organization. And
more specifically to the processing of an organization’s invoices. In VIM,
Business rules are applied to detect any exceptions before attempting to
post the invoice data to the SAP database. The Business Rules are actually
executed at the following points:
 The beginning of the DP workflow
 User action via the DP Dashboard
 Configuration dependent points
 Within the Exception Workflows
Business rules can be used to examine, change, or fix the metadata of an

invoice, to determine key values in an invoice and to affect the process flow.
Step by step: Defining Essentially, once you have a Document Type and a Process Type, you are
Business Rules prepared to configure the Business Rules as well. It is done in the
Document Type Configuration. In this step, you define how the system
determines a Process Type for a given Document Type.
Business Rules are often referred to as Process Type Determination

Rules. Use these terms interchangeably and take note when one or the
other is used.
1. Type the /OPT/VIM_1CX1 transaction code into the SAP command

field. Alternatively, navigate to Vendor Invoice Management ->
Document Processing Configuration -> Document Type Configuration -
> Maintain Document Types.
2. Execute this task.

Figure 7-31: Document Type definition screen
3. In the Document Type Definition Overview screen, select a Document

Type and double-click Proc. Type. Det. Sequence.
Figure 7-32: Configuring Business Rules
4. In the Proc. Type. Det. Sequence Overview screen, select a step and
double-click Sequence Steps.
Figure 7-33: Sequence Step definition screen
5. In this step you define, for a given Sequence Step Id, the fields that
need to be considered for validating data. This means you specify the
fields that will be checked in the business rule. You can also enter a
function module. Then you do not specify a field, but rather a step,
which will be executed for this business rule.To define sequence steps:
Populate the following fields:
 Step Seq. - Enter a numeric value that identifies this step.
 Field Name - Enter the field that should be considered for
evaluation.
 Check Type - Instruct the system as to which method the field
should be checked by. For instance, If Table Field is selected, the
system validates that the value of the document field at runtime
exists in the check table mentioned in the Table field.
 Table field - This is the check table for Check Type Table Field.
 Check Function - This is the function module that is called for
Check Type Function Module.
The business rule check function library offers additional check

function modules that are not directly delivered as pre-customized
business rules. You can use the function modules as new
business rules depending on your needs. The new library is
located in function group /OPT/VIM_PROC_TYPE_LIBRARY,
which has been created to collect such function modules.

6. Save your entries with the Save icon in the application toolbar.
Business Rules OpenText Best Practices includes the Business Rules Framework (BRF).
Framework This allows for dynamic decisions as to whether or not a Business Rule is
run for a specific scenario. With the BRF, a Business Rule can be
configured to run:
 Always
 Never
 Periodically
 Condition-based
 Blind
 Check-function based
 Counter-based
 Randomly
Figure 7-34: Different Vendor categories
 Vendor invoice categories allow the customer to dictate the level of

checking that should be done for each incoming invoice. It is a
representative confidence level in the incoming data. The White list
would be for the highest confidence or most reliable vendors, whilst the
black list would be for those which are typically most problematic.
Step by step: Configuring 1. Open the VIM specific IMG.

the Business Rules
2. Navigate to Vendor Invoice Management -> Document Processing
Framework
Configuration -> Process Configuration ->Business Rules Framework
(BRF).
Figure 7-35: Business Rules Framework in the IMG
3. The steps for configuring the Business Rule Framework are:

 Define the Vendor Groups - There are pre-configured Vendor
Groups, and they can also be created as custom.
 Create the Vendor Group Assignments – These are customer
specific and none are delivered.
 Define the Check Types - These are pre-configured, only the
names can be changed.
 Maintain the Check IDs - One entry is pre-configured, AM_1000,
which checks if the amount is over 1000.

 Complete the Schemata Assignment – This requires customer

specific configuration and answers the following questions:
– Which documents (Company Code / Vendor Group / DP
Document Type)?
– Which rules (Exception Class / Process Type)?
– Which limits (Check ID)?
– Which check (Check Type)?
Process Options Process Options are the available choices a user has in a dashboard. So,
for example, while coding an invoice, an AP Processor might have the
option to post a PO invoice, park a PO invoice, run the Business Rules on
that invoice, or refer the invoice for additional information to another user.
These are the Process Options for the Process Type defined as Process
PO Invoice. Typically, there are others as well. Below is a sampling of some
of the options that may be configured for processing invoices.
Figure 7-36:
Process Options
Configured for invoice
processing
Step by step: Configuring In order to configure the Process Options for your Process Types, follow
Process Options these steps:
2. Press Enter.
3. Then navigate to Document Processing Configuration -> Process
Configuration -> Maintain Process Options.
Figure 7-37: Maintain Process Options task
4. Execute the transaction.

Figure 7-38:
Process Options
configuration interface
5. Click on the New Entries button.
Figure 7-39: New Process Option interface

 Option Id - For objects in the customer name space, use ids starting
with “9xxx”
 Option Type -
– BDC Action
– Referral
– Class Method
– Call Transaction
– Workflow Task
If an Option Type of Referral is chosen for this process option, and

the customer requires a note to be sent along with the referral,
then the REFER_COM_REQ (Product Code 005) field in the /
PTGWFI/Z_CONST table, should be set to "X" for the process
options in the range from 2700 to 2730. If no comment is
necessary, this field should be left blank. This is the default setting.
The effect of this value being populated is that the referring user
must enter a comment for processing to continue.
 BDC Configuration ID - If the Option Type is BDC Action, this field

must be populated with a BDC ID. These are covered further in the
next section.
 Confirm Check Rules - If this is active then the end user will see an
additional popup that asks if the business rules should be checked.
 Auto Action Required - Select this check box to let the system try to
post the document (create SAP document) in the background. The
transaction that is called for posting depends on the process type
configuration.
 Recheck Proc Type - Select this check box to let the system try to
run the business rules as defined.
 Confirm Execute - If this is active then the end user will see an
additional popup that asks the user for a confirmation to execute
the option.
 Confirm Completion - If this is active then the end user sees an
additional popup that requests confirmation that the option was
successfully executed.
 Display Index Data - Select this check box to instruct the system to
display indexing data of the DP document in a separate window
while executing this process option.

 Document Status - Select the status set for the document if the
option is executed successfully.
After Display Index Data is selected for a certain Process Option,

the feature is applied to all Document Types.
7. Save your entries with the Save icon.
Maintaining BDC The BDC ID is an SAP Business Data Communication ID. The BDC ID is
Procedures for used by the system to process an SAP transaction to create an SAP
Document Processing Document. BDC allows the user to populate data into SAP transactions
without programming, yet maintaining the integrity of the data by conducting
all application logic checks. Some advantages of using BDC IDs are:
 BDC IDs are optimized for both dialog processing and background
processing.
 BDC IDs can be used to set dynamic Parameter IDs.
 BDC IDs can be used to configure new user collaboration actions.
 BDC IDs eliminate the need to code parameterized transactions.
 BDC IDs can be used to configure BDC success messages.
BDC ID configuration may still be used in VIM; However, VIM is moving

away from BDC technology, in favor of BAPI technology in order to
conform to SAP’s strategic direction.
Step by step: Defining In order to Define a BDC ID:

BDC IDs
1. Type transaction code /OPT/CP_9CX1 into the command field.
Alternatively, navigate to Vendor Invoice Management -> Document
Processing Configuration -> Process Configuration -> Maintain BDC
Procedures.
Figure 7-40:
Configuration task for

BDC procedures

Figure 7-41: BDC Definition Overview Screen
3. Click on the New Entries push button.
Figure 7-42: BDC definition detail screen
4. There are two options at this point, the first is to populate the Custom
BDC Function field, located at the bottom of the screen. This overrides
all other values of the configuration if populated. The template to use for
defining this function module is: template: /OPT/
VIM_IF_BDC_DOCLINES_PO.
5. If you are not using a custom function module, then all of the fields in
the previous figure should be populated. In this option, you will define
the SAP transaction code, the mode for calling the transaction
(synchronously or asynchronously), and ultimately map the index fields
from the invoice to the SAP screen fields that are required by the
chosen transaction code.

Exercise: Creating a Document Type and a Process Type
Create a new Document Type (copy NPO_S4). Then create a new

Process Type (Copy 200) and assign your ArchiveLink Document Type
from the previous exercise as the Default ArchiveLink Document Type.
1. Execute Transaction Code: /OPT/SPRO.

2. Then navigate to Document Processing Configuration -> Document
Type Configuration -> Maintain Document Types.
3. Select Document Type NPO_S4.
5. Use the following data:
 DP Document Type = ZNPO##INV (Where ## = your User #)
 Description = User ## NPO Invoice Document Type
 Document Index Type = Online Indexing
 Default Archive Document Type = Z##INV (your ArchiveLink
Document Type from previous exercise)
6. Press Enter.
7. Choose Copy all Entries.
8. At the Information Pop-up indicating number of entries copies, click the
Green check mark.
Create your own Process Type and assign the Process Type as the
default for your new Document Type.
10. Navigate to Document Type Customization Items.

Configuration -> Maintain Process Types.
14. Scroll down until you see Process Type 200.
15. Highlight it.
16. Press the Copy icon.
17. Give your Process Type the Proc. Type ID of 9##.
18. Change the field Initial Role to be equal to your custom indexing Role:
Z##INDEXER.
21. Select your new Document Type ZNONPO##INV.
22. Click on the Magnifying Glass to display the details.
23. In Change mode, Change the field Default Process Type to be your new
Process Type 9##.
Test your configuration, using OAWD.
25. Open up the EnterpriseScan client.

26. Click the Scan button.
27. Type /n/OAWD into the SAP command line.
28. Press Enter.
29. Find your respective pre-setting which has your ArchiveLink Document
Type.
30. Double-click this presetting.
31. Choose the Green checkmark to store a single document.
32. Wait for the message at the bottom of the SAP screen. Work item ##
created.
33. Launch VIM Analytics.
34. Ensure your Work Item was created with your Process Type.
User Process Options After testing the custom Document Type and Process Type from the
previous exercise, it becomes apparent that there is functionality missing for
the user (Role) that executes this workflow task. This is because we have
not yet defined User Process Options.
Once Process Options are defined, then it is possible to assign them to

users (or roles) in the Document Type configuration. This then relates the
actions that are possible in a given scenario to the user that is expected to
execute them. It will alter the visible buttons and options on that user’s
dashboard when they open a work item.

Below is an example of User Process Options that have been configured for
an AP Processor within the Process Type Process NPO Invoice.
Figure 7-43: Process Options for an AP Processor in the Process NPO Invoice scenario
Step by step: Defining In this example, the configuration will be shown for a swimlane which
User Process Options corresponds to our own example scenario. In this swim lane there are:
 Roles - Examples are: INFO_PROVIDER, Z##INDEXER, and
Z##APPROC
 Process Options - Examples are: Refer to Z##APPROC, Refer to
Z##INDEXER, Refer for Information, Change Document Type, Enter
Index, etc.
 User Process Options - Examples are: The INFO_PROVIDER has the
ability to Refer to Z##APPROC. The swim lane follows.
Figure 7-44:
Swim Lane design for

custom Process Type
To configure one of the User Process Options for the example Process
Type (9##), follow these steps:

2. Navigate to Document Processing -> Process Configuration -> Maintain

Process Types.
Figure 7-45:
Maintain Process Types

task
Figure 7-46: Highlight the desired Process Type
4. Highlight the Process Type which the Process Options should be

available in.
5. Double-click User Process Option.
Figure 7-47: Edit the desired User Process Options
6. Highlight the relevant Process Options.

At this stage, it is also possible to choose the New Entries button

and proceed to create a Process Option from scratch. To do this,
populate the following fields:
 Option Id - This is a numeric process option identifier
 Description - This is a description of the user’s option
 From Actor - Select the source role that initiates the work item
 To Actor - Select the target role that receives the work item if
the action is performed. This is only available if the option is a
referral
 Check FM - Enter a check function module to restrict the
option for a role. You find the interface for the check function
module using /OPT/VIM_BL_CHECK_FM_2012.
For this example, the User Process Options will be copied instead.

Figure 7-48: Customize the User Process Options
In the previous figure, note the field named Sequence. This field
was introduced with VIM 7.0 SP3. It allows the customer to
configure the display order of the process options shown in the
dashboard.
8. To assign this Process Option to the new user, populate the From Actor
field with the appropriate Role.
Summary of DP So, to reiterate, each Document Type encompasses many process flows
objects (which can visually represented as swim lanes). Swimlane diagrams will
each correspond to one Process Type which needs to be configured. And
each Process Type will necessitate Process Options to be configured.
These Process Options will be subsequently assigned to each of the Roles
(user Process Options) involved in the process.
Figure 7-49:
Relationship of
configuration objects in
Document Processing
 Document Types will have multiple Process Flows.

 Each Process Flow should be represented by a Process Type.
 A Process Type can have multiple Process Options.
 Process Options are then assigned to Roles, resulting in User Process
Options.
The Index screen The next component to configure in Document Processing is the Index
Screen itself. The Index Screen can be extended, depending upon each
customer’s unique requirements. Here, we will discuss how to configure the
index screen for each Document Type in the DP Process. The newly
released Index Screen has more functionality which means more
configuration.
Step by step: Configuring To configure index screen options for Document Types:
the Index screen
field. Alternatively, navigate to Vendor Invoice Management ->
Document Processing Configuration -> Document Type Configuration -
> Maintain Document Types.
Figure 7-50: Maintain Document Types Task

Figure 7-51: Document Type Definition screen
3. In the Document Type Definition Overview screen, select a document

type and double-click Index Screen Options.
Figure 7-52: Index Screen Options configuration
4. In the Index Screen Options screen, assign the appropriate

configuration for each combination of Process Type and Role.
5. For a given Process Type and Role, the following fields are explained:
 Allow Changes - Select this check box for a given role to allow all
users in the role to change the index data. Prerequisite - The
document should not have been submitted, yet.
Figure 7-53: Result of Indexer Role with “Allow Changes” for the Indexing screen

 Show Duplicates - Select this check box to display the duplicates

identified by the system below the index data screen for the role
that is processing the work item. An example of this is it might be
relevant for the DUP_CHECKER role to look at the duplicates to
decide whether or not the document is actually a duplicate. For the
AP_PROCESSOR role, showing duplicates might be of lesser
importance as the document might have already completed the
duplicate check process and might be ready to be posted or parked.
 Initial Tab - The user can configure each tabstrip of the new
indexing screen for the tab that is shown initially; the tabs are:
– Basic Data- this tab shows the basic indexing information which
is also available on the invoice document - this is the default tab
in focus for the user (as shown in the previous figure)
– Line Item Data- this tab shows the relevant line items
– Accounting Data- this tab shows additional SAP specific data
for the accountant to post the document
– Tax Data- this tab shows relevant tax information
– Process Data- this tab shows relevant process information and
also provides access to the duplicate invoices
 Enable Simulate- Select this check box to allow a user to simulate
skipping certain business rules. The Simulate process will check
the relevant business rules. For example, if any DP document had
an Invalid Vendor (PO) exception, this can be simulated by
selecting the current role and selecting Enable Simulate. The result
of this is a push button in the DP Dashboard. An example is shown
in the figure that follows.
Figure 7-54: Result of Enable Simulate and Bypass configuration

 Enable Bypass- Select this check box to bypass the business rules.
For example, if a DP document had an Invalid Vendor (PO)
exception, the role executing this work item could bypass this rule if
the configuration was set to Enable Simulate and Enable Bypass.
 Dis.Obsolete- Select this check box to hide the Obsolete button in
the DP Dashboard for the selected DP document type and the
current role (see next figure).
 Dis.Rescan- Select this check box to hide the Rescan button in the
DP Dashboard for the selected DP document type and the current
role (see next figure).
Figure 7-55: Result of empty Dis. Obsolete and Dis. Rescan configuration
 Show Match- Select this check box to display the matching area
within the item data subscreen for PO invoices to the user. This is
relevant to execute the matching for PO related documents based
on the SAP proposal.
Index screen Header and Other than configuring the details of the index screen, the customer can
Item fields decide which Index Header fields and Index Item fields should be available.
This is done within the Document Type configuration as well. This is done in
the same dialog for Document Type Maintenance.
Figure 7-56: Changing the Index Header Field configuration
Each field must be indicated as Display Only, Hide, Required, or Input.

Global Configuration Global Configuration will affect the functionality of an entire process. These
parameters for parameters should only be changed with careful consideration. These
Document Processing parameters are housed in a configuration table of constant values.
Step by step: Access the In order to open the table:

Webflow Constant table
1. Type the /OPT/VIM_1CX12 transaction code.
Processing Configuration -> General Configuration -> Global
Configuration.
Figure 7-57: Global Configuration parameters
3. Execute this task to display the Webflow Constant Table.
The Webflow or Z Constants in VIM are numerous and crucial for

processing. Please refer to the VIM Reference Guide 16.3 for a
complete listing of constants, their use, and their proposed
settings.
Figure 7-58: Excerpt of the VIM Reference Guide - Section on WebFlow (Z) constants
This table controls many aspects of processing. As these options arise in

context specific situations, it will be notated what the specific parameter is
and what its value should be.

An excerpt of the table is shown below.
Figure 7-59: Web Flow Constant table used for Global Configuration settings
Characteristic specific Invoice processing differs between companies depending on legal or

rules and specific company-based settings. VIM supports flexible processing by
configuration defining individual invoice characteristics. An invoice characteristic is
determined during runtime and depends on the corresponding index data of
the document. In the baseline configuration, VIM delivers the country as a
unique invoice characteristic.
Therefore, configuration that was previously Country-specific, prior to VIM

7.0, is now handled in Characteristic-specific settings.
VIM delivers sets of rules to control business and regulatory scenarios for
each customer. They are grouped into two distinct types. They are
Completeness Check Rules and Tax Related Rules. This is achieved by
OpenText with the Core Infrastructure and the Baseline Content.
Core infrastructure We have briefly covered much of the Core Infrastructure. It includes
Document Types, Process Types, and Invoice Types. We have not yet
covered Invoice Categories. Invoice Categories are used to define the
business rules for specific invoices. Certain business rules are applicable to
only some invoices that are processed in a specified characteristic. Other
business rules need to be skipped for only some invoices of a characteristic.
The following invoice categories are supported by VIM:
 Domestic - Invoices raised by vendors in the same country.
 Intra-Community - Invoices raised by vendors in the European Union
(EU) to companies in the EU. Applicable only to EU countries.
 Triangulation - Invoices raised by vendors in the EU to companies in the
EU for a delivery of goods or services originating in another EU country.
In this case, both the vendor and the company are in different EU
countries. Applicable only to EU countries.
 Import - Invoice raised by vendors outside the company’s country.
 Domestic Material - Invoices raised by vendors in India where the
Purchase Order is a Material PO. Applicable only to India.
 Domestic Service - Invoices raised by vendors in India where the
Purchase Order is a Service PO. Applicable only to India.
 Import Material - Invoices raised by vendors outside India where the
Purchase Order is a Standard PO. Applicable only to India.
 Import Service - Invoices raised by vendors outside India where the
Purchase Order is a Service PO. Applicable only to India.
 Non VAT - Invoices without VAT amount. Applicable only to China.
 VAT Common - Invoices with VAT provided but the VAT amount is not
deductible. Applicable only to China.
 VAT Special - Invoices with VAT provided and the VAT amount is
deductible. Applicable only to China.
Baseline Content Baseline Content is the implementation of the business rules as interpreted
by OpenText. This is pre-delivered with the product and is available as an
accelerator for companies to modify as required.This content includes:
 Document types for specific processes
 User interfaces for each process implementation
 Screen field configuration specific to the document types
 Business rules implemented for each characteristic
In the baseline configuration, VIM delivers three document types as global

processing templates.
S. NO Document Type Description
1 NPO_S4 Non PO Processing
2 PO_S4 PO Global Processing
3 DWN_75 Down Payment Processing

Specific processing is configured for the PO, NPO invoice types and for
Down Payments.
These global templates cover the basic configuration, and in combination

with the country-specific invoice characteristics enable global companies to
process invoices. Besides the global configuration of the document types,
the detailed characteristic configuration provides, in the baseline delivery,
settings for all countries. Specific countries and a global country template
are delivered to support all requirements from the process point of view.
If there is a need to enhance the delivered baseline, for instance to

create new characteristics or new invoice categories, or to
customize region specific tax determination please consult the
OpenText Vendor Invoice Management for SAP Solutions 16.3
Configuration Guide.
Step by step: Defining In order to define Characteristic Specific Settings for Document Types:
Characteristic settings
1. Type the /OPT/SPRO transaction into the SAP command field to
access OpenText Configuration and navigate to Vendor Invoice
Management -> Document Processing Configuration -> Document
Type Configuration -> Characteristic Specific Document Type
Configuration.
Figure 7-60: Characteristic Specific Document Type configuration task
Figure 7-61: Characteristic specific attributes overview
3. In the Characteristic Specific Attributes Overview screen, double-click a

characteristic to display the Characteristic Specific Attributes Details
screen.

In the Details screen, are the fields which can be set according to each
characteristic. So, for a certain Document Type, for a certain characteristic
(such as country), the customer can decide how fields are populated. An
example, that is pictured in the next figure, shows that for the Characteristic
DE (Germany) for a certain Document Type (not shown), the Posting Date
should be the Date on the Vendor Invoice and the Conversion Date should
be equal to the Posting Date.
Figure 7-62: Characteristic specific configuration for Document Types
For definition of all of the fields within the Characteristic

Configuration, please see the VIM 16.3 Configuration Guide.
These fields should be examined to understand the effect each of them has
on the processing of the invoice. Use these fields to determine if an invoice
is a simple invoice, if it should be treated as a down payment, and what the
invoice’s baseline date is for due date calculations in the SAP system.
Other Characteristic Characteristics can also be used to alter the Indexing Screen and the
specific settings Process Types. After the Characteristic Specific Attributes for the Document
Type are configured, then the other options can be traversed on the Left
Pane of the Details Screen. This is shown in the next figure.
Figure 7-63:
Other Characteristic
specific configuration
In this figure we see the following options:

 Index Header Configuration - Double-click on this option to list all fields
that should be configured for the Indexing header. Here, the detail pane
displays the various attributes that can be modified for a screen field.
The configuration also allows you to configure screens per role or per
invoice type. If no role is chosen, it is applicable for all roles.
 Index Item Configuration - To configure the attributes for the item
screen, double-click Index Item Configuration in the Dialog Structure.
The same attributes are available for all fields within the Indexing Detail.
 Characteristic Specific Process Types - On the Characteristic Specific
Attributes Overview screen, select a characteristic and double-click the
Characteristic Specific Process Types link in the Dialog Structure.
These must be maintained in the characteristic configuration.
 Characteristic Specific Screen Configuration - On the Characteristic
Specific Attributes Overview screen, select a characteristic and double-
click the Characteristic Specific Screen Configuration link in the Dialog
Structure.
It is important to note that the indexing screen displayed is

generated at runtime, based on the document type and
characteristic being processed.

Exercise: Creating User Process Options and Changing the Indexing Screen
Create User Process Options for your custom Roles: The User
Process Options will be R90## and R91##.

Configuration -> Maintain Process Options.
4. Click on the New Entries push button.
 Option Id: “90##”, e. g. “9099”
 Option Button Text: “Refer”
 Option Button Icon: leave blank
 Option Text: “Refer to Z##INDEXER” e.g. “Refer to Z99INDEXER”
 Option Type: Select “Referral” from the list
 Select the check box : Override Res. Actor
 Select the check box: Comments Required
 Select the check box: Confirm Execute
 Select the check box: Confirm Completion
7. Repeat, but use the following fields:
 Option Id: “91##”, e. g. “9199”
 Option Button Text: “Refer”
 Option Button Icon: leave blank
 Option Text: “Refer to Z##APPROC” e.g. “Refer to Z99APPROC”
 Option Type: Select “Referral” from the list
 Select the check box : Override Res. Actor
 Select the check box: Comments Required
 Select the check box : Confirm Execute
 Select the check box: Confirm Completion
Now, Assign these newly created Process Options to your custom

Roles (thereby creating User Process Options).

Configuration -> Maintain Process Types.
12. Scroll down and find your 9## Process Type.

13. Highlight it.
14. Move to the left hand pane.
15. Double-click User Process Option.
17. Make the following two entries (taking note to use your own custom
roles):
Figure 7-64:
New User Process

Options for the custom
Process Type
Test your configuration, using OAWD.
19. Open up the EnterpriseScan client.

20. Click the Scan button.
21. Type /n/OAWD into the SAP command line.
22. Press Enter.
23. Find your respective pre-setting which has your ArchiveLink Document
Type.
24. Double-click this presetting.
25. Choose the Green checkmark to store a single document.
26. Wait for the message at the bottom of the SAP screen. Work item ##
created.
27. Launch the Business Center Workplace.
28. Launch VIM Analytics.
29. Ensure your Work Item was created with your Process Type.
30. See which inbox the work item is in.
31. Access that user’s SAP Inbox or VIM Workplace and launch the task.

32. Ensure your new User Process Option is available.

33. Try referring it on to the Z##APPROC Role.
Affect the Indexing Screen

37. Navigate to your custom Document Type Z##_NONPO.
38. Highlight it.
39. In the left hand panel, double-click on Index Screen Options.
40. Click New Entries.
41. Type in your custom Process Type and Custom Role (Z##INDEXER)
and make the selections shown below:
Figure 7-65: Index Screen option configuration

43. Relaunch your workitem and notice the differences in the Indexing
Screen.
Other Configuration Several miscellaneous configuration options are covered in this section.
options
Figure 7-66:
Has a duplicate invoice

arrived?
Duplicate Check Logic Duplicate checking is carried out after the OCR fields have been imported
and validated or when the indexer submits the manual index. The check
which is employed depends on the Document Type.
For a Baseline Non-PO Invoice Duplicate Check (KR), the following fields
would be placed in a Duplicate Check Group and then checked together to
decide whether or not two separate documents are duplicates.
 Invoice date
 Vendor reference number
 Vendor number
In this version of VIM, the only Duplicate Check Group is Check

Group 4 which is described above. Customers can define their
own if required.
For a Baseline PO Invoice Duplicate Check (RE), the following fields might
be placed in a Duplicate Check Group and then checked together.
 PO number
 Invoice date
 Vendor reference number
 Vendor number
Duplicate Checks can also be accomplished via a duplicate check function

module.

Step by step: Defining If a user chooses to send a document to be scanned again, there should be
rescan reasons an appropriate reason attached. This will alert the scanner and provide a
level of documentation for the action taken. In order to configure Rescan
reasons:
1. Run the /OPT/VIM_1CX7 transaction.
Processing Configuration -> Process Configuration -> Maintain Rescan
Reasons.
Figure 7-67:
Maintain rescan reasons

task
Figure 7-68:
Defining Rescan
Reasons
4. Maintain the Reason Codes, the Descriptions, and indicate if they are
required or not.

Obsolete Reasons If the Obsolete push button is visible in the Application Toolbar (how to
affect this was discussed previously) then the reasons for marking a
document as obsolete should be configured. In order to create these
reasons, proceed as follows:
field.
2. Press Enter.
Processing Configuration -> Process Configuration -> Maintain
Obsolete Reasons.
Figure 7-69:
Maintain Obsolete
Reasons task

5. Maintain the Reason Codes, the Description, and indicate if they
require the user to enter comments or not.
6. Save the entries.
One example of a reason for marking an invoice as Obsolete

would be if it was a Return to Vendor scenario. (Process Option
2026).
Exercise: Maintaining Duplicate Check Logic and Reason Codes
Maintain Duplicate Check Logic
1. Execute Transaction Code /OPT/SPRO.

2. Navigate to Document Processing Configuration -> General
Configuration -> Maintain Duplicate Check Procedures.
3. Execute this option.
4. Select a Duplicate Check Group.
5. Press the COPY icon.
6. Choose Copy ALL entries.
7. Prefix the name of the new Duplicate Check Group with: 9## (where ##
is equal to the Group #).
8. Select new duplicate check group and GROUP FIELDS.
9. Add or remove new duplicate check fields.
Configure Rescan Reason Codes

Configuration -> Maintain Rescan Reasons.
3. Create new reason code.
Configure Obsolete Reason Codes

Configuration -> Maintain Obsolete Reasons.
3. Create new reason code.
Summary
In this chapter, the main concepts used in Document Processing were
introduced. Because Document Processing is the area of the system where
it is determined how an invoice will flow through the system, many
configuration tasks were introduced. This included Document Types, Logic
Modules, Business Rules, the Business Rules Framework, Process Types,
Process Options, and User Process Options.

Cha pter 8. Invoice Pr ocessing configu rat ion
8. Invoice Processing configuration
Objectives

 Recognize the significance of Reason Codes in Invoice Processing
 Customize the PO Parking, PO Blocking, and Non PO Parking Processes
 Find where custom development exits can be used
Baseline invoice handling

VIM is delivered with a significant amount of configuration to meet the
customer’s requirements with only minimal effort. VIM comes with Baseline
Exception Handling for blocking and parking workflows.
Reason Codes Reason codes are used in VIM to determine process flow and control. They
will effectuate where the work item (or invoice) goes and what can be done
to it for resolution.
Reason Codes delivered A sample of the PO reason codes delivered by OpenText are:
 Price Discrepancy
 Quantity Discrepancy
 Date Block
 Order Price Quantity
 Project Budget Block
 Manual Block
 Quality Block
 PO Parked Document
 Non PO Parked Document
Invoice processing customization

Rollout Criteria for This configuration allows the customer to define the VIM PO parking, PO
Triggering PO blocking and Non PO parking document processes to be triggered
Blocking Workflow dynamically.
As an example, a customer might want to apply VIM for some specific

combinations of company code, plant, and document type (plant is only
used as a criteria for PO invoice). For other combinations of the same data
criteria, the customer might want to use standard SAP processes.

In this case, the rollout must be maintained with the correct company codes,
plants, and document types as criteria.
If Rollout criteria is not maintained here, the workflows will trigger for all
documents.
Step by step: Defining To define the rollout criteria:

Rollout criteria
1. Type the /OPT/SPRO transaction code into the SAP command field.
2. Press Enter.
3. Navigate to Vendor Invoice Management -> PO Based Invoice
Configuration -> Blocked Process Configuration -> Rollout Criteria
(Workflow Start Conditions) -> Allowed Company Codes, Plants,
Document Types for Parked/Blocked Invoices.
Figure 8-1: Maintain Rollout criteria task
Figure 8-2:
Choosing Rollout criteria
5. Choose which Company Codes should use VIM for parking/blocking

processes according to your selected combination of company codes,
plants, and document types.
6. Indicate whether or not this is active for PO based invoices and/or Non
PO based invoices.
Event Linkages - PO The next task in the IMG for blocking configuration is the definition of Event
based Linkages.
Figure 8-3:
Event Linkages IMG task

Event Linkages are used to affect the workflow or code which is called when
an invoice is parked or blocked.
 Object Category: BO
 Object Type: /OPT/B2081
 Event: ZWFI_PARKED
 Receiver Type: WS00275260
 Receiver Call: Function Module
 Receiver FM: /OPT/BL_PO_PRK_RECEIVER
 Check FM: /PTGWFI/PRK_M_CHECKFM
 Linkage Activated: X
The Event Linkage settings should not be changed unless the customer
wants to implement a custom Receiver Function Module or Check
Function Module.
PO Parking specific Primarily, invoices can be parked for some further processing. This
configuration includes, for example, waiting for approval, or changing some values like
vendor data, or tax data. The invoice will then be posted in a later step.
The main processing concept involved in managing parked PO invoices is

the concept of Parking Reasons. Parking reasons define the overall
processing of the invoice as required by the process.
Non PO Parking Vendor Invoice Management also provides functionality for managing
specific configuration parked Non PO FI invoices (MIR4 transaction) and the exceptions therein.
The main processing concept involved in managing parked Non PO

invoices is the concept of “parking reasons”. Parking reasons define the
overall processing of the invoice as required by the process.
In previous versions of VIM, PO and Non PO Parking processes

used a separate workflow. Now, they are handled via the DP
Workflow.
Configuring parked Parked processing within the DP Workflow is newly introduced. For this
processing scenario:
 The new posting logic for VIM 16.3 is (BDC 2200).
 Only invoices processed by MIRO or MIR4 are supported. FI postings in
FB60 or other FI transactions or by VIM 7.5 posting logic are not
supported.
 For upgrade customers only: The Z constant 005 /
VIM_VERSION_SWITCH is not set to 700. You can configure this logic
for specific vendors.
 The Z constant 005 / SYNC_ITEM_PARKED_PO should be set to X.
Trigger points Parked documents can be triggered automatically after the start of the DP
Process, by a Process Option, or by parking a document in MIRO, MIR7 or
the Fiori Managed Supplier App.
Parked and held The DP workflow can process parked and held documents.. The following
documents with a process options are available in the baseline to create or change MM
Process Option documents in dialog:
 2100 Post Invoice (MIR4)

– In the baseline, this process option is available after all business
rules are resolved and the workflow is in the default step. When
processing, a held document is created and displayed to the user in
MIR4. If the user is not posting the document, the held or parked
document will be kept.
 2102 Go to SAP Document (MIR4)
– This process option is available as soon as a held or parked
document is created for the current DP process. With this option,
the SAP document can be changed or posted in MIR4.
If a SAP document is available, the VIM indexing screen is set to process

mode.
The MM document is the leading document, therefore changes to SAP

relevant data is only possible by opening the invoice using the process
option in MIR4.
SAP related input fields in the VIM indexing screen are set to read only and
will be updated automatically when changing the SAP document in MIR4.
PO Blocking specific VIM also provides functionality for managing blocked PO invoices (based
configuration on the MIRO transaction) and exceptions therein. Invoices are blocked if
they show discrepancies. An example of this is a price discrepancy, which
would prevent the invoice from being paid.
The main processing concept involved in managing blocked PO invoices is

the concept of “Blocking Reasons”. Blocking reasons define the overall
processing of the invoice as required by the process.

The most important reasons are price block and quantity block reasons.
Some of the typical blocking reasons are shown in the next figure.
Figure 8-4:
Example Blocking
Reason for PO invoices
Step by step: Defining PO 1. Type the /OPT/SPRO transaction code into the SAP command field.
Blocking Reasons
2. Press Enter.
Configuration -> Blocked Process Configuration -> Blocked Reason
Maintenance.
4. Expand this menu. The following three tasks should be executed:
 Block Reason Defintion
 Process Option Definition
 Maintain BDC Procedures
Technical configuration
Global parameters control various aspects of the processing logic for PO
invoice parking and blocking and Non PO parking process flows. Various
global customization parameters are available.
Changes to global configuration parameters can affect the functionality of

the entire process and might have unintended consequences.
Some of the functionality that is configured via global parameters is

described below:
This list is just a sampling of the options that are available for
customizing PO parking, PO blocking, or Non PO parking
This processes. Specific options exist for each of the processes and
are found in configuration, under the base menu, under the
Technical Configuration Option. Please consult the OpenText
Vendor Invoice Management for SAP Solutions v16.3.1
Configuration Guide for detailed instructions on customizing each
option.
 Configuring Transactions to Create Parked PO Invoices - Here,

transactions that create Parked Invoices are configured.
 Configuring Screen Exits - This allows for the configuration of additional
subscreens that can be made to appear in a dashboard to collect
additional data or provide additional information to the user.
 Configuring the Option Order - In this step, the order in which the
options appear in the user’s dashboard in the parked invoice process is
configured.
 Configuring Binding Function Exits - This allows for custom function
modules that can transfer data that is related to the parked invoice to
the OpenText delivered workflow processes, thereby allowing for the
manipulation of workflow container data.
 Configuring the Pre-dashboard Method Exit - This allows for a custom
function module that will manage custom data before calling the
dashboard.
 Configuring the Post-dashboard Method Exit - This allows for a custom
function module that will manage custom data after calling the
dashboard.
 Configuring Automatic Image Display - This allows the customer to
configure whether or not images are automatically displayed when the
PO Parked Invoice Dashboard is opened.

Exercise: Change the blocked invoice display
Dynamic Column Configuration
1. First, execute Transaction Code: /OPT/SPRO.

Configuration -> Blocked Process Configuration -> SAP Inbox
Configuration -> Dynamic Column Configuration.
3. Press the New Entries button.
4. Populate the relevant entries.
5. Click the Save icon.
Summary
This chapter covered specific configuration tasks for PO Parked Invoice
processing, PO Blocked Invoice processing, and Non PO Parked Invoice
processing. Reason codes were shown to be the main driver behind the
options each user has in a particular process and how the invoice will flow
from that exception and consequent user action.
C hapter 9. Invo ice app roval configu rat ion
9. Invoice approval configuration
Objectives

 Explain when and how the IAP process gets triggered in the VIM flow
 Differentiate between the functionality of simple approval and level based approval
 Configure level based approval for Non PO invoices
Invoice approvals
Invoice Approval (IAP) is the component of VIM that handles the approval
processes for both Non-PO based and PO based invoices. Approvals can
be handled before or after posting:
 DP Approval - approvals are completed prior to posting
 Posted Approval - approvals are completed after documents are posted
Features of the IAP The following are the main features of IAP.
 The approval workflow is a new sub workflow; approval steps are a
technically different dialog task, separate from the DP dashboard tasks
or the other VIM workflows.
 The approval workflow supports a multi level approval. For Non PO
invoices, this is achieved via configuration.
For PO invoices, a custom extension is required. From baseline, PO

invoices go through only one approval step (by the requester of the PO).
 The approval workflow supports approvals inside the SAP GUI, and
outside of the SAP GUI, if the optional OpenText Approval Portal or
Mobile Approval Portal is implemented. It can also be implemented as a
Fiori app.
 Parked invoice documents with the parking reason “Approval Required”
are now handled by the DP workflow.
 For DP invoice documents, the approval sub workflow can be triggered
by configuring the Process Type to be Auto submit for approval or
clicking the Submit for approval option.
 The approval sub workflow is completed when either the Approved
completely or the Rejected completely flag is set on the monitor table.

Cha pter 9. Invoice appr oval co nfigur atio n
 For posted invoice documents, the approval sub workflow can be

automatically triggered right after the invoice is posted. Therefore the
document type must be configured accordingly. Another way to trigger
the approval sub workflow is to click specific process options created for
that purpose.
Figure 9-1: The IAP component of VIM
What starts the approval process?

The approval process is triggered at different points according to which type
of invoice is being processed and whether or not it is before (DP Approval)
or after posting (Posted Approval).
DP approval DP Approval is triggered when an “Approval Required” process type (or

exception) is encountered.
Posted approval Posted Approval is triggered in one of the following three situations:
 A document is manually posted with a configured payment block.
 A document is automatically posted from DP processing with a special
payment block.
 A document is automatically posted with a specific payment block after
the requester step in the approval workflow.
Posted approval is not delivered with Baseline configuration. It should be

configured according to the OpenText Vendor Invoice Management for
SAP Solutions 16.3.1 Configuration Guide, section 12.3.1.
DP approval For parked invoice documents: When an invoice is parked with a parking
reason that requires invoice approval, the IAP workflow gets initiated. It is
possible to delay the start of the IAP process by first sending the invoice to
the AP processor (for a manual check of the invoice) who can subsequently
submit the invoice for approval.
For DP invoice documents: The approval sub workflow can be triggered by

configuring the Process Type to be Auto submit for approval or clicking the
Submit for approval option.

Configuring the IAP process

The following design considerations should be made in preparation for
configuring the Invoice Approval process:
1. Identify the approval Process Types.
2. Determine the user framework to be used. This deals with configuring
or extending the /ORS/USERMAPPING class.
3. Identify the approval steps and roles:
 Identify who is responsible for account assignment (Coder and
Requester roles).
 Identify approval logic:
– Who is the first approver?
– How does the system proceed up the approval chain (if
needed)?
– What marks the end of approval?
– What needs to happen in case of rejections?
 Identify the account assignment screen layout and logic:
– Identify fields to be displayed.
– Identify validation requirements.
 Identify how to display the image during the approval process.
 Identify and configure any global customizing parameters.
Approval specific This is the starting point in the Approval Process for DP Approval. We have
Process Types seen previously that Process Types are handled by the system for each
Document Type. In order to initiate the Approval Process for DP invoices,
one of the Process Types should have the workflow type of OpenText
Approval Workflow.
By default, the following Process Types are configured with auto start:
 Process Type 150 - PO based invoices
 Process Type 250 - Non PO based invoices
This is accomplished in the Document Processing Configuration under

Process Configuration -> Maintain Process Types. This was described
earlier, and is shown in the next figure for reference.
Figure 9-2: Process Type for Non PO Approval Required
Multi level approval The main objective of the level based approval is, that each invoice in a
company is processed in an approval hierarchy, which is associated with
different approval levels. When an invoice or invoice lines are approved on
one level by one or more users, the system checks if an additional approval
level is necessary based on the limit assigned to the approval level.
With VIM 7.0, OpenText delivered a new level based approval process.
The approval processing prior to version 7.0 is still accessible as the
simple approval scenario. But, in the future, OpenText will only support the
level based approval introduced with VIM 7.0.

Approval can be customized to meet special processing

requirements. Approval hierarchy and level logic can be
customized by extending methods in the class /ORS/APPROVER.
Highlights of level based Some of the advancements in approval processing that were introduced
approval with level based approvals are:
 Approval Processing
– Approval flow is based on approval levels
– Approval can be done as header-based or line-based (sequential or
parallel)
– A pack is defined as a group of lines that are assigned to an
approver which he/she can approve; this means, the approver has
the corresponding authorizations for the cost element combination
– All lines (in line based approval) are processed within one level
sequentially or in parallel (based on the existing pack)
– Once one level is finished, the next level is processed sequentially
– Approval is complete when all packs are fully approved through all
levels
 The Approver is determined in the following manner:
– Line based - according to Cost Object assignment in the COA, for
the first unapproved line, the user is found, then all approved lines
are shown within a pack
– Header based - according to Cost Object assignment in the COA,
the approver with the highest limit assignment of approvable
invoice lines becomes the approver at a header level for the entire
invoice
 Amount Limit is checked in the following manner:
– Line based - Against the pack amount
– Header based (with highest pack option) - Against the total amount
– Header based (with all pack option) - Against the pack amount plus
the additional amount for unassigned lines.
For PO invoices, a custom extension is required for multi level

approval. According to baseline, PO invoices go through only one
approval step (by the requester of the PO).
Questions to answer To define a multi level approval process, the following considerations
before configuration should be made:
starts
 How is the first approver identified?
 Who should approve the invoice after the current approver approves
the invoice?
 When is an invoice considered finally approved?
Approval flow The flow of an invoice through approval will differ depending on the type of
invoice. The next figure gives a general idea of the progression from Coder
to Requester to Approver.
Figure 9-3:
Approval flow

DP approval The IAP DP Approval process starts when a DP PO invoice or a DP Non

PO invoice gets the process type for approval or a user from the Accounts
Payable (AP) department specifically clicks the Submit for Approval option
from the DP dashboard.
The initial approver is determined by finding the requester of the PO (for PO

based invoices) or this might be overridden in the DP Dashboard by an AP
Processor.
The next approver is determined according to the Chart of Authority (COA).

The COA evaluates according to the following criteria:
 company code (company code of invoice line(s))
 approval level
 cost object assignment (cost object of invoice line(s))
Defining the approval hierarchy and approval levels

Simple approval The Simple Approval process corresponds to the invoice approval approach
from prior versions of VIM. The flow is simple and calculates the amount (for
consideration in evaluating the approver) based on gross amount value of
the total invoice. The simple approval flow uses the information provided in
the old COA.
Figure 9-4:
Old COA configuration
For PO document types, level-based approval cannot be used. Only the

old COA and Simple Approval is supported.
Step by step: Accessing In order to access the OLD COA:

the Simple Approval COA
(old COA)
field.
2. Press Enter.
COA maintenance (OLD and NEW) requires functional users who are
aware of organizational objects involved in the Invoice Approval process.
Level based approval There are several ways to implement an approval hierarchy and approval
levels (authorized amount that an approver may approve). For Level Based
Approvals, the OpenText approval hierarchy table must be used. The NEW
COA must be configured and Approval Flow Settings (AFS) must be
maintained.
Chart of Authority (new) In the NEW COA, approvers can be different with various approval limits for
different combinations or different organizational data, which can be very
complex. The NEW COA provides an interface for maintaining all the
combinations of approvers, approval limits and coders for the Invoice
Approval process.
Level based Approval is only considered for Non PO invoices. For

PO invoices, Baseline implementation determines the requester of
the PO as the first (and only) approver.
The data combination maintained in the COA helps to determine the correct
approver for a certain invoice (header based) or a certain set of lines (line
based) in the approval process.

Preparing to configure There are several tasks that must be completed before the COA tables can
the new COA be maintained. They are as follows:
 Cost Objects for the IAP must be maintained via transaction code SM30
- table /OPT/BL_T401V.
 Fields for Approval User Data must be maintained via transaction code
SM30- table /OPT/BL_T402V.
 Levels required for Approval limits and Approval authorities must be
maintained via transaction code SM30 - table /OPT/AT_LEVEL (shown
below) or via the opentext™ IMG
Figure 9-5: Level configuration table
Level 0 is always reserved for Coder Level. Level 1 always

represents Requester Level. All subsequent levels from 2 on can
be used for Approval Levels.
Step by step: Accessing In order to access the NEW COA:

the new COA
1. Type transaction code /OPT/VIM_APPR_COA into the SAP command
field.
Figure 9-6: NEW COA configuration
2. Navigate to the User Details tab.

3. Some key fields that should be noted in this configuration are:
 Bulk Approval Category - Permission to perform bulk approval, this
indicates that the user can approve or reject more than one work
item at the same time, for example in the VIM Workplace, the
Approval Portal, mobile approval, or the Fiori Approval app.
 Windows Domain - If implementing optional Approval Portal with
WAS authentication scenario: Windows domain. Required if COA
uses Approval Portal with WAS authentication scenario and users
are authenticated using Windows domain.
 Windows_ID - If implementing optional Approval Portal with WAS
authentication scenario: Windows ID or the login ID. Required if
COA uses Approval Portal with WAS authentication scenario and
users are authenticated using Windows domain.
 Personnel number - SAP HCM Personnel number of the user.
 SAP Portal User ID - If implementing optional Approval Portal with
Portal authentication scenario, this will be the login ID for the user in
the portal.

4. Navigate to the Approval Limit/Level tab.
Figure 9-7: Approval Level/Limit tab
5. For each combination of Company Code and Approval Level, enter all
relevant fields. Some key fields that are explained here are:
 Amount Limit - Enter an amount. This amount will be considered as
the approval limit. The user can approve the invoice if the amount of
a certain pack in the invoice is less than or equals the amount
mentioned in this column. If the amount exceeds this limit, the
invoice needs next level approval.
The pack amount is the sum of different line items assigned to an

approver per cost element combination. For the coder level, the
amount must always be 0 (zero).
 Approval Category - This column is specific to header based

approval. Select H-Highest pack only or A-All pack from the list. For
header based approval, not all packs (lines) are assigned to
different users. Only one approver is determined. This approver is
found by the COA to be able to approve the highest pack (= sum of
all lines with the highest amount that can be assigned to one user).
Choose from the following:
– H-Highest pack only - The amount limit within COA is checked
against the total invoice amount. From the level with an amount
limit (level 1 to level n), fetching the next approver is based on
the highest pack. For coder level (level 0), the value must
always be H-Highest pack only.
– A-All pack - The amount limit within COA is checked against the
pack amount (assigned and approvable invoice lines). The
additional amount is checked against the sum of not assigned
invoice lines.
6. Navigate to the COA Details tab.
7. Some key fields that should be noted in this configuration are:
– Configurable Cost Elements - The cost elements, for example Cost
Center or WBS Element, can be maintained in table OPT/BL_T401.
According to the configuration of OPT/BL_T401, ranges can be
maintained for the different cost objects. It is also possible to
configure an asterisk (*) for a cost object.
Figure 9-8: COA details tab- Coder/Requester

8. Navigate to the Coder Settings tab.

9. Choose the appropriate AFS (this is covered in the next section).
10. Press Return.
11. Enter the relevant fields.
Approval Flow Approval Flow Settings are used to complete the configuration by dictating
Settings the flow of the invoice’s approval. AFS configuration consists of three main
tasks:
Step by step: Setting the 1. Start by accessing the OpenText VIM IMG, by typing transaction code
Approval Flow Settings /n/OPT/SPRO into the SAP command line.
(AFS)
2. Press Enter.
3. Navigate to Vendor Invoice Management -> Invoice Approval
Configuration -> Setup Approval Chain -> Approval Flow Settings.
Figure 9-9: Maintain Approval Flow Settings task
Figure 9-10: AFS Types
5. Maintain the appropriate AFS ID.

Line based vs. header As illustrated by the previous figured, level-based approvals can be done in
based a line based (sequential flow) or header based fashion. Levels are defined
against approval limits.
 Line based processing (sequential or parallel)

In line based processing, the approver is determined by the NEW COA,
where you can calculate the approver by approvable lines. After all
packs (lines) within one level are approved, the next approval level is
processed. Therefore, the pack amount is checked against the limit of
the approval level to determine if the pack (lines) is already finally
approved. Approval is completed when all lines are finally approved.
 Header based processing

In header based processing, the approver is determined by the NEW
COA, where you can calculate the highest pack amount of possible
invoice lines. When a user opens an approval work item, all lines are
approvable for this user. The invoice total amount is checked against
the limit of the approval level. Via configuration in the NEW COA,
invoice lines that are not assigned within the COA configuration can be
checked against an additional limit in the approval level (All pack
scenario).

Figure 9-11: Approval Flow Settings - Baseline Sequential approval details
Additional information about maintaining the Approval Flow

Settings can be found in the OpenText Vendor Invoice
Management for SAP Solutions - Configuration Guide, found in
the OpenText My Support portal.
Step by step: Mapping The second step is the mapping of approval flow settings to the VIM
AFS IDs to Document document type - The configured approval template with its approval
Types flow ID (AFS ID) must be mapped to a DP document type. Each
document type can be maintained individually. This is a mandatory
task.
– Type the /OPT/SPRO transaction into the SAP command field,

press Enter, and navigate to Vendor Invoice Management ->
Invoice Approval Configuration -> Approval Workflow -> Setup
Approval Chain -> Mapping for Approval Flow Settings.
Figure 9-12:
Mapping for Approval

Flow Settings task
– Execute this task.

Figure 9-13: Mapping the AFS to the Document Type
– Edit and save your entries.

 Defining dynamic determination - This maintenance step is only
relevant if the AFS mapping to Document Type - Activation Type is set
to Activate by Determination. If you choose this mapping activation
type, you must perform this step. If you activate it always or by custom
function module, then this customizing is not necessary. For additional
information on this configuration, please consult the OpenText Vendor
Invoice Management for SAP Solutions v 16.3.1 Configuration Guide.
If a level based approval flow starts for a work item, the work item
will keep the AFS settings that are captured initially. Even if the
AFS settings are changed in the middle of the approval, it does not
consider the latest change.
Expense Types For one specific approver, different approval limits can be defined for
different expense types. Typical examples of expense type are:
 Capital
 Marketing Expense
 Office Supply
 Communication
 Utility
Figure 9-14: Expense Type configuration
The Approval Req flag is used to indicate if the expense type requires an
Invoice Approval process.

E-mail notification When an invoice is sent for approval to an agent, an e-mail can be
generated to alert that user. Approvers will receive these e-mails saying that
new invoices are waiting in their SAP inbox. If the optional Approval Portal
is implemented, the emails contain a URL link to either the portal with the
invoice iView or the invoice list page. The following is an example of a
notification email:
Figure 9-15: Example notification e-mail
The notification email can be configured to include some invoice

information, such as vendor name, invoice reference number, or invoice
amount.
Step by step: In order to customize the body of the e-mail:

Customizing the e-mail
1. Type the SO10 transaction code into the SAP command field.
notification body
2. Press Enter.
3. Enter the Text name INVOICE_APPROVAL_NOTIFICATION, select
Text ID ST (Standard text) and click Create (or Change, this Text is
delivered with Baseline).
 To include contents of invoice fields use the following notation:
<(>&<)>/ORS/INVAP. InvoiceAmount<(>&<)>. These variables will
be replaced at runtime by evaluating the current instance of the
business object /ORS/INVAP.
Texts must be maintained in all applicable languages. If the value of Sy-

langu (the user’s logon language) does not have an associated text
maintained then no e-mail will be sent.
The notification emails can also be sent in HTML format with

readable formatting and invoice data presented in the form of
HTML tables.
To enable this functionality, access the Webflow Constant table
and set the constant 005 / REM_MAIL_DOCTYPE to HTM. In the /
OPT/VIM_8CX50 transaction, configure the e-mail Type to be
Internet e-mail.
Configuring fields for The approval screen in the SAP GUI, Approval Portal and Mobile Approval
the invoice approval Portal contains a number of fields that can be configured depending on the
screen calling application (SAP GUI / Portal / Mobile / Fiori).
Invoice detail fields Header and detail item fields along with their corresponding attributes must
be configured for the invoice detail page. This is mandatory in order to
render the fields on the Approval screen.
Step by step: Configuring 1. Type the /OPT/SPRO transaction code into the SAP command field.
approval screen invoice
2. Press Enter.
detail fields
3. Navigate to Vendor Invoice Management > Invoice Approval
Configuration > User Experience >Invoice Detail Configuration >
Maintain Invoice Detail Fields.
Figure 9-16:
Maintain Invoice Detail

Fields task

5. Edit and Save your entries.
Figure 9-17: Invoice Detail Fields configuration
For the coding fields, you must also configure all fields separately.
This configuration separates display functionality and the
functionality to read and store data back in the invoice line items,
independent of the field status on the screen.
Invoice List fields Whenever invoices are displayed in a list view in the system, there are
particular fields that are displayed. This aids the agent in being able to
choose the correct item for processing or viewing. This set of fields is
configurable.
Step by step To configure this display:

1. Type the /OPT/SPRO transaction code into the SAP command field.
2. Navigate to Vendor Invoice Management -> Invoice Approval
Configuration -> User Experience -> Invoice List Configuration ->
Maintain Invoice List Fields.
Figure 9-18:
Maintain Invoice List

Fields task

Figure 9-19: Invoice Fields list display
4. Edit your field selections and save your entries.
Alternatively, if personalization is not configured then the default invoice list

configuration can be employed. This is set in the WebFlow constant table
(via transaction code SM30, Table /PTGWFI/Z_CONST via parameter
DEFAULT_INV_LIST).
Exits Exits can be used to integrate individual screen logic in the Approval Portal
and Mobile Approval Portal. These are configured via the Web Flow
constant table as well. The following parameters should be populated with
the appropriate function module that will be called:
 EXIT_INVOICE_ACTION
 EXIT_INVOICE_DETAIL
 EXIT_INVOICE_LIST
OpenText provides template function modules that can be leveraged for

custom function module development. These are:
 /OPT/OAP_EXIT_ACTION
 /OPT/OAP_EXIT_DETAIL
 /OPT/OAP_EXIT_LIST
Button configuration Buttons can be added to the Invoice List and the Invoice Detail page of the
Approval Portal and the Mobile Approval Portal. The assignment can be
dynamic, according to the type of the invoice and the approver role.
Depending on where the button is displayed, configuration for this option
varies. This is depicted in the next figure.
Figure 9-20:
Configuring buttons

Roles
There are three main Roles in the Invoice Approval Process. They are
Coder, Requester, and Approver. The term Role is used differently here
than in other parts of VIM processing.
The roles used in the IAP process are technically different from the ones
used in all other processes. This section describes the main roles that are
required for the IAP process.
The Coder This terms signifies that the user has the capability to assign accounting
data within an invoice. This role is essentially, just an approver that has also
been granted access to code an invoice. To effectuate this, the Coding flag
is set for a user. If an invoice is parked, it will go to the Coder first. Some
typical ways for determining Coder are in the following table.
Method Details
by Requester Each Requester has a designated Coder
by Company Code Each Company Code has a designated Coder
Both Coder is determined by both Requester and

Company Code
Use Requester (Default) The Coder will the Requester of the invoice -
allows the requester to complete coding
changes
Settings are configured in the Approval Flow Settings.
Coding validation If there are custom requirements for validating the account assignment data
on the invoice coding screens, the BAdI infrastructure can be used to
implement custom validations.
For more information concerning how to utilize the BAdI

infrastructure, see the Configuration Guide.
The Approver User identities are maintained in the table /ORS/USERMAP. However, this
table does not have a maintenance interface and therefore must be
maintained via the COA maintenance transaction code /OPT/VIM_7CX1
(for Simple approval).
Step by step: Configuring 1. Enter transaction code /OPT/AR_COA into the SAP command field.
the new COA
2. Alternatively run the /n/OPT/VIM transaction and navigate to OpenText
Vendor Invoice Management -> SAP menu -> Roles -> Level Based
Approval Flow -> Level Based Approval - Chart of Authority
Maintenance.
Figure 9-21:
New COA Chart of

Authority maintenance
3. Double-click this menu path.

Figure 9-22: New COA
4. Populate the tabs, according to the rules for Level based approval.
COA upload The initial conversion of data into the COA maintenance tables can be labor
intensive. And the ongoing maintenance, perhaps an interface, might prove
to require a large amount of maintenance. For this reason, OpenText
provides a utility program which allows the customer to do an upload of data
into the New COA maintenance table.
The program can be run for a Full load - where all existing records are
removed and the new records are created via the file. Alternatively, the
program can be run for Delta load, which only updates existing records,
deletes old records, and creates new records. To access this program, type
the transaction code /n/OPT/VIM_COAUPLOAD into the SAP command
field and press Enter.
Figure 9-23: VIM COA upload report: Selection screen
The COA Upload Report might be used as a template for an

ongoing interface, which updates the COA tables on a periodic
basis. To schedule this report to run in the background, use
program /OPT/COA_UPLOAD_REPORT.
The COA Upload Report might also be used as a download utility to extract
the existing entries in the COA table.

Approver Personas The Approver Persona is determined by a set of check boxes that define
what an approver can do when approving the invoice. The access rights are
controlled by various flags that can be set for stack entries during approval
logic execution. The table for approver persona attributes is
/OPT/BL_AP_CONF.
Step by step: Editing 1. Enter transaction code SM30 or SM31 into the SAP command field.
Approver Persona
2. Press Enter.
attributes
3. Enter /OPT/BL_AP_CONF into the Table/View field.
4. Press Enter.
Figure 9-24: Approver Persona table via SM31
5. According to User Type and Invoice Type combination, make your

appropriate choices for the approving user. Some of these options are
explained next. The Approval check box should always be marked.
Override In order to override the next approver, the current user should be able to
override the system-generated next approver. To do so, the process option
associated with approval must have the Override check box marked.
Figure 9-25: Override configuration
CoDelegate If the current coder/approver can not complete the coding, the current
coder/approver may delegate to another. To do so, the approver persona
needs to have the CODELEGATE check box selected. Some stipulations
for Delegation are:
 The user must have same authorization limits as the original approver
 The Delegate has effective start and end dates
 Invoices are sent directly to the delegate’s Inbox
 An approval audit trail log shows the delegate is acting on behalf of the
original approver

Substitution The approver or coder can set a substitute to assume their responsibility
during vacation or a time of leave. This is accomplished as follows:
 From the Portal IAP:
– From the approval web page, open the User Preference page.
– Open the Substitution section.
 From the SAP inbox:
– Choose Add substitute from the SAP menu.
 From the User Substitute Management Utility (/ORS/MAIN_SUBS
transaction).
The /ORS/MAIN_SUBS transaction code can be used to maintain

all the substitute relationships in the system.
Figure 9-26: User Substitute Management Utility
Rejection Rejection reasons are defined for PO based invoices. The approvers are
presented with possible rejection reasons, if they are configured.
Step by step: Configuring Type the /OPT/VIM_IMG421 transaction code into the SAP command field.
Rejection reasons Alternatively, run the SM30 transaction to maintain table
/PTGWFI/Z_CONST, and locate the records with Product Code IAP and
Constant REJECTION_REASON.
Figure 9-27: Configuring Rejection reasons

Resubmit If the option for resubmitting an invoice is configured then the user can
restart the approval process for an invoice after it has been rejected.
Step by step: Configuring In order to configure Resubmit for Approval Action Codes:
Resubmit for Approval
1. Use the /OPT/VIM_IMG412 transaction code. Alternatively, navigate to
action codes
Vendor Invoice Management -> Invoice Approval Configuration ->
Approval Workflow -> Resubmit for Approval Action Code.
2. Define the Constant Value.
Figure 9-28: Approval Action codes
In the previous figure, 8701...2028 represent Process Options for

submitting for approval which should be available in the
dashboard.
Step by step: Approval In order to activate this functionality, a Process Option must be configured
Process Types and for Starting the Approval Process (Typically Process Option 2015). Then:
Options
1. Type the /OPT/VIM_8CX1 transaction into the SAP command field.
2. Press Enter.
Figure 9-29: Approval Process Type
3. Mark the Approval related Process Type and click User Process Option
in the navigation panel.

Figure 9-30: Start Approval Process Option
4. The DP process option (2015) should be configured as user option for

the Approval related Process Type.
Bulk Approval From VIM 6.0 onwards, the bulk approval/rejection validation function
module /ORS/AINV_BULK_VALIDATE_INV provides a customer exit.
The baseline validation functionality might not meet the customer’s
requirements. A new function module can be created with the same
interface as /ORS/AINV_BULK_VALIDATE_INV.
Step by step: To configure the bulk approval validation exit:

Customizing Bulk
1. Run the SM30 transaction to maintain table /PTGWFI/Z_CONST.
Approval
2. Locate the record with Product Code IAP and Constant
BULK_VALIDATE_EXIT.
3. Enter the name of your function module in Constant Value.
The baseline function module calls your function module if it is configured

and ignores the validations provided in baseline.
Custom Classes
With the latest release of VIM, OpenText delivers new opportunities for
extending the solution. Classes are used for modifying or extending
standard functions. Custom classes allow the customer to create a more
robust or more customer specific solution where the Baseline can not be
utilized or configured to meet their needs. For IAP, the following classes
should be noted.
Class WebFlow Constant Base Class Name Example
Custom APPROVER_CLASS /OPT/CL_IAP_APPROVER_BL By modifying/extending the

Approver Class method NEXT, you can
implement your own logic to
determine the approvers in
the approval process.
Custom Invoice NPO_INV_CLASS /ORS/NON_PO_INVOICE_NEW This might be used to

Class PO_INV_CLASS PO_INVOICE_NEW create more complex
validation logic for the
accounting data in the
method
VALIDATEACCTDATA.
In order to use these classes, populate the relevant constant in the

WebFlow constant table (shown above) with the custom class.
Exercise: NEW COA
Configure the NEW Chart of Authority
1. Execute Transaction Code: /n/OPT/AR_COA.

2. Select the Display/Change button.
3. Click the Plus button to insert a row.
4. Create a new approver entry by entering: Last Name, First Name, SAP
User ID, SAP portal name (e.g. “test”), E-mail Address.
5. Save your new entry.
6. Click the Approval Limit/Level tab.
7. Assign an approval amount to newly created approver.
8. Save your new entry.
9. Optional:
 Execute Transaction Code: SU01
 Create a new SAP User, (e. g. copy your training account: USER-
##)

Exercise: Approval Configurations
Configure Recall and Reassign
1. Execute Transaction Code: /ORS/UMREASSIGNED.

2. Run without any variant data.
3. Select an invoice under one Approver and press the REASSIGN button.
4. Select a new Approver from the drop-down list.
Maintain Approval Substitutes
5. Execute Transaction Code: /ORS/MAIN_SUBS.

6. Search for a user.
7. Select: Select a substitute.
8. Set a new substitute and From and To dates.
Summary
In this chapter we introduced the Invoice Approval Processing component
for VIM. This component handles the approval flow, workflow, and handling
of all invoices. It uses the concept of the Chart of Authority to allow for
determination of approvers. This chapter covers both the older method of
invoice approval, now referred to as Simple approval but focuses mainly on
the newer method, referred to as Level based approval.
Test your knowledge
1. Compare and contrast simple versus level based approvals in VIM.
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
2. Explain the main configuration steps for level based approvals.
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________

Cha pter 10. Cu stomizing Busin ess C enter C aptur e
10. Customizing Business Center Capture
Objectives

 Identify the various OCR methods used by Business Capture Center
 Use the BCC Configuration Client
 Create an Invoice Application
 Explain how ICC/BCC fits into Early Archiving
Business Center Capture

As explained in previous chapters, Business Center Capture (BCC) is a
component of OpenText™ Business Center for SAP® Solutions. BCC
provides for automatic extraction and manual validation of various types of
business documents, for example Sales Orders or Delivery Notes. This is
done via the technology of Optical Character Recognition (OCR). For VIM,
BCC will be used strictly for recognizing invoices.
History OpenText has over 40 years of experience in providing leading edge OCR
technology. OpenText has previously offered this technology with two other
products, Invoice Capture Center (ICC) and OpenText Capture Center
(OCC). Both of these products have matured over the years to be fore
runners in the OCR space. These products currently support a multitude of
customers, some of whom process millions of pages per year.
OpenText’s OCR technology is patented and the full stack is owned in

house. This is an advantage to our customers. While ICC is used strictly in
conjunction with the Vendor Invoice Management solution, OCC can be
used in a more generic fashion. OCC allows for the capture of various
document types.
Although ICC was previously a stand alone product, as of BCC

16.3, ICC is now embedded in the BCC product. This course
attempts to distinguish the more specific functionality within BCC
which is for VIM, namely the Invoice Applications. However,
sometimes Invoice Applications are used synonymously with the
acronym ICC.
Cha pter 10. C ustomizing Busin ess C enter C aptur e
Business Center Capture With the introduction of SAP Business Center, OpenText leveraged its OCR
history and products and developed the SAP Business Center Capture
(BCC). From a licensing perspective, this product is a part of the Business
Center license.
From a functionality perspective, BCC has built on the foundation of Invoice

Capture Center and OpenText Capture Center. Yet, BCC can capture any
type of business document. Not only does it leverage the existing OCR
product functionality, it also introduces three new methods for automated
learning. Automated learning, in conjunction with the traditional recognition
methods, will ensure the customer obtains the highest OCR recognition rate
possible.
BCC architecture
As described previously, the Business Capture Center is an OCR software
solution for recognizing various types of documents. The functionality for
recognizing the document data and for validating that data is contained in
the Extraction Service and the Validation Service respectively. These
services sit on the Business Center Capture server, and must interact with
the SAP system and the Archive. As such, it requires that each type of
incoming document is assigned certain parameters to inform the system of
how to process the document. There is also the requirement to set up
communication between these various components and the clients (such as
the Scan client, the BCC clients, and the SAP client).
Setting these parameters, or customizing BCC, requires configuration in

both systems (Business Capture Center and Business Center).
Figure 10-1: Architecture of Business Capture Center and Inbound Foundation
Landscape BCC is comprised of a Recognition Cluster and several Validation Clients

(as shown for review in the next figure) The Recognition Cluster consists of
a Server (which includes the BCC Customizing Client) and additional
Recognition Nodes. The Recognition Cluster gets recognition jobs from
SAP, fetches the corresponding document images from the archive,
performs data extraction, and returns its results to SAP.
Figure 10-2:
Architecture of the
Business Center Capture
OCR integration in VIM

The first step for preparing an invoice for DP processing is to capture the
index data that is required from the invoice itself. When a company is
receiving paper invoices, this can be handled in two ways.
Manual Indexing The first option is to manually capture the data fields from the invoice via a
user who deciphers each invoice.
In the scenario of manual indexing, the following are true:

 The index screen is a delivered part of the VIM Dashboard
 Basic data validation can be done on the index screen
 A customer can customize the index screen
 Business rules are executed after indexes are submitted
OCR scenario The second option is to utilize software that recognizes fields on the invoice
and places them into the data fields that VIM requires. This is referred to as
Optical Character Recognition (OCR). OCR can be utilized to further
automate the processing of paper invoices through the SAP VIM system. In
this scenario, the SAP system serves as the backend receiving system for
storing and receiving information from the OCR software.
When a customer is evaluating whether or not to use OCR, the following

should be considered:
 VIM does not have an OCR engine
 VIM uses OpenText BCC or a third party OCR software to provide OCR
services
 VIM has a defined OCR interface using standard SAP technology
 The data validation (Business Rules) is executed when indexes are
passed to the DP workflow
Business Center If a customer plans on using OCR, OpenText’s Business Center Capture
Capture for VIM (BCC) is the base product for recognition technology. Along with an Invoice
Capture Center (ICC) application, the products work in seamless
conjunction with VIM. The Invoice Capture Center application provides
automatic data extraction via OCR/IDR for invoice header and item data.
The VIM application for ICC (a.k.a invoice accelerator) is delivered with the
VIM Software and is installed on top of the BCC product.
Starting with BCC 16.3, ICC is no longer available. If you used ICC,
remove ICC, install BCC and, in addition, the BCC Invoice Solution plug-
in.
Invoice accelerator The invoice accelerator, which is a BCC application is pre-configured to

automate and simplify invoice processing. It improves data quality as logical
checks are made during the recognition process (e.g. sum checks for
invoice amount fields, checks for valid invoice data).
Intelligent document capture recognizes not only data found on the image
but also determines which fields are needed for invoice processing in SAP
(e.g. Vendor number or Company code) by matching invoice data with SAP
master data that has been shared with the BCC/ICC system.
Figure 10-3: Sample data captured by ICC/BCC for SAP VIM
Architecture To show where OCR fits into overall VIM processing, the following figure is
shown. Note that enabling OCR via BCC does not necessarily negate the
need for validation to take place.
Figure 10-4:
Recognition in the VIM

Process
Early Archiving Scenario The Document Handler is a part of VIM. Using services of the Document
Handler and the Registration Handler (formerly the ICC Dispatcher), all
tasks related to the following actions can be controlled:
 storing documents
 retrieving documents
 extracting documents
 validating documents
In order to understand the true flow of a document when using BCC within
the context of VIM, the scenario for Early Archiving will be dissected. Here,
we assume that EnterpriseScan is being used to first scan the document in
and store it in the Archive Server electronically.
Figure 10-5: Data flow steps in sequence
1. SAP calls Enterprise Scan through the Early Archiving registration type,
using the OAWD transaction.
2. The OAWD transaction creates a registration entry in SAP using the
registration interface class implementation
/OTX/PF01_CL_REGISTER_OAWD.
3. The registration method inserts an entry to tables /OTX/PF01_T_1REG
and /OTX/PF01_T_1IMG and sets the status to Registered.
4. The document handler (periodic job for report
/OTX/PF01_P_IDF_TRIGGER) processes the required service
modules in SAP ERP and sets the status accordingly.
5. The BCC Extraction service calls the API function
/OTX/PF01_IF_GET_NEW_DOC_LIST using a scheduled batch job on
BCC side and gets new documents for processing:
 Gets all documents in status Ready for OCR extraction along with
secure URL for image and XML document, which will be created by
the BCC Extraction service.
 Updates the document status to Sent to OCR.
6. The BCC Extraction service picks the documents from 3 on page 84
and imports the corresponding images from the Archive.
7. The Export module of the BCC Extraction engine calls the API function
/OTX/PF01_IF_OCR_DATA_UPDATE_N with call point EX:
 Updates the status and OCR data appropriately. This API exports
the data to SAP after completion of the extraction phase. Table
/OTX/PF01_T_1EXT will be updated with extracted data.
 Updates the DP Document status to Extraction Completed.
8. The BCC Extraction service sends the detailed results XML file of the
exported data to the Archive using the URL retrieved from SAP. The
BCC Validation engine uses the XML file. Results for each data
exported to SAP ERP are stored in an XML file and archived.
9. The document handler picks up the registered items with status
Extraction Completed. The document handler checks if validation is
required or not. If validation is required, the status is set to Ready for
Validation. If validation is not required, the document handler will
process the corresponding service modules and trigger the target
application.
10. The BCC Validation service calls the /OTX/
PF01_IF_GET_VAL_DOC_LIST API and gets a list of documents for
validation:
 Gets all the documents in status Ready for Validation.
 For each document, it gets the secure URL for image and XML
documents, which will be used by the BCC Validation Client.
11. The BCC Validation service calls the /OTX/
PF01_IF_OCR_DATA_UPDATE_N API with call point VA:
 Updates the status and OCR data appropriately. This API exports
the data toSAP ERP after completion of the validation phase. The /
OTX/PF01_T_1EXTtable is updated with validation data.
 Updates the document status to Validation Completed.
12. The document handler picks up registered items with status Wait for
Validation completed, and after elapsed time sets the status to Error.
13. The document handler picks up the registered items with status Wait for
Extraction completed and checks the time elapsed. If it exceeds the
configured time, the status is set to Error.
14. The document handler picks up registered items with status Validation
Completed, processes the corresponding service modules, and triggers
the target application.
Figure 10-6:
The steps of an Inbound

BCC process in Business
Center Inbound
Administration
The previous figure showcases the steps which are involved in the inbound
process when using ICC/BCC. The document is first registered and then
follows the steps previously outlined through to completion of the inbound
process. Note the status change with each step of the process.
 Registered
 Linkage created for archived document
 Registered in target application
 Ready for extraction
 Sent for extraction
 Extraction completed
 Ready for validation
 Sent for validation
 Validation completed
 Ready for the business application/process
 Business application/process started
 Inbound completed
BCC customizing First, we will cover customizing within the Business Capture Center. The
client Business Capture Center deploys two client interfaces to end users. The
first, the Validation client, is used to confirm and submit recognition results
when a document is in the Ready for validation status. This is covered in a
separate chapter of the course. In this chapter, we cover the Customizing
Client, which is used for preparing the software to recognize documents.
Creating custom BCC Applications is extensive and detailed work.

This chapter gives an overview of the configuration aspects and
highlights the configuration for a BCC Invoice Application.
OpenText offers separate courses for OCC/ICC/BCC, which teach
the student how to create custom applications.
There is also a customizing guide available for Business Capture
Center, available on the OpenText Knowledge Center.
Launching the BCC The Customizing Client is installed on the desktop for those who have the
Customizing client permission to access it.
Figure 10-7:
BCC Customizing client

icon
Much like other applications, the configuration portion of BCC (the

customizing client) should be restricted to a small set of users who are
trained to administer the system and configure applications.
Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Page 10- 11
Once the authorized user launches the application, they find that the
Customizing client is split into two tabs:
 The General tab
 The Application tab
Figure 10-8:
Tabs in the BCC

customizing client
General tab The General tab provides the capability to monitor the Applications which
have been installed or created. On the General tab, a user can switch
between several technical views:
 HotSpot
 Jobs
 Cluster
Figure 10-9: BCC customizing client: The General tab
The General tab also shows the Recognition Server status at a global level.
It is used for the administrative tasks associated with the server.
Application tab Conversely, the Application tab allows the user to affect one application at a
time. From the Application tab, the user clicks on the Blue Paper icon and
then navigates the menu to perform the associated task. The menu of tasks
is shown in the next figure.
Figure 10-10: BCC customizing client: The Application tab
From this menu, a user can:

 Create new applications
 Open an existing application
 Import an applications from a file
 Modify an existing application
 Check the SAP connection
Applications Applications provide a construct for saving various customizing settings. In

order to tailor Business Capture Center to specific needs, Applications must
be created.Application creation is done within the Customizing Client on the
Recognition Server, usually on a special development Recognition Server
or standalone system, which is connected to an SAP ECC development
system. Applications are stored in a shared folder on the Recognition
Server.
Once created, BCC Applications are immediately available to perform

recognition on the Recognition Server. However, in order to be available in
the Validation client, the application has to be exported to the respective
SAP system.
Invoice Applications BCC uses Applications to process invoices of certain types through the
extraction process.
 An Invoice Application is a pre-defined extraction project containing a
set of rules for extraction and validation of invoice data and other
required settings.
 BCC allows for several applications running in parallel on the same
BCC server.
 Applications can be comprised of single countries, multiple countries, or
might be created for special circumstances.
Figure 10-11:
BCC Applications stored

in SAP
Creating a new In the Application menu, the option for New Application can be chosen in
Application order to create a new BCC Application. Once the user makes this selection,
they are given the choice of several Application Types.
Figure 10-12: Creating a new BCC Application: Choose Application Type
The Application Types are:

 Custom - An Application completely suited to the customers needs
 Delivery Note - A Solution Accelerator Application for Delivery Notes
 Digital Mailroom for HR-Classification - A Solution Acclerator
Application for classifying incoming HR documents
 Digital Mailroom for HR - Extraction - A Solution Acclerator Application
for extracting data from incoming HR documents
 Sales Order - A Solution Accelerator Application for Sales Orders
 Invoice Multiple Countries - An Application used for Vendor Invoice
Management functionality
 Invoice Single Country - An Application used for Vendor Invoice
Management functionality
In order for the Application Type of Invoice... to pop up in this

dialog, the Invoice Solution must be installed.
Once the application has been created, the next step is to choose the
desired country.
Figure 10-13: Choice of country for Invoice Application
The next step is to add the specification of which ArchiveLink Document

Type(s) that should be processed by this application.
Figure 10-14: ArchiveLink Document Type assignment
The next step is to designate how the Company Code will be detected.
There are three different methods:
 A single, fixed company code for all documents of the current
application
 A separate company code for each archive document type
 Automatic company code detection
Figure 10-15: Choose Company Code detection method
Once SAP connection data has been configured, the application is ready to
be created.
Demo: Invoice Application Creation in BCC Customizing Client
1. The instructor will showcase the creation of an invoice application in the

BCC Customizing Client.
The steps for creating an invoice application are given in this

chapter, beginning on page 14 to follow along.
2. In order for the new application to be available in the Validation client,

the instructor will also showcase the Export of this application to the
SAP system.
Optimizing OCR recognition

Once an application has been created, the customer’s attention turns to
optimizing the results of the data recognition.
To heighten recognition percentages, Business Center Capture leverages

classical OCR methods and newer methods (such as Continuous Self
Adaption). Both types of methods are expounded on further.
Classical methods The classical OCR methods are:

 Full Text Reading - a complete read of all characters
 Rule-based Free Form Recognition -uses fixed rules which are defined
to give clues as to the target values location and format
 Snap Match -uses data tables to look up the correct values from data it
can find on the document
 Adaptive Recognition Technology (ART) - extracts fields using
templates to determine the position of a certain value. These templates
are defined beforehand and do not change based on processing
Continuous Self Beyond these classical OCR methods, three new adaptive methods have
Adaptive methods been developed for BCC automated learning. These are necessitated by
the nature of Business Center as a framework for manifold document
applications.
These adaptive methods learn based on manual data entry by the user.
(user feedback).
Continuous Self- Continuous Self-Adaptation can only be used in BCC applications. It uses
Adaption data collected by the Validation Client and SAP to adapt to reoccurring
document types automatically. The new CSA methods are:
 Layout-unspecific Phrase Learning (LUPL)
 Layout-specific Rules
 Adaptive Line Item Extraction
Machine Learning is an umbrella term for Continuous Self

Adaption (CSA) and Layout based methods - LUPL and LSPL
 CSA - uses data collected by the Validation client (which is
input by the user) to create its own templates to use for each
document it reads. It then can subsequently find fields based
on those templates and the rules it has created to go with it.
 LUPL/LSPL - phrase learning methods which again learn
based on the user first teaching the system which phrases to
look for
Classical: Full Text This method is the automated recognition of the complete text of an
Reading(RecoStar) incoming document.
Figure 10-16:
Full Text Reading:

sample document
Within BCC, the result of a full text read is shown in the next figure.
Although the fields may or may not be mapped, they have been captured. It
also allows the user to “mouse over” any text fields for the movement of
data fields with the click of a mouse.
Figure 10-17: Result of Full Text Reading
Classical: Rule-Based This method provides for the automated extraction of structured data within
Free Forms documents of variable layout. Examples of documents which are good
Recognition(DOKuStar) candidates for this method are: Invoices, Sales Orders, and Delivery Notes.
Figure 10-18:
Sample Document: Rules

Based Free From
Recognition
Classical: SnapMatch This method is for data lookup and matching of that data. The SnapMatch
automation method permits the user to match a key data field against a
database. If a matching database record can be found, all data fields
assigned to the columns of the database are then filled in automatically. For
example, this method might be used to find the Vendor ID or the Customer
ID, based on master data, such as Vendor Name or Customer Name. In
BCC, SnapMatch is used in Look Up Lists.
Figure 10-19:
SnapMatch Vendor
detection
Classical: Adaptive ART is an adaptive OCR method. It is initiated by a user who trains the
Recognition Technology system by repeatedly clicking on the target data field and then choosing the
(ART) correct field in the recognized document (via Single Click Entry technology).
The ART method learns from many layout-specific samples. This is used
effectively by a power user. For example, this method would be effective in
training the system to recognize the hand written Invoice Date of a specific
vendor.
CSA: LUPL Layout-Unspecific Phrase Learning is a self-learning automation method

that uses typical phrases to find a corresponding value with a specified
format, for example a date or an amount. LUPL learns based on user
feedback. It learns to recognize document header fields related to key
words like Document Date, Document Number, and Document Reference.
It does this without considering the layout of the document.
Figure 10-20:
Adaptive Learning: LUPL

for finding order date
In the previous figure, BCC uses LUPL to search for the phrase “Order
Date” and then to find the associated, formatted date field with the value
“10/24/10”.
CSA: Layout-specific Automated learning of layout-specific rules can also be achieved by

rules collecting user feedback. In this method, the system learns layout based
rules for recognizing fields not related to keywords but related to data
values such as Business Partner or Material Number.
CSA: Adaptive line item Automated Learning of layout-specific rules can also be achieved for line
extraction items by collecting user feedback. In this method, the system learns to
recognize line items for specific layouts (such as a table).
The next set of figures will show an example of how a user could initiate the
Auto Table Complete Self Learning (a specific example of Adaptive Line
Item Extraction).
1. The first step is for the user to place their cursor in the first row of the
table in the left frame. They then click on the first row of line item data in
the document image.
Figure 10-21:Auto Table Complete self learning: Step 1
2. The next step is to click on the TAC, Table Auto Complete button, which
will complete the line items remaining.
Figure 10-22:Auto Table Complete self learning: Step 2
3. The table is now populated and the next document of the same
document type, which is recognized, should have the table line items
recognized and populated correctly (as shown in the next figure).
Figure 10-23: Auto Table Complete self learning: Step 3
After several iterations where the user captures data, OCR will begin to
deliver the data automatically. The confidence level of the results will
increase per document. The new learning methods adapt quickly to new
Document Types and new countries.The confidence in the OCR results will
grow quickly with these new adaptive learning methods.
Benefits: Continuous Self The Continuous Self Adaption methods will:

Adaption
 Reduce implementation effort through automatic adaptation
 Adapt to changes in business through permanent feedback evaluation
 Provide excellent recognition rates through adaptation to the customer
environment
OpenText is now offering OCR services as Information Extraction

Service for Invoices (IES). IES uses the same machine learning
algorithms we’ve reviewed. These are the Continuous Self
Adaptation (CSA) algorithms.
 As we have seen, CSA learns from user feedback. For
invoices CSA is used in combination with the invoice
knowledge base.
 Therefore, IES reduces the need for data entry for the user.
 Layout oriented algorithms work based on the geometry of
the data related to the text layout. These algorithms are
learning very fast – at the second pass of a document of the
same business partners, a learning result will be available.
 Layout independent algorithms consider the data structure
and the surrounding text of the data – these algorithms need
additional passes until learning results will be provided.
 A voting mechanism evaluates the results of the different
methods and decides which is the best result based on
feedback.
 For invoices the voting also considers results of the invoice
knowledge base.
Invoice data extraction

process
Figure 10-24: Typical data extraction from an invoice
The recognition process breaks down into several steps as follows:

 Recognize - Here the system intakes pixels and turns them into
characters.
 Analyze - Here the software searches the document, finds meaningful
fields, and tags them.
 Extract - Here the system discerns which fields are required (i.e. finds
the correct date among all detected alternatives).
 Normalize - Here the software decomposes string values into
meaningful sub units and reformats them as required (i.e. one country
date format into another).
 Verify - Here the system checks the field data against plausibility and
business rules.
Manual validation means keying in the data that could not be extracted
automatically or which failed to run through the verification step.
Company Code detection Company Code is used as a criteria for decision points within VIM and
within SAP. In particular, it is used in determining the Vendor and the Line
Item Mapping. Therefore, it is important to be able to detect Company
Code. Some of the ways ICC supports this detection are:
1. Fixed company code for defined SAP system - If the customer has only
one company code then this setting can be used.
2. Company Code per Archive Document type - If incoming invoices are
scanned separately for subsidiaries then scan jobs can be linked to the
Archive Document Types. Every subsidiary has one Archive Document
type. This allows the Validation task to be done by the user assigned to
that specific subsidiary.
3. Automatic Company Code detection - The company code is detected by
invoice recipient address (in US: ship to address). Ship to address can
be downloaded from SAP (that is the home address assigned to the
company code) and can be used as a template to extend for address
synonyms which are also valid (consider different spelling,
abbreviations etc.). In some countries only one registered address will
be valid.
Figure 10-25: Company Code detection strategy
Obtaining Vendor There are several scenarios concerning the Vendor on the invoice. It is
possible that the Vendor ID may or may not be detected. It is also possible
that the Vendor name appears, but not the Vendor ID. The Vendor is
necessary for posting and may be set as mandatory in the scan. The field
can be found with the aid of the invoice knowledge base or with SnapMatch
mapping to the SAP master data that has been shared with the ICC system.
It might also be deciphered via auxiliary information about the vendor, such
as telephone number, address, etc.
Figure 10-26: Vendor ID detection method
If the Vendor is not found via the PO data, SnapMatch technology. The
SnapMatch automation method matches a document against a database. If
a matching database record can be found, all data fields assigned to
columns of the database are then filled automatically.
SnapMatch delivers all possible vendors found by mapping SAP vendor

master data with the invoice data. If the company code is known, a filter is
set for company code. This makes sense if company code is used for
subsidiaries in foreign countries and due to company mergers vendors exist
with different vendor numbers in different company codes.
Obtaining invoice For invoice amounts, there are many fields that might need to be discerned,
Amount field such as net, gross, and currency. This data might also be extracted with the
help of the invoice knowledge base or by an iterated key value search.
Logical relationships between values are used for disambiguation. This is a
mandatory field for posting and in configuration, can be hooked to a
language setting.
Several other key fields must be detected with the OCR tool. Each of these
can be discerned with the help of the knowledge base and with techniques
in which OpenText ICC Global Services has extensive experience. Some of
the other fields and key methods of detection are:
 Invoice Date and Invoice Number - Iterated key value search, often
invoice date and invoice number are in close proximity
 Purchase Order Number - Iterated key value search, use of predefined
syntax (01923XXXX......) or via a downloaded list of open orders
 Line Items - Careful document analysis is a prerequisite to use this
customizing feature. Onwards from version 7.0, ICC will deliver line
item data, which previously had been filtered out if this option was
activated. The Line item filter is configurable. It allows for use of
Qualifying terms (or phrase lists) to identify specific line items like
material overhead, discounts, etc.
Figure 10-27:
Purchase Order excerpts
An optimized invoice After an Application is created and recognition methods are in place, the
accelerator application first document can be processed.
In this section, we will review an invoice application which has been

optimized with ART.
Step 1: First pass of an In this first step, an invoice is sent to the application for recognition. Most of
incoming document the resultant fields are obtained via the invoice knowledge base. Three key
fields have not been detected:
 PO Number
 Vendor
 PO Line Items
Figure 10-28: First pass recognition results
In order to train this document, the user would:

 Find the Vendor ID via look up (by searching the staging table described
previously).
 PO Number is on the image. So, the user would place the cursor in the
PONumber field and then click on the corresponding field in the image.
 Invoice Items will be need to be trained as well. The first thing the user
must do is to add a new empty entry to the invoice items grid (as shown
in the next figure).
Figure 10-29:Using TAC (Table Auto Completion) to train the invoice fields for line items
 Then, they press the TAC button at the top of the interface and the rest
of the line items are automatically populated.
 Now that the invoice fields are accurate, the user can submit this
invoice.
When the next invoice document is presented in this application, all of these
fields are automatically recognized. (as shown in the next figure).
Figure 10-30: A fully recognized invoice - second pass of machine learning
In this example machine learning scenario, the following OCR methods

were employed:
 Adaptive line item extraction
 Adaptive Recognition Technology
 SnapMatch
Configuring SAP for This section will cover the SAP-specific configuration for getting the BCC
BCC scenario up and running. Much of the configuration was handled in the
Inbound Configuration chapter.
The configuration entry point is transaction code /OTX/PF00_IMG->

OpenText Business Center for SAP Solutions > Inbound Configuration >
Basic Settings.
Figure 10-31:
BCC/ICC Configuration
within SAP
Step 1: Set Retry Limits Every time that OCR retrieves the image and XML Document URLs for
for Extraction and Recognition/Validation, the system will increase the Retry count. A
Validation dispatcher program in VIM will monitor all such documents and check
whether any DP document is in the Extraction/Validation process for more
than the allowed time. If so it sets the status back to ready for Extraction/
Validation.
To perform this configuration:
1. Execute the Basic Settings task.
Figure 10-32:
Validation and Extraction

retry counter setting
2. Choose Retry Counter Extraction and Retry Counter Validation.

3. Maintain the Customizing Value.
Step 2: Define New The validation framework determines whether a DP Document needs
Validation ID validation or not and assigns the validation agents to validate the DP
Document.
The Validation Assignment will determine whether Validation is required or

not. Under the Inbound Configuration -> Business Center Capture menu
choose Validation -> Set up a Validation ID.
Figure 10-33: The Validation IMG task
Step 3: Assign the In the next step, the Validation ID that should be used for each Archive
Validation ID to the Document type is defined. To configure this, under the Business Capture
Archive Document Type Center Menu, choose Validation Assignment.
Figure 10-34: Validation Groups to Archive Document Types assignment
Assign the Type of Validation via the ID which is required for each
Document Type.
Step 4: Assign the agents The next task in the IMG allows for the assignment of an SAP user, job,
organizational unit, work center or position for validation. It is performed in
the same dialog, but in the second row in the left hand frame as shown in
the next figure.
Figure 10-35:
Agent validation
assignment
Administering BCC for As with most SAP functionality, there is some standard maintenance which
VIM is periodically required. Here, we list some of these such tasks.
Document Handler Job This job is required to be run on a recurring basis, preferably every minute.
 /OTX/PF01_P_IDF_TRIGGER - When running the IDF trigger job, the
report picks up all items that have been registered to the framework and
that also have finished after the last run. So every item will go through
all steps defined in the customizing.
Download Programs These programs are used to move SAP Master Data to the ICC/BCC
Server.
 Vendor Download - This program downloads vendors with all company
and bank information to a staging table. The program name is
/OPT/IR_DL_VENDOR_TO_STG_TABLE.
 PO Download - This program downloads all POs and all open POs to a
staging table. The program name is
/OPT/IR_DL_PO_TO_STG_TABLES.
The next table shows the names of the staging tables that are used in the
download procedures.
Table Description
/OPT/VIM_STG_LIF Staging Data - Vendor master for ICC
/OPT/VIM_STG_PO Staging Data – Purchase Order and Deliveries

for ICC
/OPT/VIM_STG_POH PO header staging data for Download

Infrastructure
/OPT/VIM_STG_POI PO Item staging data for Download

Infrastructure
Creation of BCC users The following users must be created for interaction with the BCC Server.
 Recognition Server/Node User - The Recognition Server User
communicates with the SAP system to ask for recognition jobs,
download data, and learning data. The Recognition Server and the
Recognition Nodes export results to SAP. The Recognition Server and
Recognition Node are used as a prepared SAP user for the SAP
Download Link Hot Spot and the SAP Extraction Link Hot Spot.
 Customizing Client SAP User - This user is used for download and
upload of the BCC configuration to the SAP System.
 BCC Validation User - As soon as the Validation user has started the
Validation Client, the user has to log on to SAP using a prepared SAP
user. This user is connected to the VALIDATOR role.
Monitoring Tool VIM is delivered with a monitoring tool for BCC. This tool can be launched
via transaction code /n/OTX/PF03_WP.
Figure 10-36: Inbound Administration via the Business Center Workplace
Transaction code /n/OTX/PF03_WP can be given to provide

display only access to users that should not have administrative
authority.
BCC download programs Special programs are provided by OpenText for standalone testing, offline
for Invoice Applications scenarios and the initial load of company codes. There are programs
available for:
 Vendor data download
 Purchase order data download
 Receiver data download
 Recipient data download
Please see the OpenText Knowledge Center for additional information

regarding these programs.
Evaluating BCC Some general details that should be kept in mind when evaluating BCC as
an OCR option:
 BCC doesn’t duplicate SAP business logic in an external system
 BCC only uses SAP data downloads for recognition purpose
 BCC does some internal logical and mathematical checks on the
invoice (check invoice amounts, check line item amounts) for
recognition purposes but delivers no check result to Validation nor VIM
 BCC delivers data 1:1 from the invoice, if fields are recognized with high
reliability. If reliability is not sufficient, a field is delivered empty
 BCC doesn’t apply business rules and doesn‘t modify or deduct data
 BCC doesn’t complete a field, such as tax rate by calculating from
amount fields
 BCC Validation does not do comprehensive checks on a field level,
except for two fields: Vendor ID, Line item mapping
 VendorID: if not found, field remains empty. No address data is
delivered
 Line item mapping: recognition data is completed item by item by PO
number and PO line item number – for unmapped lines PO number and
PO line item number fields remain empty
 BCC incorporates Adaptive Learning Technologies which increase
recognition quickly
Demo: Using the BCC Invoice Application for PO based invoice
1. The instructor will process a PO invoice, using the newly created BCC
application (from the previous demo) and the following data:
 Input Invoice: sample PO-based invoice,
PO_ACME_Supply_Invoice(US).pdf
 ArchiveLink Document Type: ZVIM_ARCH
 DP Document Type: PO_S4
 OAWD setting: ZICC - BCC Capture Center Scenario
 Data for PO invoice creation
– Materials: TG10, TG11
– Vendor: USSU01
– Purchasing Organization 1710
– Purchasing Group: 100
– Company Code: 1710
– Plant: 1710
– Storage Location: 171A
Exercise: Now that you have watched the demo of the BCC scenario,
distinguish differences in the BCC scenario (SAP-specific
configuration) compared to that of the manual indexing scenario.
1. Compare and contrast the two DP Document Types which have been
used in class.
 PO_S4
 ZNPO##INV
a. Which field in DP Document Type configuration distinguishes that
processing is manual or OCR?
b. Which ArchiveLink Document Type is assigned (as a default) to
each of these DP Document Types?
2. Compare and contrast the inbound configuration task Registration:
Early Archiving for these two scenarios:
 ZVIM_ARCH
 Z##_INV
a. What are the two different values for Channel?
b. What are the two different values for Handler?
c. What does the field Classification do?
Exercise: Change your existing DP Document Type (ZNPO##INV) to BCC

specific
Change your existing DP Document Type (ZNPO##INV) to switch it

from a manual indexing solution to a BCC-enabled solution
1. The first step is to change the Indexing Type from Online Indexing to
Indexing using OCR.
This is done within the OpenText VIM-specific IMG. Transaction code /
OPT/SPO. Navigate to Document Processing Configuration ->
Document Type Configuration -> Maintain Document Types. Choose
your Document Type and then adjust the Document Index Type field
from Online Indexing to Indexing with OCR, as shown next.
Figure 10-37: DP Document Type: Index Type field
2. Next, Inbound Configuration for Registration must be changed.

This is done within the Business Center Inbound Configuration IMG:
Transaction Code /OTX/PF00_IMG. Navigate to Inbound Configuration
-> Document Handler -> Registration -> Early Archiving. Change the
existing entry for your ArchiveLink Document Type Z##_INV, to the
following values (as shown in the next figure):
 Channel: ICC
 Handler: PS03_CAPTU
Question: Why can the Classify field remain the same?
Figure 10-38:
Early Archiving
Registration for an OCR/
BCC scenario
3. Lastly, within the Inbound Configuration folder, navigate to Business

Center Capture -> Validation Assignment. Here the user or role that
should be allowed to validate results is assigned. This is shown next.
Figure 10-39:
Validation agent
assignment
In order to enable this functionality, your ArchiveLink Document Type

would now be assigned to the BCC Application (as shown in the demo). In
this classroom set-up there is not access for each student to perform this
configuration.
Summary
In this chapter the Business Center Capture architecture, configuration, and
methods for capturing data were introduced. The invoice application (ICC)
which runs in BCC was also highlighted.
Tips, tricks, and traps
 ICC can be used with Business Center Inbound Configuration to process invoices. New
customers should use Business Center Inbound Configuration for email and paper.
 Business Center foundation is included in the VIM license, however, BCC is licensed
separately. A VIM customer does not automatically get the BCC license. ICC and BCC
should be distinguished here.
C hapte r 11 . T he Fi ori Task A pp
11. The Fiori Task App
Objectives

 Explain landscape implications of using the Fiori Task App
 Install necessary components
 Navigate to essential configuration
The Fiori Task App

The Fiori Task App is an OpenText custom built application, which runs on
the SAP Fiori platform. It allows the end user to work on VIM/Business
Center tasks from their mobile device or from a browser on their desktop.
Figure 11-1:The Fiori Task Application
The following sections give you detailed information about the landscape,
customizing options and the interface of the Fiori Task App, which are a part
of Business Center Foundation (which comes with VIM).
Cha pter 11. The Fior i Ta sk App
The Fiori Task App is a light-weight web application following the Fiori
design principles. It represents an inbox showing the a class of items that
have been assigned to the logged-in user. The user then is able to complete
items by performing dedicated actions, entering comments, and editing the
data.
You configure the complete content of the Fiori Task App by customizing
and implementing interfaces of the Web Services. Therefore no extension
points for the Fiori Task App are offered and enhancements of the Fiori
Task App or the Business Center OData service are not supported.
Fiori architecture The next figure gives an example architecture for the deployment of the
Fiori application. Fiori can be accessed either via a mobile device or via a
desktop or laptop. In either case, the device will use the SAP Gateway and
two functionality Add-ons to communicate with the back end SAP system.
Figure 11-2: Fiori deployment options
Deployment The previous figure illustrates a potential deployment scenario:

requirements
 The Fiori Server - This requires a minimum SAP User Interface
Technology version 7.40.
 User Interfaces - Mobile, Web, and Desktop
 The SAP Server - Opentext recommends that the Service AddOn
OTBCWSR be placed on this server along with the OTBCFND AddOn.
 The following components are required:
– OTBCFND (Business Center Foundation)
– OTBCBAS (Business Center Base)
– OTBCINB (Inbound Configuration)
– OTBCSL0X (Solution Accelerators 01 - 0N are optional)
– OTBCWSR (Service AddOn)
– OTBCWUI (Business Center Web UI)
– OTBCCRM (only required if integrating Extended ECM)
Configuring the Fiori The steps for configuring the Fiori Task App are only highlighted here. The
Task App tasks are split between technical set-up and functional configuration.
Please see the OpenText Business Center for SAP Solutions

Configuration Guide 16.3.1 for further details.
Technical set-up 1. Enable the OData Service - The Fiori Task App communicates with SAP
using a dedicated OData service (/OTX/PF05_DATA). To invoke this
service using the HTTP protocol, it must be enabled.
i. Logon to the SAP Fiori server, which has the Fiori UI
functionality.
The server on which configuration for the services and Gateway is

performed will depend on each customer’s landscape (i.e. the manner in
which Fiori and the Gateway are deployed). In this example, the Fiori and
Gateway components are on one server, separate from the SAP ERP
server, which houses the components for Business Center.
ii. Navigate to the IMG path pictured in the following figure.
Figure 11-3: SAP Netweaver Gateway communication settings
a. Ensure all prerequisite communication settings have been made.
The RFC connections must be trusted.
b. Activate the SAP Netweaver Gateway.
c. Use the /IWFND/MAINT_SERVICE transaction to create the

backend service to the /OTX/PF05_data.
Figure 11-4: Enabling the OData backend Service
Figure 11-5: Adding the ZPF05_DATA service
2. Activating the BSP - The Fiori Task App is a BSP, which is defined on
the SAP ERP server. A prerequisite for launching a BSP is an active
service. This service is created on the Fiori Server in the SICF
transaction. For UI5 applications, the service is created by default,
nevertheless it must be activated.
a. Log on to the SAP Fiori server, which has the Fiori functionality.
b. To activate the service, run the SICF transaction and activate the /
sap/bc/ui5_ui5/otbcwui/pf07_bc_ui service (as shown in the next
figure).
Figure 11-6: Active Service for the BSP
Functional UI set up After technical set up is completed, the content and the visual aspect of the
Fiori Application must be set up. The area for this configuration is under the
Web Services menu in the OpenText specific IMG. This is depicted in the
next figure.
Figure 11-7:
IMG Area for the Fiori

Task App configuration
The following sections are available:

 Basic Settings - choose whether the Web Viewer of Brava! is used for
the display of documents
If no settings have been made in the viewer section, the associated

ArchiveLink documents will not display in the Fiori detail pane.
 Work Object Type - Choose which Work Object Types will be enabled
for the Fiori App
 Workplace - Define which Nodes will be available for Web Services
 Items - Define the behavior of the work objects of a work object type
 Input helps - Allows for the definition of input help at a field level for item
or header fields. Input Help can display domain value lists, use SAP
Search Helps, or call an SAP user exit, which has a predefined function
module in the BADI /OTX/PF62_BADI_INPUT_HELP.
 Perspectives - Define which item related data is displayed and where it

is displayed in the Fiori Task App.
We will cover the Perspectives tasks in more detail.
Figure 11-8:
IMG Area for UI set up
Perspectives Perspectives define which item related data is displayed in the Fiori Task
App and where. They define the content and visual appearance of items for
a specific area of the screen in the Fiori Task App. Only one perspective is
shown at the same time in the Fiori Task App.
Perspective views are delivered using the BSP applications

PF07_BC_UI_03, PS30_VIM_UI_03 (and custom BSPs). They reside on
the frontend server.
The Overview screen for Perspective configuration is shown in the next

figure.
Figure 11-9: Perspective Overview
Configuration of the Fiori Task App is covered in detail in the

OpenText Business Center Configuration Guide 16.3.1 Chapter 8.
Setting up launchpad For the Business Center Fiori Task App, set up the Fiori Launchpad tiles.
content
The general setup is described in Chapter 9 of the OpenText Business
Center for SAP Solutions - Configuration Guide 16.3.1. Import the
mentioned transport or configure the tiles.
The VIM specific tiles are also delivered with transports:

VendorInvoiceManagement-LaunchpadContent.zip. They can be
accessed on My Support: https://knowledge.opentext.com/
knowledge/llisapi.dll/Open/71941132
When setting up tiles for VIM, you need to know specific parameters for
each App. They are listed in the following table:
App nodeID wobjType workplaceId
Approve Invoices PS03_VIM_APR_INV PS03_PRC_VIM_APR WP_INBOX
Enter Cost Assignment PS32_VIM_SCO_INV PS32_PRC_VIM_SCO WP_INBOX
Resolve Invoice Exceptions PS31_VIM_RG01 PS31_VIM_WEB WP_INBOX
Confirm Quantity and Price PS35_VIM_MPOEX_INV PS35_VIM_MPOEX WP_INBOX
These Fiori Apps are specific to VIM 16.3 Classic Mode. Simple mode
apps and configuration are different and separate from these.
Summary
In this chapter the Fiori Task Application installation and configuration were
highlighted. Both technical set-up and functional configuration for enabling
the functionality in the Business Center landscape were covered. VIM
specific set up of the Fiori launchpad tiles was also highlighted.
Chap ter 12. O ptiona l VI M C onfigu rat ion
12. Optional VIM Configuration
Objectives

 Identify VIM Workplace extensions
 Identify the integration scenario for SRM
 Customize the PDF History Log
 Understand the requirements for enabling Supplier Self Service
 Configure the Return to Vendor Functionality
 Visualize the integration with OpenText Extended ECM
Special topics
The Configuration covered in this chapter is optional, but might be required
for specific customer needs.
Cha pter 12. Option al V IM C onfig urat ion
Return to Vendor
The Return to Vendor (RTV) function allows the customer to inform the
vendor by e-mail that an invoice is being returned. (The functionality then
terminates the DP workflow and sets the DP Document to a status of
Obsolete).
Figure 12-1: Return to Vendor Process Type
RTV e-mail The e-mail is generated based on a template that the VIM user selects. The
e-mail lists the reasons for the return and may contain additional comments.
It can also have the invoice image attached. VIM users may select several
different return reasons that are maintained in VIM customizing.
Figure 12-2: Return to Vendor interface
The following section highlights the necessary configuration steps:
RTV configuration 1. Configure SAP Connect and SMTP: RTV uses SAP Business
Communication Services (BCS), which in turn relies on SAPConnect for
sending the emails over SMTP protocol.
2. Assign the RTV Process Option to your Process Type: In VIM Baseline,
the new process option 2026 performs the RTV function.
Figure 12-3:
New Process Type for

Return to Vendor
3. Maintain the reasons that the invoice might be returned for. The return
reasons are maintained in the /OPT/VIM_RTVV table.
4. Maintain the e-mail template. VIM delivers a standard text,
/OPT/VIM_RTV_EXAMPLE, which can be viewed in transaction SO10
as a template for this e-mail.
Figure 12-4:
Template
5. The standard text would then be populated as in the next figure.
Figure 12-5:
Standard RTV text
6. Maintain the footer of the e-mail, via the template:

/OPT/VIM_RTV_SIGNATURE.
Figure 12-6:
Signature text
The signature text is made up of parameters, which are derived from the
SAP user data, as follows:
Figure 12-7:
Signature parameters
7. In order to fetch the e-mail, it must be maintained in the Vendor Master.

This can be displayed via transaction code BP, in the address tab.
Figure 12-8: E-mail destination for RTV message
If e-mail address is not in the Vendor Master, maintain the e-mail

determination user exit. This is done with a user exit, which is a function
module whose name must be maintained in the new Z-constant 005
RTV_GET_EMAIL in the /PTGWFI/Z_CONST table.
8. The message can be archived by maintaining the ArchiveLink

Document Type /OPT/HTM with a Document Class of HTM and a
Business Object of /OPT/V1001. (see Chapter 6, ArchiveLink
configuration of Document Types).
9. The Process Option for granting this functionality to a role is: 2026
Return to Vendor. It might be assigned as follows:
 Process Type 200, 203, 207, 412 for NPO_AP_PROC
 Process Type 201, 202, 203 for NPO_INDEXER
 Process Type 204 for NPO_DUP_CHCK
PDF Log
At various locations throughout VIM, a PDF log can be created. At the
beginning of the VIM process, it is possible to create PDFs of incoming
IDocs. At the end of the VIM process, it is possible to automatically create a
PDF history log.
Figure 12-9:
Example PDF history log
All comments that have been entered at any of the process or approval
steps are included in the PDF history log file.
The PDF history log file is archived and linked to the DP document and its
SAP invoice.
If any issues occur during the creation of the PDF history log, a log
message is written to the application log for object /OPT/VIM with
subobject DP.
To create a log, a profile must be created and that profile must be assigned
to a VIM process step. In the previous example, the following parameters
are delivered with Baseline:
 Profile - HISTORY
 VIM process step - VIM process is finished
Logs Logs are created in the VIM IMG /n/OPT/SPRO, then navigate to Vendor
Invoice Management > Cross Component Configuration > PDF Log >
Maintain Customizing Profiles.
Profiles Profiles are assigned to VIM process steps in the VIM IMG /n/OPT/SPRO,
then navigate to: Vendor Invoice Management -> Cross Component
Configuration -> PDF Log > Maintain Customizing Profiles.
Incoming IDocs A profile is delivered for PDF creation of incoming IDoc data.There is now
the opportunity to convert incoming IDocs into PDF files. The data is
mapped from the IDoc into the PDF document and creation can be
activated via the Business Center Inbound Configuration.
Figure 12-10:
PDF Log Profile for an

incoming IDoc
Extended ECM The VIM integration with Extended ECM (xECM) allows for the direct
display of xECM workspaces in VIM screens. There are three different
places in VIM where an xECM plug-in can be integrated:
 VIM Workplace
 VIM Indexing Screen
 VIM Analytics
Extended ECM for SAP Solutions can also be integrated into VIM Analytics
as a custom button that opens a separate window.
The following figure shows an xECM Business Workspace for Vendor

related data, launched from the VIM Workplace.
Figure 12-11: xECM Vendor Workspace in VIM Workplace
xECM integration In order to use the xECM integration capabilities the customer must ensure
prerequisites that they have:
 Vendor Invoice Management 7.0 SP5 or
 Vendor Invoice Management 7.5 SP1
 Extended ECM 10.5 SP1
xECM Baseline delivery Baseline delivery for this integration consists of:
 Example implementation for Vendor Workspaces
 Plugin for Indexing screen
 Plugin for VIM Workplace
 Button for VIM Analytics (7.0)
 Button for VIM Analytics (7.5)
 Plugin for VIM Analytics (7.5)
Customizing for this scenario consists of defining plug ins and

respective plug in framework configuration. Please consult the
VIM 16.3.1 Configuration Guide for detailed instructions.
Supplier Self Service Supplier Self Service a web interface that enables suppliers to keep track of
their invoices’ status. It also shows additional information such as payment
status and SAP documents linked to the invoice (for example Purchase
Order number, Delivery Note number).
The architecture of the Supplier Self Service functionality is shown next.
Figure 12-12: Self service architecture
Supplier Self Service is delivered as either a Fiori App or a lean variant. The
Fiori app allows for user-based access in contrast to the lean variant which
allows for anonymous access to search for invoices via certain criteria.
Fiori App Multiple Fiori apps are delivered for self service, user registration and
accountant access are provided.
Figure 12-13: Fiori: SSS app
Lean variant The lean variant of Supplier Self Service can be deployed in a HANA Cloud
deployment or On-premise.
Figure 12-14:Self service Lean variant
Supplier Relationship SAP’s SRM module can also be integrated with OpenText’s VIM
Management (SRM) component. The supported scenarios are:
 Missing Goods Receipt
 Quantity Discrepancy
 Price Discrepancy
Features Some of the integration features between VIM and SRM are as follows:
 Configurable E-mail - With the OpenText configurable e-mail
infrastructure, it is possible to compose the e-mail body and pass
attributes of a document without programming.
 Configurable URL - It is possible to configure the URL which will be sent
out to the SRM user.
 Configurable delay time for quantity and price block - It is possible to
configure the delay time for quantity and price blocks. After the delay
the work item will be routed to a designated agent
 Determination of the SRM purchase order is configurable.
 Determination of the recipient for e-mail is configurable - In the case of
the missing goods receipt scenario, it is possible to configure the
number of retry attempts that will be made to check for goods receipt
before sending the item to the designated agent.
Configuration tasks All SRM configuration is done from the /OPT/SPRO menu under Vendor
Invoice Management -> PO Based Invoice Configuration -> SRM
Integration.
Figure 12-15:
SRM integration
PO Status Possible SRM Purchase Order statuses are maintained in this step. If
necessary check field "STATU" in table EKKO (e. g. TA: SE16) for
appropriate statuses, if necessary add them separated by a semicolon.
Figure 12-16:
Configuration of PO
statuses
Missing Goods Receipt The Missing Goods Receipt scenario will be covered in this chapter. Detail
scenario on configuration of the other two scenarios is contained in the VIM 16.3.1
Configuration Guide.
Process Type SRM Block process type will be maintained here. This process type will be
maintenance used to determine the Mail configuration ID and Receiver's e-mail finding
Function module. The Default Baseline Value is 162. The constant is used
to determine different attributes.
Verify that the following fields are maintained for the SRM process type:
 Workflow Type - SRM System Integration
 Max Retry Counter - Maximum number of retries to send the e-mail for
one PO
 Retry Time (Minutes) - The e-mail will be sent again after the time
internally maintained here if no Goods Receipt is posted meanwhile.
For each time, the counter is incremented by 1.
 Mail Config ID - Function Module for Receiver E-mail, for example
/OPT/S_GET_SRM_USER_EMAIL_ID
 Function Module to send e-mail - /OPT/S_DP_EMAIL_NOTIFICATION
Send an e-mail VIM Baseline contains the option ID 2740 which will enable the AP
Processor to send an e-mail to the SRM user. The e-mail text based on the
mail configuration ID must be maintained in the process option. In
configuring the e-mail, the recipient is determined dynamically and the e-
mail contents are editable.
Figure 12-17: General SRM e-mail format
Figure 12-18: Generated e-mail sample
SRM Scenario Type SRM Scenario types will be maintained here. The default scenario is
"EXTENDED_CLASSIC". This is configured in the WebFlow Constant
Table. The Constant is SRM_Scenario_Type.
VIM Workplace The VIM Workplace is extensible according to the customer’s needs. to
provide flexibility, several templates have been provided for function module
enhancements. The following list gives an overview of all available exit
function module templates that can be used to implement extensions or
custom enhancements for the VIM Workplace.
 /OPT/C_PMC_EXIT_TEMPL_BUTTON
– Purpose: Allows to skip the creation of an action button during
runtime.
 /OPT/C_PMC_EXIT_TEMPL_ICON
– Purpose: Allows to influence the icon properties during runtime.
 /OPT/C_PMC_EXIT_TEMPL_FLD_STAT
– Purpose: Allows to influence the properties of an output list field
during runtime.
 /OPT/C_PMC_EXIT_TEMPL_PRE_ACT
– Purpose: Runs before the action logic of a button or icon action is
executed. In the case of multiple backends, it is always called once
for all selected work items on the local system and a second time
for all corresponding work items of each backend system.
 /OPT/C_PMC_EXIT_TEMPL_ACT_EXE
– Purpose: Executes the action logic of a button or an icon action.
 /OPT/C_PMC_EXIT_TEMPL_PROC_RFC
– Purpose: Executes the data selection directly on each involved
backend system.
 /OPT/C_PMC_EXIT_TEMPL_DISCOUNT
– Purpose: Controls the behavior of the discount light in the output
list, for example when should it switch to red, yellow or green.
Business Warehouse Content

OpenText delivers pre-configured reporting and analysis scenarios for SAP
NetWeaver BW that are based on consistent metadata. The VIM BW
content provides the relevant BW objects from extraction to analysis, in an
understandable, consistent model. The VIM BW content therefore provides
an efficient and cost-effective way to implement SAP NetWeaver BW for a
VIM installation where BW is the preferred system for analytical reporting.
Beginning with VIM 7.5, BW content is delivered for SAP NetWeaver BW

7.0, SAP NetWeaver BW 7.3, and OLTP systems with ECC 6.0.
Technically, the VIM BW content comprises DataSources together with the
following components:
 Extractors
 InfoObjects
 DataStore Objects (DSO)
 InfoCubes
 MultiProviders
 BEx Query Variables
 Transformations
 InfoPackages
 DataTransfer Processes (DTP)
 Process Chains
The configuration instructions for installing and activating this

content in the customer’s BW system is covered in detail in the
VIM for SAP 16.3.1 Solutions Configuration Guide.
Integration with the SAP Adapter for the Ariba Network

Ariba is an e-commerce solution, which allows the customer to collaborate
with their suppliers in an electronic network. For those customers who
already employ the Ariba network, there is a streamlined way to integrate
the Ariba Network with the Vendor Invoice Management Solution.
Integration with VIM can be integrated with the Ariba Network from the buyer perspective. In
Vendor Invoice this scenario:
Management  Suppliers create invoices within the Ariba Network
 Invoices are sent to the SAP system of the buyer
 The buyer processes all incoming invoices within VIM
Besides local invoice channels (e-mail, or scan, or OCR), the buyer is

connected with the Ariba Network and receives invoices of his suppliers
from this channel.
Advantages of VIM With the standard SAP/Ariba integration, invoices are posted or parked
integration automatically in the SAP System. If the customer integrated VIM, they have
the opportunity to catch any invoice exceptions, handle them via the DP
workflow, and then to process them to completion.
Ariba can be integrated in two different ways.
PI Adapter scenario In the first scenario, an integration with the SAP NetWeaver Process
Integration (PI) in combination with the Ariba PI adapter is possible. In this
scenario, invoices arrive in IDoc format (INVOIC02) to the SAP ERP system
of the buyer.
Figure 12-19: The Ariba Network Integrated with VIM via the PI Adapter
SAP Add-on Ariba In the second scenario, it is possible to connect Ariba with the new SAP
Network Integration for add-on Ariba Network Integration for SAP. Technically, the invoices are
SAP sent in cXML format.
Figure 12-20: The Ariba Network Integrated with VIM via the SAP add-on
For this second scenario, OpenText delivers a significant amount of

baseline configuration for getting the customer started with this integration.
Both scenarios allow for the inbound processing of the invoice

data and outbound update of the status of the invoice to the Ariba
Network. Additional details for configuring either of these
scenarios can be found in the VIM 16.3.1 Configuration Guide
Chapter 23.
Exercise: Viewing the PDF Log Profiles
Change the PDF Log Customizing Profile

2. Navigate to Vendor Invoice Management -> Cross Component
Configuration -> PDF Log -> Maintain Customizing Profiles.
Summary
In this chapter we covered configuration which is optional to the customer. It
can be leveraged to integrate VIM with BW, SRM, and the Ariba network
thereby increasing the number of scenarios where the company’s personnel
can collaborate via the VIM tool. This chapter also introduced ways that the
customer can put their own thumb print on the VIM Workplace. Finally, the
new capabilities for Supplier Self Service (SSS) and for generating a PDF
History Log was reviewed.
Cha pter 13. Admin istra tion and t roub leshoot ing
13. Administration and troubleshooting
Objectives

 Explain new jobs and tools for the SAP Administrator
 Identify the main tasks in VIM Administration
 Identify new procedures for the Year End and Month End AP Processes
 Explain some common issue resolution strategies for VIM
VIM administration
In general the job of administering the VIM system will fall under the
responsibility of the SAP Basis team. This team should be made aware of
the additional responsibilities they will assume once VIM is installed. The
tasks break down into the following categories:
 Scheduling jobs
 Monthly and Year End reporting
 Bulk change of posting date for DP invoices
 Support pack and patch maintenance
 Standard SAP Workflow tasks
Figure 13-1:
Administration areas in
VIM
Cha pter 13. Ad mi nistr ation and t rou bleshoot ing
General maintenance tasks

This set of tasks includes the scheduling of periodic jobs that run to
maintain system health. These jobs are provided with the OpenText
Baseline installation and can be scheduled via the familiar SM36 job
interface in SAP. The jobs that are required will vary by implementation and
customer requirements. This set is not meant to be comprehensive or
mandatory, but rather a list of commonly used programs.
SAP Program Area Description Suggested Parameters

Frequency
RM08RELEASE Workflow To release blocks on Once per day Automatic

MM documents and As currently Release
payment blocks on FI scheduled by the
document (equivalent customer
to MRBR transaction)
PTGWFI/ To handle actions Once per day N/A if run daily;

R_LIX_CLEANUP_WFS_NEW taken outside of Run after Otherwise
workflow which can RM08RELEASE Invoice
clear a blocked Creation Date
invoice. This program Range
removes associated
redundant workitems
and completes
workflows
/PTGWFI/ To handle actions Once per day N/A if run daily;

R_PIR_CLEANUP_WFS taken outside of after Otherwise
workflow which can /PTGWFI/ Invoice
clear a parked R_LIX_CLEANU Creation Date
invoice. This job P_WFS Range
removes associated completes
redundant workitems
and completes
workflows
/ORS/ To release invoice Every 30 minutes N/A

000007_LOCK_CLEANUP locks as set by
approval W/F
/OPT/VIM_R1A_REMINDER To send out VIM Once per day Select:

reminder e-mails for Background
overdue items Mode
Table: /OPT/
T852 sets the
number of
grace days
RSWWERRE Restarts workitems As defined by the

that are in error; This Workflow
reduces workflow configuration
administration
SAP Program Area Description Suggested Parameters

Frequency
/OPT/ LIV Header Level Twice a day or N/A

VIM_TRIGGER_HEADER_WF Workflow Triggering more depending
on the
requirements
/OPT/DR_BR_WAIT Reruns the process 1/day

types that have been
set into a wait step
/OPT/ If the maximum wait Every 4 hours

CR_RERUN_RULES_JOB time is configured for
some DP Process
Types
(exceptions), this
program will complete
the waiting work items
for documents
with those DP
Process Types
SAP AP processes
The OpenText Vendor Invoice Management year end procedures dictate a
procedure for allowing parked invoice processing to be carried over to the
next fiscal year. The year end procedures for parked invoice processing
must be performed at the fiscal year end.
As part of a company’s fiscal year end preparations, please ensure that a

copy of the Parked Document Processing guide is on hand. If the customer
requires a copy of the guide, please contact OpenText Customer Support at
support@opentext.com.
The year end processing for parked invoices includes running the year end
programs provided by OpenText. These programs were delivered as part
of the original implementation and are already in the VIM system.
Customers should install any year end program patches prior to

commencing any fiscal year end activities.
OpenText recommends that a customer runs the year end procedures for
parked invoice processing in a test environment before attempting them in
their production environment.
Fiscal year end procedures for parked invoice processing should only be
run in the production environment after the last posting period in the
previous fiscal year is closed and when no user is trying to create or
process parked invoices in the system.
Furthermore, changing the posting date of a parked invoice so that it carries

over to the next fiscal year should only be done by running the year end
programs.
Manually changing the posting date of an invoice so that it falls into the next
fiscal year during processing through a workflow or outside a workflow
process will have adverse effects on the existing workflows that are
associated with that invoice and should not be performed.
OpenText also provides a program and corresponding transaction code to

perform a mass update to the posting date in DP documents. With the
introduction of DP-based invoice approvals in VIM 5.2, DP documents now
have longer processing cycles. Customers may encounter a situation where
changing the fiscal year or fiscal month may result in them having to update
the posting date for many DP documents to move them into the new posting
period.
Mass change of This program can be used for the following:

Posting Date utility  Bulk change of posting date for DP invoices to avoid any issues with
closing of periods
 All invoices except for those that already have an existing SAP
document. Further, no invoices with status 'Deleted', 'Obsolete' nor
'Cancelled' can be updated.
 Updates to VIM Analytics (the report writes an entry in the process logs)
Figure 13-2:
Mass change for Posting

Date program
Step by step In order to use the program, proceed in the following manner:
1. Type the /OPT/DP_POST_DT_UPD transaction code into the SAP
command field.
2. Press Enter.
3. Fill in the following fields on the selection screen, in the Settings
section.
 New Posting Date - This field is mandatory.
 Test mode (display invoices) - This check box is selected by default.
The invoices resulting from the search are only displayed (no
change is effectuated).
 Exclude empty posting dates - Select this check box only in special
cases where the posting date is not filled in and should not be
updated.
4. In the Document options section you find standard search criteria for
DP invoices.
5. To execute, un-check the Test mode field and click on the Execute icon.
OpenText recommends doing tests of the report on a test system.

OpenText also recommends running the report when users are not
working on the system as there might be conflicts when objects are being
locked and this might result in data inconsistencies.
Month End reporting: The month end report is a tool that is used to change the posting date for
parked invoices parked PO and Non PO documents that need changing due to a closing
period date. The following transaction codes can be used respectively:
 /OPT/VIM_MEND_PO
 /OPT/VIM_MEND_NPO
In both cases, the report can be executed in either an online mode or

scheduled as a batch job. In the batch mode, all the documents that match
the selection criteria will be processed automatically without user
intervention.
Year End reporting: If a document is parked in a particular fiscal year, but the processing of the
parked invoices document is not completed in that year. It is carried over to the next year. If
the posting date has to be changed, the MIR4 transaction must be used to
post it in the new posting period (FBV4 for Non PO invoices).
At this stage, the runtime workflow instance based on this parked document
will be rendered unusable as the object key of the parked document is now
changed. All of the OpenText application tables will be out of sync, as
well.Therefore, the best option is to prevent the entire scenario: Ensure that
all parked documents created in a particular fiscal year get posted in the
same year.
If the business needs mandates that the parked documents have to be

carried over to the next year, implement the solution according to the type of
invoice.
Please see the VIM 16.3.1 Administration Guide for all the
required steps in PO and Non PO Year End Reporting Scenarios.
The transaction codes that will be used to invoke the OpenText programs
are:
 /OPT/VIM_YEND_PO
 /OPT/VIM_YEND_NPO
 The year end procedure will also include using the month end
programs, this is described in detail in the Administration Guide.
Testing OpenText highly recommends comprehensive testing of the year end

procedure before it is run in the Production environment. The following are
suggestions for this testing:
 Simulate various scenarios.
 Run the programs in the order mentioned.
 Ensure the image links are transferred correctly.
 Ensure the logs and reports show the correct information.
 Ensure the comments are showing up properly.
 Run the programs in dialog mode to investigate any errors.
 Keep the log for the program executions so that you will have a record
of what invoices were changed in case something goes wrong.
Technical upkeep of the software

Every product version component has a patch history list and each patch
has a pre-requisite as detailed in the patch note. In some cases, pre-
requisites span across product components. Patch imports are not
mandatory and are subject to specific customer’s functional requirements.
The OpenText Knowledge Center (https://knowledge.opentext.com) is

OpenText's corporate extranet and primary site for technical support. The
Knowledge Center is the official source for the following:
 Product downloads, patches, and documentation including Release
Notes.
 Discussion forums, Online Communities, and the Knowledge Base.
 OpenText Developer Network (OTDN), which includes developer
documentation and programming samples for OpenText products.
Workflow administration
There are eight workflow templates for VIM processes, OpenText
recommends that the Administrator monitor the VIM Workflows on a regular
basis. This will ensure that problems are detected quickly and handled in a
timely manner. SAP transaction code SWI1 can be used to monitor the
following workflows:
1. WS00275269 – Document Process Workflow (from receiving the
scanned invoice info until the invoice is parked/posted or the document
is marked as obsolete or duplicates). (WS00275255 ≤ 5.1.6)
2. WS00275260 – Parked PO invoice workflow (from the time a PO
invoice is parked until the invoice is posted or deleted). This workflow is
only used in releases prior to 16.3.1.
3. WS00275264 – Blocked PO invoice line level workflow (from the time a
PO invoice is blocked for payment until it is released or cancelled)
4. WS00275266 – Blocked PO invoice header level action workflow (from
the time that a blocked invoice is authorized for header level action until
the action is completed or when AP sends back).
5. WS00275254 – Non-PO parked invoice workflow (from the time a non-
PO invoice is parked until the invoice is posted or deleted). This
workflow is only used in releases prior to 16.3.1.
6. WS00275252 – Web approval of parked invoice (from the time an
invoice is sent for web approval action until approval is completed or
invoice is fully rejected).
Linking Events for the SAP events are trigger points for VIM workflows. For example, when a
Workflows logistic invoice is posted, SAP ERP generates the event POSTED from the
business object BUS2081. The event is linked to trigger the VIM workflow
solution for blocked invoices if the invoice is blocked. Event linkages must
be created manually since VIM 6.0.
Object Type Event/Receiver Receiver Function Module/ Usage Comments

Type Check Function Module
FIPP Deleted SWW_WI_CREATE_VIA_EVENT Invoice Approval (IAP)

TS00275270
FIPP Posted SWW_WI_CREATE_VIA_EVENT IAP

TS00275270
BUS2081 Deleted SWW_WI_CREATE_VIA_EVENT IAP

TS00275270
BUS2081 Posted SWW_WI_CREATE_VIA_EVENT IAP

TS00275270
BUS2081 POSTED /OPT/BL_PO_BLK_RECEIVER Invoice

WS00275264 /OPT/ Exception (IE)
BL_PO_CHECK_ROLL_OUT
Object Type Event/Receiver Receiver Function Module/ Usage Comments

Type Check Function Module
/OPT/FIPP ZWFI_CREATED /OPT/BL_NPO_PRK_RECEIVER IE

WS00275254 /PTGWFI/PIR_F_CHECKFM
/OPT/B2081 ZWFI_PARKED /OPT/BL_PO_PRK_RECEIVER IE

WS00275260 /PTGWFI/PRK_M_CHECKFM
FIPP DELETED /OPT/VIM_RPT_RECEIVER_FM VIM Analytics

(VAN)
FIPP POSTED /OPT/VIM_RPT_RECEIVER_FM VAN
BUS2081 DELETED /OPT/ VAN

VIM_RPT_PO_INV_RECEIVER
BUS2081 POSTED /OPT/ VAN

VIM_RPT_PO_INV_RECEIVER May be used in
special
situations.
Should be
inactive in
standard
configuration.
BUS2081 RELEASED /OPT/ VAN

BUS2081 CANCELLED /OPT/ VAN

/ORS/INVAP POSTED /OPT/AAFS_POST_RECEIVER Posted

Approval
BUS2081 POSTED WS00275264 or EMPTY In transaction SWETYPV, make

sure that only one of these event
linkages is
activated.
• If you use your own blocking
workflow, activate only the event
linkage with
empty Receiver Type. This event
linkage ensures that VAN will be
correctly
updated.
• If you use the standard blocking
workflow template, activate only
the event linkage with Receiver
Type WS00275264. This event
linkage updates VAN
with the same function module as
the other event linkage but it also
starts
the blocking workflow.
How to enable the VIM In order to create these linkages, type the SWE2 transaction code into the
Workflows SAP command field and press Enter. Choose the New Entries button and
create all linkages as shown above.
Workflow activities Most companies with a large Workflow footprint employ a Workflow
Administrator. (In the event there is not a Workflow Administrator, these
tasks usually fall under the Basis Team).That role would also need to
perform the following:
 Role Maintenance
 User ID changes
 Role Error investigation and resolution
 Chart of Authority (approvals) maintenance
 SAP Inbox substitutes setup
 Reassigning workitems
 Approval Items: Transaction Code: /ORS/UMREASSIGNED
 Forwarding items
 Releasing locked objects
 Approval Items: Transaction Code: /ORS/RELEASE_LOCK
 Table size monitoring and archiving
Workflow Transaction Some transaction codes which are helpful for the Workflow Administrator
Codes are shown in the following table:
Task Access in SAP
Review workitems with error status SWI1
Where used list for a task SWI11
Task Profile – Authorizations SWI13
Workflow Diagnosis SWUD
Transaction RFC SWU2
Restart WF after error correction SWPR
Process workitems as administrator SWIA
Workload by user SWI5
Access Workflow log for a specific user SWI6
Create substitute user (user side) SAP Business Workplace
Run other standard SAP reports Tools > Business Workflow >
Development > Reporting
Automatic Workflow Customizing SWU3
Display Workflow Event Trace SWEL
Task Access in SAP
Synchronize Runtime Buffer SWU_OBUF
Diagnosis of Work Items Containing Errors SWI2_DIAG
Maintain Business Object SWO1
Workflow Builder SWDD
SAP Business Workflow SBWP
Create/Maintain Organizational Structure PPOC/PPOM
Create/Modify Structure (Work Center A008) PPSC/PPSM
Create/Maintain Tasks PFTS
VIM tables for Administrators

For a person administering the VIM System, there are some relevant data
tables to be aware of. They are categorized and listed here.
 DP Workflow
– Indexing Tables: /OPT/VIM_1HEAD, /OPT/VIM_1ITEM
– BDC Error Log: /OPT/VIM_1BDCLOG
– DP Log: /OPT/VIM_1LOG
 PO Blocked Workflow
– Monitor Table: /PTGWFI/F_LIXMTR
 PO Parked Workflow
– Monitor Table: /PTGWFI/M_PRKMTR
 Non-PO Parked Workflow
– Monitor Table: /PTGWFI/F_PIRMTR
 Approval Workflow
– Monitor Table: /ORS/STACK_VIEW
– Chart of Authority: /OPT/BL_APPCOA, /OPT/BL_AP_CODER,
/OPT/BL_T401, /OPT/BL_AP_CONF
– Usermap: /ORS/USERMAP
 Role Resolution
– Role Table: /PTGWFI/W_ROLE
– Org. Table: /PTGWFI/W_ORG
Key Determination: /PTGWFI/Z_KEYDET, /PTGWFI/Z_KEYRNG,

/PTGWFI/Z_KEYVAL
 General Tables
– Constant Table: /PTGWFI/Z_CONST
– Options: /PTGWFI/F_POT, /PTGWFI/F_OST
– Parking/Blocking: /PTGWFI/F_BCT, /PTGWFI/F_PRKRSN,
/PTGWFI/M_PRKRSN
Troubleshooting
This section will deal with commonly faced errors when operating VIM. The
suggested approach to understanding or resolving the issue will be
presented. However, this should only be used as a guide and not a
replacement for the Configuration and Administration Guides that are
provided for the VIM for SAP Solutions software.
Role resolution Workflow is a constant thread of tasks that are linked together via the
workflow tasks and the agents who execute them. If Workflow ends up in an
Error Status, it might be that agent resolution (or the workflow determination
of who is to execute a given task) might have failed. The suggested steps to
follow are:
Step by step 1. Type transaction code SWI1 into the SAP command field.
2. Press Enter.
3. Take note of any Error workflows by populating the following information
in the selection screen:
 Type: F
 Status: Error
 Task: WS00275270 (version 16.3), WS00275271(version 16.3),
WS00275269 (WS00275255 ≤ 5.1.6), WS00275260,
WS00275254, WS00275252, WS00275264, WS00275266.
4. Validate that this is a role resolution error. (A typical error is depicted in
the next figure.)
Figure 13-3:
Role Resolution error
5. Display the container contents of the error workitem.

6. Read the element “Actor” or “Next Role” to determine the role causing
the error. Fix role logic issue.
7. Use the Role test transaction code:/OPT/VIM_ROLETES to find and fix
the issue.
8. Restart the workflow using Transaction Code SWPR.
Workitem Role flow In this type of error, a workitem ends up in the inbox of an unexpected
agent. A workitem should flow according to the design initiated in the Swim
lane Diagram workshops. If conditions were configured in VIM to be
determined dynamically, then it is beneficial to use transaction code SWI1
to display the step by step flows and roles.
Occasionally, a workitem is sent to the DEFAULT or FAIL_SAFE groups

that are specified in the role definition. This is subject to Key Determination
failing. To investigate if this is the root cause of the error, use the
transaction code /OPT/VIM_ROLETEST. This transaction codes selection
screen is depicted in the next figure.
Figure 13-4:
Role Test utility
Authorizations User Authorization issues manifest themselves in several ways:

 A user does not see specific options in the Dashboard
 A user can’t display images
 A user can’t execute a workitem. (This is more prevalent for approval
workitems.)
 A user can’t display user IDs from an HR object.
 A user can’t execute transaction codes associated with options.
In order to investigate authorization issues, the user must also have

adequate authorizations. Some typical investigation points are not open to
many users.
A very typical suggestion for a user that is having trouble is to have them
utilize transaction code SU53. This is used by a Security Consultant to
determine the missing authorization.
To use SU53, the transaction should be invoked directly after the user has
had the authorization issue.
Invoice Approvals Some of the common issues with the Invoice Approval Process and
suggested courses of action are presented in the below table.
Error Symptoms Transaction Code for Resolution
Locked invoice object Invoice is locked for processing Use /ORS/RELEASE_LOCK to unlock the
invoice.
Approval not open User can not execute the User may not be the intended approver or
approval of an invoice. have been setup as an official substitute
Use /ORS/MAIN_SUBS to confirm and fix.
Recall necessary User needs to retrieve approval Use /ORS/UMREASSIGNED to recall or

item from approver. reassign the approval item.
Workflow triggering If there is an issue that seems to be preventing an SAP workflow from
triggering properly, the following should be evaluated.
1. Are Document Type and Plant filtering configured properly?

2. Is there an issue with the WF-BATCH user ID? (Use Transaction Code
SWU3 to confirm.)
3. Is it a Business Transaction Event (BTE) or Business Add-In (BADI)
issue? To evaluate this, the user can use debug mode. Set a break-
point in the Event or in the function module that is called by the BADI to
see if the logic is processing as expected.
4. Is it an Event Linkage Issue? Use Transaction Code SWEL to ensure
the event was published and the receiver function module is being
executed correctly. Debug mode can also be employed here.
EnterpriseScan If after archiving, a document reappears in EnterpriseScan and an error

message is displayed, then the user should check for the relevant logfiles
on the scanning station. The name of the file is IXClient.log, DP.log.
Some common reasons for failure are:

 The DocumentPipeline is not running.
– Check this with the spawncmd command.
 There is a problem with the DocumentPipeline directory on the
scanning station. It might be non existent, wrongly configured, filled up,
or have missing permissions.
– Check the DPDIR parameter in the registry.
– Visit and examine the DP directory on the operating system level.
If sending a document to the Archive ends with an error message that says
the DS host for archive cannot be found to get the Document ID then
EnterpriseScan could not determine which Archive Server to send the
document to. The user should check the relevant log files. On the scanning
station, the file name is IXClient.log. On the Archive Server, the log file is
admSrv.log.
Some common reasons for failure are:

 The Archive Server is not running or unavailable.
– Check the availability of Archive Server
 The configuration on the client or server side is wrong.
– Check the following:
• Which Archive Server is EnterpriseScan linked to?
• Does the target logical archive exist on the Archive Server
side?
• If the target logical archive is hosted by a different Archive
Server, do both servers have a “known servers” relationship?
Archive Center log Some of the log files that can be consulted for understanding issues with
files Archive Server are listed here:
Area Files
Document retrieval IXClient.log (on retrieval client)

RC1.log
dscache1/2.log
jbd_trace.log
Purging disk buffer dsHdskRm.log

jbd_trace.log
Write to VI pool (Single File – dsGs.log

Centera)
Write to FS pool (buffered hard dsHdsk.log

disk)
Burning ISO images / writing to dsCD.log / dsWORM.log

IXW medias jbd_trace.log
Backing up IXW medias bkupDS.log

bkupSrvr.log
bkWorm.log
jbd_trace.log
Finalizing IXW medias dsFinalize.log

jsd.log
jbd_trace.log
The Application Log The application log, which is accessed via transaction code SLG1 can be
used to analyze any issues in Document Processing. The log point helps us
to locate the issue easily. Log points are configured through transaction
code /OPT/IT_LOG_PNTV. Log levels can be maintained through
transaction code /OPT/VIM_LOG_CFG.
OCR related issues If there is an issue with executing the extraction of an invoice (i.e. the
Document remains in status 01 and the application does not pick it up), then
the following can be attempted to understand the issue:
1. Run TraceViewer for detailed error message.
2. Check HotSpot Configuration to see if the service is not running or the
Hotspot is switched off.
3. Check if the Workflow task WS00275270 has not been assigned to the
archive document type.
If there is an issue with the actual extraction results (i.e. fields are empty
and an exception is raised in SAP) then the following can be attempted to
resolve the issue:
1. Check if fields and corresponding values are being transferred to SAP
with transaction codes SE16 or SE16N. Check table
/OPT/VIM_1EXT_H.
2. Check if the the wrong documents were scanned (i.e. Italian documents
were scanned for a US application).
If the Recognition Server fails when processing an incoming document

image, then the corresponding entry in Business Center inbound
administration will have a status of 87, which denotes: Error in extraction.
If the Validation Client fails during user review, then the corresponding entry
in Business Center inbound administration will have a status of 89, which
denotes: Error in validation.
The application log of a job with error status shows the more specific BCC
error code. Some examples follow:
 87 - recognition errors
 001 - recognition service broken
 002 - empty image
 005- archive not accessible
 89 - validation errors
 003 - unknown image format
Additional application log information can be found in the

OpenText Business Capture Center for SAP Solutions -
Administration Guide in OpenText Support.
OpenText Support
There are many avenues for obtaining support for VIM related issues within
OpenText.
The Customer Portal Here a customer can:

 Open a ticket
 Knowledge base area
 Discussion area
 Enhancement request area
OpenText Support Portal http://www.opentext.com, click on Support
Customers should contact OpenText support before installing a new patch

to the VIM system. Detailed step by step instructions should be referred to
and followed in the Administration Guide that is provided by OpenText.
Figure 13-5: OpenText Support
Summary
Troubleshooting the VIM process is, in essence, a series of troubleshooting
all of the communication points. Communication between servers, between
processes, and between workflow agents are all common places for break
down in the flow. Use this guide as a place to start for troubleshooting and
use other OpenText resources if it proves insufficient.The administration
effort for a customer implementation of VIM is minimal but is not
insignificant. Plans should be made in advance to handle ongoing
administration duties as well as the month end and year end business tasks
that arise due to VIM.

3-2102-163-00 - Vendor Invoice Management For SAP Solutions Administration 16.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3-2102-163-00 - Vendor Invoice Management For SAP Solutions Administration 16.3

Uploaded by

Copyright:

Available Formats

Vendor Invoice Management for SAP

Solutions Administration 16.3

OpenText Suite for SAP Solutions

Comments or suggestions about this manual can be sent to LearningContentDev@opentext.com.

OpenText Learning Services

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion iii

1. Vendor Invoice Management overview

2. Landscape and Architecture

3. Installation and upgrade to VIM 16.3 SP1

4. SAP ArchiveLink Customizing for VIM

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion v

5. VIM Role Framework

6. Business Center Inbound Configuration

8. Invoice Processing configuration

9. Invoice approval configuration

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion vii

10. Customizing Business Center Capture

11. The Fiori Task App

12. Optional VIM Configuration

13. Administration and troubleshooting

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion ix

This workbook uses the following conventions:

Convention What it is Used For

Italic Italics are used for Workshops and Exercises.

Monospace Monospaced text is used to represent sample code.

Bold In instruction steps, indicates the action to be taken. In text it

<> Angle brackets (<>) represent an element of syntax you must

This icon represents an optional or advanced lesson symbol where

This icon represents a note that supplies additional information.

This icon represents a tip that supplies additional shortcut

This icon represents a collection of Tricks, Tips, and Traps that is

This icon represents a caution that supplies warning information.

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion xi

1. Vendor Invoice Management overview

On completion of this section, participants should be able to:

OpenText Vendor Invoice Management for SAP Solutions

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pa ge 1- 1

Figure 1-1: AP business process flow without VIM

Various users may keep copies of invoices and information requests

Correspondence between the involved parties must be captured and

Figure 1-2: Typical statistics: AP challenges

Manual keying of invoice data and resolution efforts involve time-consuming

AP staff resources can spend a large amount of time addressing these

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pa ge 1- 3

Figure 1-3: Parties involved in invoice processing

Within these different areas, there are different organizational challenges

 Business Partners - Supplier’s View

What is Vendor Invoice Management for SAP Solutions by OpenText?

VIM is a prepackaged composite application that acts as an add-on to the

The objectives in a VIM implementation are for invoices to be processed

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pa ge 1- 5

A high-level look at this new digitally-focused processing is pictured next.

Figure 1-4: The invoice process with VIM

Figure 1-5: OpenText Suite for SAP Solutions

VIM is a packaged business solution that is developed and tested in

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pa ge 1- 7

For this course, we refer to it exclusively as VIM as sold by OpenText. To

Figure 1-6: VIM/SAP version matrix

This course uses VIM Version 16.3 SP1 in conjunction with

Figure 1-7: Business Center/SAP version matrix

Ven dor Invoice M anagement fo r S AP So lution s Admin istra tion Pa ge 1- 9

VIM’s Classic Mode is made up of components that provide different pieces

Figure 1-8: Components of VIM 16.3 Classic Mode