OpenText Vendor Invoice Management For SAP Solutions 20.4 SPS1 - Scenario Guide For Invoice Solution English (VIM200401-CCS-En-04)

OpenText™ Vendor Invoice Management
for SAP® Solutions
Scenario Guide for Invoice Solution
This guide describes functional and technical scenarios of the

Invoice Solution of Vendor Invoice Management.
VIM200401-CCS-EN-04
OpenText™ Vendor Invoice Management for SAP® Solutions
Scenario Guide for Invoice Solution
VIM200401-CCS-EN-04
Rev.: 2021-Aug-27
This documentation has been created for OpenText™ Vendor Invoice Management for SAP® Solutions 20.4 SPS1.
It is also valid for subsequent software releases unless OpenText has made newer documentation available with the product,
on an OpenText website, or by any other means.
Open Text Corporation
275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1
Tel: +1-519-888-7111
Toll Free Canada/USA: 1-800-499-6544 International: +800-4996-5440
Fax: +1-519-888-0677
Support: https://support.opentext.com
For more information, visit https://www.opentext.com
Copyright © 2021 Open Text. All Rights Reserved.

Trademarks owned by Open Text.
One or more patents may cover this product. For more information, please visit https://www.opentext.com/patents.
Disclaimer
No Warranties and Limitation of Liability
Every effort has been made to ensure the accuracy of the features and techniques presented in this publication. However,
Open Text Corporation and its affiliates accept no responsibility and offer no warranty whether expressed or implied, for the
accuracy of this publication.
Table of Contents
1 About Vendor Invoice Management ........................................ 7
1.1 Architectural Overview ....................................................................... 9
1.2 About this document ........................................................................ 10
Part 1 Classic VIM - functional scenarios 13
2 General Data Protection Regulation (GDPR) ........................ 15
3 Processing invoices in VIM .................................................... 21

3.1 Standard invoice processing ............................................................ 21
3.2 Invoice processing with parked invoices ........................................... 35
4 Multiple backend system ........................................................ 37

4.1 Defining logical systems .................................................................. 38
4.2 Assigning clients to logical systems .................................................. 39
4.3 Maintaining RFC destinations .......................................................... 41
4.4 Working with the System Landscape Directory (SLD) ........................ 42
4.5 Implementing cross release multiple backend functionality ................. 47
4.6 Maintaining channels ....................................................................... 51
4.7 Maintaining Mapping IDs ................................................................. 51
4.8 Maintaining the system determination ............................................... 51
4.9 Working with ICC in a multiple backend system ................................ 53
5 Using the Inbound Configuration with a different

workflow ................................................................................... 55
5.1 Overview ........................................................................................ 55
5.2 Interfaces ....................................................................................... 56
5.3 Tables and structures ...................................................................... 60
5.4 Log points ....................................................................................... 61
5.5 Customizing VIM and Inbound Configuration ..................................... 62
6 Validating invoices in ICC or indexing in VIM? .................... 65

6.1 Some background about the tools .................................................... 66
6.2 Deciding which tool to use ............................................................... 66
6.3 Defining the validation determination ................................................ 67
7 Handling line items in ICC or VIM .......................................... 71

7.1 ICC line item recognition .................................................................. 72
7.2 Line item mapping ........................................................................... 73
7.3 Use case 1: Invoices matching PO - highly automated posting ........... 74
7.4 Use case 2: Invoices with planned or unplanned expenses ................ 75
7.5 Use Case 3: Invoices related to blanket orders .................................. 77
VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution iii

Table of Contents
7.6 Secure line item number input .......................................................... 78
8 Field references for ICC .......................................................... 81

8.1 Header fields .................................................................................. 81
8.2 Line item fields .............................................................................. 114
9 Field references for IES ........................................................ 123

9.1 Header fields ................................................................................ 123
9.2 Line item fields .............................................................................. 127
10 Processing electronic invoices ............................................ 131

10.1 Country specific notes ................................................................... 131
10.2 Integration with SAP Document Compliance ................................... 143
10.3 Configuration ................................................................................ 145
10.4 Quick start .................................................................................... 158
10.5 Generic Peppol/UBL mapping ........................................................ 162
10.6 Visualization of XML invoices ......................................................... 168
10.7 Known issues ............................................................................... 183
11 Configuring Public Sector Management ............................. 185

11.1 Routing documents with the route ID .............................................. 185
11.2 Line item fields relevant for PSM .................................................... 187
11.3 Derivation of accounting data ......................................................... 187
12 Scenarios for special countries ........................................... 189

12.1 Brazil ............................................................................................ 189
12.2 Canada ........................................................................................ 194
12.3 China ........................................................................................... 201
12.4 India ............................................................................................. 209
12.5 Northern Ireland ............................................................................ 214
12.6 Poland .......................................................................................... 216
12.7 Russia .......................................................................................... 220
12.8 Spain ........................................................................................... 223
12.9 Switzerland ................................................................................... 224
12.10 Thailand ....................................................................................... 228
13 Processing leasing invoices ................................................ 235
14 Translating VIM ...................................................................... 237

14.1 Roles and responsibilities .............................................................. 237
14.2 Prerequisites ................................................................................ 238
14.3 Setting up the environment ............................................................ 238
14.4 Translation ................................................................................... 272
14.5 Creating language packages or language transports ....................... 284
14.6 Importing languages and activating translation ................................ 288
iv OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

Table of Contents
14.7 Approval Portal translation ............................................................. 289

14.8 Supplementary language ............................................................... 295
14.9 Translating VIM Fiori apps ............................................................. 298
15 VIM Confirm Quantity and Price Fiori app: use cases ....... 301
15.1 Use case 1: Invoice with missing GR: requisitioner confirms GR -
no specialist required .................................................................... 302
15.2 Use case 2: Invoice with price discrepancy - specialist required for
PO change ................................................................................... 303
16 Posted invoice reversal with a new DP workflow start ...... 305
17 SAP S/4HANA embedded analytics ..................................... 309

17.1 Invoice Life Cycle analytics ............................................................ 309
18 Smart coding .......................................................................... 323

18.1 Training the models ....................................................................... 324
18.2 Smart coding button in the DP indexing screen ............................... 330
18.3 Testing a DP document with smart coding proposal ......................... 331
18.4 Confidence level calculation ........................................................... 331
19 Processing SAP Transportation Management invoices .... 333

19.1 Configuring the document type ....................................................... 334
Part 2 Classic VIM - technical scenarios 343
20 Adding new fields in ICC and VIM ........................................ 345

20.1 ICC .............................................................................................. 345
20.2 Standard VIM tables ...................................................................... 346
20.3 VIM Invoice Workplace .................................................................. 347
20.4 VIM indexing screen ...................................................................... 358
20.5 Notifications program .................................................................... 360
20.6 Invoice Approval ........................................................................... 360
20.7 VIM Analytics ................................................................................ 362
20.8 New VIM Analytics ABAP CDS views ............................................. 362
21 Using the metadata interface of the Inbound

Configuration ......................................................................... 369
21.1 Overview ...................................................................................... 369
21.2 Functional description .................................................................... 369
21.3 Example ....................................................................................... 369
22 Invoice Approval: A typical flow example ........................... 371
Part 3 Simple Mode VIM - scenarios 375
VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution v

Table of Contents
23 Invoice processing in Simple Mode ..................................... 377

23.1 Validation ..................................................................................... 378
23.2 Exception handling ........................................................................ 381
23.3 Enter cost assignment ................................................................... 385
23.4 Approval ....................................................................................... 386
GLS Glossary 389
vi OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

Chapter 1
About Vendor Invoice Management
OpenText Vendor Invoice Management for SAP Solutions (VIM) is an ABAP add-on
solution to SAP ECC and SAP S/4HANA.
VIM automates the processing of incoming documents into SAP.
Document-centric business processes like the processing of incoming invoices from

vendors or incoming sales orders from customers are typical use cases for VIM.
After capture, data is enriched and validated against predefined business rules.
If no business rules fail, the document is posted in SAP without human intervention.
Although a straight through, no-touch process is the ultimate objective, VIM also
supports the fast and efficient handling and resolution of exceptions.
Exceptions are routed via workflow to the relevant user or user group based on the
role assigned to the exception.
For managers VIM offers a comprehensive suite of operational and analytical

reports. In addition, VIM offers the tools to identify common exceptions that should
be addressed to achieve even higher levels of automation.
VIM includes the following solutions:
• Invoice Solution
• Procure to Pay Solutions
– Order Confirmation
– Delivery Note
– Quotation
• Order to Cash Solutions
– Sales Order
– Remittance Advice
Each solution consists of a best practice implementation for a specific document

scenario. It includes preconfigured mapping rules, enrichment rules, business rules,
user roles and user actions. Learning-based enrichments features embedded easy to
configure machine learning that automates input based on previous user input.
Since VIM resides inside SAP, enrichments and business rules have direct access to
SAP master and transactional data, which avoids complex interfaces and the
replication and duplication of data.
VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution 7

Chapter 1 About Vendor Invoice Management
Each solution offers a Workplace used by end-users and managers to manage and
monitor outstanding and completed work items. Each solution includes a
preconfigured set of analytical measures tailored for the specific document scenario.
Solutions can be enhanced to support company-specific business requirements.
VIM Solutions use features offered by its powerful feature rich Foundation.
The VIM Foundation consists of the following components:
• Inbound
• Process
• Workplace
• Analytics
VIM also supports custom solutions where a preconfigured solution is not available
for a specific, less common business process.
VIM offers a simple and intuitive user interface for end-users, managers and
administrators.
Users can choose between the classic SAP GUI or the modern SAP Fiori interface.
SAP Fiori offers a responsive web-based user interface that supports desktop and
mobile devices.
VIM supports various input channels including scan, fax¸ e-mail and web services.
It also supports various input formats, including paper, PDF, TIFF, IDoc and XML.
VIM requires an ArchiveLink-compliant SAP-certified content repository for the

storage of incoming documents. OpenText recommends OpenText Archiving and
Document Access for SAP Solutions or OpenText Core Archive for SAP Solutions for
the storage of documents.
8 OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

1.1. Architectural Overview
VIM integrates seamlessly via its Inbound component with OpenText Intelligent
Capture for SAP Solutions and OpenText Core Capture for SAP Solutions, which
uses advanced machine learning algorithms to extract metadata from imaged-based
documents like PDF and TIFF.
VIM also offers integration with OpenText Extended ECM for SAP Solutions and
OpenText Document Presentment for SAP Solutions.
1.1 Architectural Overview

The following figure gives an overview of the basis architecture. It shows how the
core components of VIM are integrated into SAP and which additional OpenText
components like Document Pipeline, Document Storage, Information Extraction
Service and WebViewer are completing the solution.
Beside the components of this graphic, VIM offers additional components such as
SAP NetWeaver Business Warehouse or BW/4Hana for specific solutions which are
not shown in this basis architectural overview.
Figure 1-1: Technical system landscape

Chapter 1 About Vendor Invoice Management
1.2 About this document

This document describes various implementation scenarios of VIM. It distinguishes
between functional and technical scenarios.
“Classic VIM - functional scenarios”

Functional scenarios refer to integrating VIM with external concepts or systems,
for example the implementation of Goods-Receipt-based invoices or a detailed
explanation of handling multiple backend systems.
“Classic VIM - technical scenarios”
Technical scenarios refer to customizing standard VIM functions, from the point
of view of a special requirement or an overview of the complete system. An
example for a special requirement are business requirements of Central
Reporting. An example for an overview is the end-to-end description how to
add new fields in ICC and VIM.
Note: From a technical point of view, OpenText™ Invoice Capture Center

for SAP® Solutions (ICC) corresponds to “OpenText™ Business Center
Capture for SAP® Solutions with invoice solution” (BCC with invoice
solution).
For detailed descriptions of customizing settings, technical scenarios may

provide links to the standard documentation.
“Simple Mode VIM - scenarios”
Simple Mode scenarios refer to Simple Mode a new invoice process designed
according to the SAP S/4HANA standard and concepts like simplification,
principle-of-one, digitalization, cloud-first, and a new user experience from the
start.
The Scenario Guide does not replace the standard documentation for VIM but
understands itself as an addition. See also the following guides that are partly
referenced in this document:
• OpenText Vendor Invoice Management for SAP Solutions - Installation Guide (VIM-
IGD)
• OpenText Vendor Invoice Management for SAP Solutions - User Guide for Invoice
Solution (VIM-UGD)
• OpenText Vendor Invoice Management for SAP Solutions - Configuration Guide for
Invoice Solution (VIM-CGD)
• OpenText Vendor Invoice Management for SAP Solutions - Administration Guide
(VIM-AGD)
• OpenText Vendor Invoice Management for SAP Solutions - Reference Guide for Invoice
Solution (VIM-RGD)
• OpenText Vendor Invoice Management for SAP Solutions - Scenario Guide for Invoice
Solution (VIM-CCS)

1.2. About this document
• OpenText Vendor Invoice Management for SAP Solutions - Security Guide (VIM-GSM)
Foundation (BOCP-CGD)
Solutions Beyond Invoice (BOCP-CCS)
• OpenText Vendor Invoice Management for SAP Solutions - User Guide for Solutions
Beyond Invoice (BOCP-UGD)
• OpenText Validation for SAP Solutions - User Guide (CPBC-UGD)
• OpenText Business Center Capture for SAP Solutions - Customization Guide (CPBC-
CGD)
• OpenText Business Center Capture for SAP Solutions - Administration Guide (CPBC-
AGD)
Release Notes Release Notes describe:
• The software supported by the product

• Requirements
• Restrictions
• Important dependencies
• New features
• Known issues
• Fixed issues
• Documentation extensions
The Release Notes are updated continuously . The latest version of the Release Notes
is available on OpenText My Support (https://knowledge.opentext.com/knowledge/
cs.dll/Open/10151494).
1.2.1 Target audience

This document addresses consultants and administrators who customize and
implement Vendor Invoice Management (VIM). This includes:
• SAP Basis Administrators

• SAP Workflow Administrators
• SAP Configuration and Development Support
• OpenText Professional Services SAP Consultants
The following knowledge is required from the reader:
• in-depth knowledge of SAP S/4HANA system administration

Part 1
Classic VIM - functional scenarios
Part 1 Classic VIM - functional scenarios
Functional scenarios refer to integrating VIM with external concepts or systems, for
example the implementation of Goods-Receipt-based invoices or a detailed
explanation of handling multiple backend systems.

Chapter 2
General Data Protection Regulation (GDPR)
The General Data Protection Regulation (GDPR) is a new European Union (EU) law
that gives residents greater protection and control of their personal data. It will
regulate the data that companies in and outside the EU can collect, store, and
transfer, and how they use it. All companies that process EU resident data must be
ready to comply when the GDPR enforcement starts on May 25, 2018.
Note: No legal advice is provided in this document or any other part of VIM
product documentation. Product documentation does only provide general
technical guidelines that may be relevant to consider if a customer implements
the product and is looking to define their strategy towards GDPR and similar
data protection requirements.
Software solutions like VIM cannot be considered to be or not to be GDPR

compliant. Every customer using SAP S/4HANA and VIM is responsible to provide
GDPR compliance in their organization.
SAP S/4HANA already provides a superior level of user security and data protection
features. VIM as an add-on package profits from the high standard of SAP S/
4HANA compared to outside-in solutions with their own database, duplication of
data, and lower level security concepts.
Sensitive personal data – In general VIM is not designed and does not require to
store any sensitive personal data: “Personal data” means any information
concerning the personal or material circumstances of an identified or identifiable
natural person. “Sensitive personal data” means information on racial or ethnic
origin, political opinions, religious or philosophical beliefs, trade-union
membership, health or sex life, and bank account data.
Use of generic data containers like long text fields and file attachments – Like
many other software components, VIM offers long text fields and the option to
upload and link file attachments. Any content of long text fields and content of
attachments is not in any way classified by the solution if it might contain personal
data or sensitive personal data. Customers using VIM are advised to train their
personal to not put any such information into long text fields and file attachments.
User data in VIM – VIM refers to user information stored in SAP S/4HANA and, in
addition to SAP S/4HANA, VIM provides a COA transaction to store information
about users being involved into Invoice Approval. Personal information stored in
COA may consist of, for example, first name, last name, user account, company
phone number, company email address as well as approval level and link between
user and invoice coding elements like cost center and others. VIM provides tools to
delete such personal data from COA.

Chapter 2 General Data Protection Regulation (GDPR)
Supplier VIM is designed to process vendor invoices and therefore includes supplier specific
specific data information and reference to SAP’s business partner master which may be classified
and VIM run
time data
by a customer as relevant for their data privacy strategy.
In general, data stored in VIM run time tables is considered to be of temporary

nature and only required during the processing phase were an SAP invoice has not
yet been created in core SAP. When an SAP invoice has been created and the
processing history from VIM has been attached as PDF file to the invoice posting,
then the data in VIM can be deleted, for example, using SAP Data Archiving tools.
Customers are advised to consider the tradeoff between keeping VIM data for
reporting and analytics purposes against deleting data to reduce potential
complexities when defining their data privacy strategy. Such a strategy could
include, for example, to delete old VIM run time data after x months or years.
VIM may also store vendor specific data in some customizing tables as well as
reporting tables and other database tables. Because VIM is a very flexible framework
with many features and many extension points, every customer needs to determine
where vendor data is stored in their specific installation.
VIM offers tools to delete vendor specific entries from some core customizing tables
as well as from the VIM run time tables.
The following documentation sections explain the tools available in VIM to delete
specific user data and specific vendor information in VIM tables:
• Section 4.1.4.8 “Usermap and COA cleanup” in OpenText Vendor Invoice

Management for SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD)
• Section 8.3.1 “Vendor data cleanup program” in OpenText Vendor Invoice
Management for SAP Solutions - Administration Guide (VIM-AGD)
• Section 22.9 “Vendor cleanup program for Supplier Self Service” in OpenText
Vendor Invoice Management for SAP Solutions - Configuration Guide for Invoice
Solution (VIM-CGD)
Areas with employee and vendor related data in VIM

The following areas store employee or vendor related data and may therefore
potentially be subject to GDPR. This section provides some hints how to delete this
data from VIM.
Vendor and employee data stored in VIM customizing (master data) and
transactional tables
This includes configuration like white lists of vendors, COA, DP documents, and
other objects.
OpenText provides a program to clean configuration tables for particular vendors

and clean business data in DP documents that is related to vendors. DP documents
can be archived and deleted with standard tools provided by VIM. This can be done
even before the end of the data retention period. For more information, see Section

8.3.1 “Vendor data cleanup program” in OpenText Vendor Invoice Management for SAP
Solutions - Administration Guide (VIM-AGD).
OpenText also provides a program to clean personal data from COA or to delete
COA records completely. For more information, see Section 4.1.4.8 “Usermap and
COA cleanup” in OpenText Vendor Invoice Management for SAP Solutions -
Configuration Guide for Invoice Solution (VIM-CGD).
Vendor and employee data contained in ArchiveLink documents
This includes the scanned vendor invoice image, uploaded PDF invoices, any file
attachments created in the process, and the PDF history log created by VIM.
VIM links such archived documents to the posted SAP invoice (object type BKPF).
They can later be deleted using standard SAP ILM (Information Lifecycle
Management) tools, for example after the archiving retention period expires.
Data in the tables specific to Supplier Self Service
Open Text provides a cleanup program to delete records from Supplier Self Service
tables. For more information, see Section 22.9 “Vendor cleanup program for Supplier
Self Service” in OpenText Vendor Invoice Management for SAP Solutions - Configuration
Guide for Invoice Solution (VIM-CGD).
Data in internal ICC/BCC vendor and purchase orders databases
Currently, no special programs are provided. As soon as vendors and related

purchase orders are deleted from the backend system, ICC/BCC download can be
run in full mode, which will reset the ICC/BCC database first. This can be performed
periodically to ensure the cleanup.
Application logs or traces
This includes logs or traces potentially created by VIM if it was configured

accordingly.
Most of logs and traces are not stored permanently. They have an adjustable
retention period, normally much shorter than that of the related business data.
Sample scenarios for configuring audit areas and IRM policies

When using SAP Information Lifecycle Management (ILM) tools with respect to
VIM data, you must create and maintain audit areas and IRM policies. The
configuration of ILM objects is described in Section 37.4 “Configuring ILM objects
for VIM archiving objects” in OpenText Vendor Invoice Management for SAP Solutions -
Configuring ILM audit area for ILM object /OPT/DOC
Audit areas define the business information needed to store data for audit purposes.

To configure an ILM audit area:
1. Run the ILMARA transaction in the customer namespace (Y or Z).
2. To create an ILM audit area, click the New button.
3. Mark the ILM objects /OPT/DOC and AL_DOCUMENTS, and then select the Object
Assignment check box for the ILM objects.
The ILM object /OPT/DOC is for VIM invoices.
The ILM object AL_DOCUMENTS can also be included in the audit area to enable
ILM for ArchiveLink attachments of invoices.
Configuring ILM policies and rules
You can perform time-based data life cycle management with the help of rules that
are defined in the context of policies.
To perform time-based data life cycle management:
1. Run the IRMPOL transaction.
2. Create IRM policies for the audit area created in “Configuring ILM audit area
for ILM object /OPT/DOC” on page 17 and assign business rules.
3. To define new policies and rules, click New.

Note: You can choose a maximum of 4 condition fields that can be used
for one policy.
4. When the policy is created with displayable condition fields, maintain ILM rules
with respect to the ILM object.
5. For ILM object AL_DOCUMENTS, select the Inherit Rule check box to inherit rules
from the OPT_DOC ILM object.
6. When all rules are defined in ILM policies, set the policy status to LIVE.
Configuring audit area and policy for OPT_REP
Carry out all configuration steps for ILM object /OPT/REP, as done for /OPT/DOC.
Note: When creating audit area for /OPT/REP, just choose the ILM object /OPT/
REP. You need not choose ILM object AL_DOCUMENTS.
Viewing archiving sessions
From the Archive administration, you can navigate to ILM Browser or Management
to view the archiving sessions and the status of the sessions.


Chapter 3
Processing invoices in VIM
3.1 Standard invoice processing

VIM delivers a default configuration (baseline) that you can use as a template for
your own custom processes. This section describes the processing modes that are
based on this default configuration.
A standard VIM process for a Non PO invoice comprises the following steps:
1. Invoice entry
2. Data enrichment
3. Exception handling
4. Approval
5. Posting
A standard VIM process for a PO invoice with goods-receipt-based purchase orders

comprises the following steps:
1. Invoice entry
2. Data enrichment
4. Handling of price/quantity discrepancies
5. Posting
6. Handling of price/quantity discrepancies
A standard VIM process for a PO invoice related to purchase orders without goods
receipt settings comprises the following steps:
1. Invoice entry
2. Data enrichment
4. Approval / acceptance of goods or services
5. Posting
6. Handling of price discrepancies
You configure this VIM process in a business configuration set (document type).
Several participants in the invoice process can be involved during a VIM process.

Chapter 3 Processing invoices in VIM
3.1.1 Participants in the invoice process

Exception In the baseline configuration, the following roles are part of invoice management
handling processes in the exception handling:
Role Used in PO Used in NPO

Process Process
AP_PROCESSOR X X
AP_EXPERT X X
BUYER X
RECEIVER X
INFO_PROVIDER X X
Accountant (Role: AP_PROCESSOR)

The main actor in the invoice processing. The following tasks are done by the
accountant:
• Scanning invoices
• Verifying invoice data, comparing data and line items with invoice image
• Checking compliance rules
• Solving most invoice exceptions
• Forwarding complex invoices or problem cases to an accounting expert
• Sending inquiries to participants in the invoice process, for example to buyer
or receiver
• Starting and monitoring approval processes
Accounting expert (Role: AP_EXPERT)

The accounting expert handles complex or problematic invoice cases like special
tax issues or disputes.
• Receiving invoices from the accountant if necessary

• Solving complex invoice exceptions
• Has the same processing options as the accountant
Buyer (Role: BUYER)

The buyer can be involved in the PO process to handle some PO based issues.
For this role, the following actions are available:
• Creating a new PO
• Changing an existing PO

3.1. Standard invoice processing
Receiver (Role: RECEIVER)

The receiver can be involved in the PO process to handle some goods-receipt-
based issues. For this role, the following actions are available:
• Posting a goods receipt

• Reversing a goods receipt
Info provider (Role: INFO_PROVIDER)

The info provider can be any user in the organization to answer an ad hoc
question sent, for example, from the accountant. The following action is
available:
• Entering a comment and sending back to sender
Approval The following roles are available in the approval process:
Role Used in PO Used in NPO

Process Process
CODER X
REQUESTER X
APPROVER X X
Coder
If the cost object assignment is not done by the accountant, a coder can enter the
relevant accounting data.
• Coding – entering cost objects

• Delegating coding to someone else
• Sending an inquiry to somebody
• Approving the coding
• Rejecting the invoice with a comment
Requester
The requester of the invoice is involved to confirm the receipt of goods or
services.
• Comparing goods and services listed on invoices

• Checking and confirming prices and cost centers so that the invoice approval
workflow can continue

Approver for NPO invoices

The approver approves based on the authority of the individual assigned
approval limits.
• Approving to continue to next approver, or the invoice is finally approved

and ready for posting
Approver for PO invoices

The approver confirms the goods/services.
• Approving in a one-step approval

Blocking The following roles are available in the blocking workflow to handle price and
workflow quantity discrepancies:
• AP_PROCESSOR
• BUYER
• RECEIVER
• REQUISITIONER
• INFO_PROVIDER
Accountant (Role AP_PROCESSOR)

The accountant is relevant in the blocking workflow for a final decision or check
what the initial roles have decided for a price and quantity discrepancy. The
following decisions are available for the accountant, depending on what the
buyer or receiver has decided.
• Cancelling the invoice

• Short Pay
• Paying as invoiced
• Cancelling and reentering the invoice
• Sending inquiries to participants in the invoice process, for example to buyer
or receiver
Buyer (Role: BUYER)

The buyer is involved to check or handle price discrepancies. For this role, the
following actions are available:
• Continuing to accountant with the decision to cancel the invoice

• Continuing to accountant with the decision to Short Pay

• Continuing to accountant with the decision to pay as invoiced

• Continuing to accountant with the decision to cancel and reenter the invoice
• Creating a new PO
• Changing an existing PO
• Updating info record
Receiver (Role: RECEIVER)

The receiver is involved to check or handle quantity discrepancies. For this role,
the following actions are available:

• Posting goods receipt
• Reversing goods receipt
Requisitioner (Role: REQUISITIONER)

The requisitioner is involved by a manual forward to check or handle a quantity
or price discrepancy or to create a new purchase requisition. For this role, the
following actions are available:

• Creating a new purchase requisition
Info provider (Role: INFO_PROVIDER)

The info provider can be any user in the organization to answer an ad hoc
question sent, for example, from the accountant or the buyer. For this role, the
following action is available:
• Entering a comment and sending back to sender

3.1.2 Business configuration set

Business processes in VIM are configured in the document type configuration. A
document type comprises a set of logical modules for the following purposes:
• Data enrichment
• Business rules with assignment to a specific user role for exception handling
• A posting component
Document Types are related to a specific invoice type. For more information, see
Section 9.1 “Configuring DP document types” in OpenText Vendor Invoice
Management for SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD).
The baseline delivers three document types that can be used as templates to
configure custom processes:
NPO_S4
Invoices without purchase order (NPO invoices)
Invoices that are not based on a purchase order must be approved before
posting.
PO_S4
Invoices based on a purchase order (PO invoices)
Depending on the type of the purchase order, the business rules are checking
whether a goods receipt or service entry is required or if an approval is needed
before posting.
DWN_75
Down payments
Down payment processes that need to be posted in the F-47 transaction are
handled in this document type.
3.1.3 Invoice entry

Invoices can be received in several ways:
• Scanning without OCR

• Scanning with OCR
• Email entry
• IDoc
• Business networks
• Import scenarios
VIM can handle these different input channels using the Inbound Configuration. For
more information, see Section 7 “Incoming document processing” in OpenText

Vendor Invoice Management for SAP Solutions - Configuration Guide for Invoice Solution
(VIM-CGD).
3.1.4 Data enrichment

After the invoice is entered in one of the invoice channels, the system is performing
an automatic data enrichment in the logic modules. For more information, see
Section 9.4 “Processing logic modules” in OpenText Vendor Invoice Management for
SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD).
3.1.5 Exception handling

The baseline delivers a set of rules (exceptions). This includes basic checks, for
example missing mandatory data, and country specific compliance checks. If these
checks are resolved, further business rules check if an invoice approval is needed, or
if goods receipts and service entries are sufficient to post the invoice automatically.
The exception handling is done by the accountant and the expert accountant in the
VIM Invoice Workplace and the VIM indexing screen.
3.1.5.1 VIM Invoice Workplace

VIM Invoice Workplace is the main access point for the accountant. All relevant
invoices are available for the accountant in the workplace inbox.
3.1.5.2 VIM indexing screen

The VIM indexing screen is called from the VIM Invoice Workplace by choosing a
specific invoice. The accountant can check the detailed information about the invoice
and enter missing data.
The current process step is displayed in the Basic Data tab and shows the active
exception, for example Missing Company Code (NPO).

Based on the step configuration, several process options are available to refer the
invoice to other roles and users or perform other tasks. The process options are
depending on the currently active exception.
With the process option Apply Rules, the indexing screen recalculates the current
exception. If the next active exception is configured for the same role (for example
accountant), the indexing screen updates the step and might display different
process options.
If the next active exception is configured for another role, the indexing screen is
closed and the workflow is sent to the new role (for example an approver).
The invoice exceptions can be checked by using the Simulate Business Rules
functionality.

For more information, see Section 4.4 “Simulating business rules” in OpenText
Vendor Invoice Management for SAP Solutions - User Guide for Invoice Solution (VIM-
UGD).
If all exceptions are resolved and automatic posting is configured, the indexing
screen is closed and posting in background is triggered.
If all exceptions are resolved and manual posting is configured, the indexing screen
accesses the default step and a new process option to post manually becomes
available.
3.1.5.3 Baseline checks for NPO invoices (NPO_S4)
Step ID Process Type

242 Check Data After Restart
404 Check BPF added data (NPO)
435 PO Data exists (NPO)
431 Missing Company Code (NPO)
433 Missing Gross Amount (NPO)
223 Missing Invoice Date (NPO)
233 Vendor Invoice Reference Missing (NPO)
201 Invalid Vendor (NPO)
202 Invalid Currency (NPO)
238 Missing Mandatory Information (NPO)


204 Suspected Duplicate (NPO)
206 Non-PO Credit Memo Processing
221 Incomplete Credit Memo (NPO)
228 Missing Date of Supply (NPO)
224 Invalid Tax Info (NPO)
220 Invalid Vendor VAT Number (NPO)
226 ISR Number Mismatch (NPO)
270 Validate Bank Details (NPO)
276 Invalid Payment Reference (NPO)
434 Check Vendor/Company Address
203 Invalid Requester ID (NPO)
225 Invalid Recipient VAT Number (NPO)
290 SCB Indicator / Supplying Country Missing (NPO)
287 Invalid Withholding Tax Code/Type (NPO)
288 Withholding Tax Base/Amount Exceeds Total Net (NPO)
289 Check Withholding Tax Data (NPO)
255 Invalid/Missing Vendor ABN Number (NPO)
256 Invalid/Missing Recipient ABN Number (NPO)
277 Missing Vendor PAN Number (NPO)
278 Mismatch Vendor PAN Number (NPO)
279 Missing Vendor STC Number (NPO)
280 Mismatch Vendor STC Number (NPO)
281 Missing Vendor CST Number (NPO)
282 Mismatch Vendor CST Number (NPO)
283 Missing Vendor TIN/TOT Number (NPO)
284 Mismatch Vendor TIN/TOT Number (NPO)
285 Missing Vendor LST Number (NPO)
286 Mismatch Vendor LST Number (NPO)
420 Missing/Invalid GST Partner (NPO)
422 Missing/Invalid Vendor GST Registration number (NPO)
424 Missing/Invalid HSN/SAC code (NPO)
216 Invoice Older than Allowed (NPO)
241 Verification Required (NPO)


218 Invalid Common Ordinary Invoice (VAT Exists) (NPO)
253 Vendor Audit Required (NPO)
254 Tax Audit Required (NPO)
250 Approval Required (NPO)
271 Validate Accounting Data (NPO)
3.1.5.4 Baseline checks for PO invoices (PO_S4)

142 Check Data After Restart
405 Check BPF added data (PO)
430 Missing Company Code (PO)
432 Missing Gross Amount (PO)
125 Missing Invoice Date (PO)
133 Vendor Invoice Reference Missing (PO)
101 Invalid PO Number (PO)
102 Invalid Vendor (PO)
104 Invalid Currency (PO)
138 Missing Mandatory Information (PO)
426 Supplier self service: self registration rule
105 Suspected Duplicate (PO)
115 Invalid PO Item Number (PO)
113 Manual Check Needed / Missing Data for Indexing Lines (PO)
160 PO Credit Memo Processing (PO)
121 Incomplete Credit Memo (PO)
127 Missing Date of Supply (PO)
106 PO Not Released or Incomplete
126 Invalid Tax Info (PO)
120 Invalid Vendor VAT Number (PO)
129 ISR Number Mismatch (PO)
170 Validate Bank Details (PO)
176 Invalid Payment Reference (PO)
159 Invalid Requisitioner (PO)
128 Invalid Recipient VAT Number (PO)


434 Check Vendor/Company Address
190 SCB Indicator / Supplying Country Missing (PO)
161 Company Code Mismatch (PO)
153 Vendor Mismatch (PO)
155 Currency Mismatch (PO)
156 Unit of Measure Mismatch (PO)
154 Service Entry Required (PO)
166 Service Entry Required - Enhanced Check (PO)
401 Invalid Withholding Tax Code/Type (PO)
402 Withholding Tax Base/Amount Exceeds Total Net (PO)
415 Check Withholding Tax Data (PO)
112 Missing/Invalid Invoice Code Format (PO)
114 Missing/Invalid Characters in Secret Code (PO)
141 Verification Required (PO)
191 Missing NF Data (PO)
192 Missing NF Customizing (PO)
193 NF Validation Check Failed (PO)
194 Brazil - Wait for GR - Simple Check (PO)
196 Russia - Wait for TORG-12 - Simple Check (PO)
172 Invalid/Missing Vendor ABN Number (PO)
173 Invalid/Missing Recipient ABN Number (PO)
177 Missing Vendor ECC Number (PO)
178 Mismatch Vendor ECC Number (PO)
179 Missing Vendor CST Number (PO)
180 Mismatch Vendor CST Number (PO)
181 Missing Vendor TIN/TOT Number (PO)
182 Mismatch Vendor TIN/TOT Number (PO)
183 Missing Vendor LST Number (PO)
184 Mismatch Vendor LST Number (PO)
185 Missing Vendor PAN Number (PO)
186 Mismatch Vendor PAN Number (PO)
187 Missing Vendor STC Number (PO)
188 Mismatch Vendor STC Number (PO)


419 Missing/Invalid GST Partner(PO)
421 Missing/Invalid Vendor GST Registration number (PO)
118 Invalid Common Ordinary Invoice (VAT Exists) (PO)
116 Invoice Older than Allowed (PO)
163 GR Not Done - Simple Check (PO)
425 Cannot Verify Quantity/Price Exceptions (PO)
418 Quantity/Price Mismatch (PO)
417 Quantity/Price Confirmation Required (PO)
418 Quantity/Price Mismatch (PO)
151 Vendor Audit Required (PO)
158 Tax Audit Required (PO)
416 Down Payment Clearing (PO)
150 Approval Required (PO)
3.1.5.5 Baseline checks for down payments (DWN_75)

305 Check Data After Restart (DWN)
310 Invalid Vendor (DWN)
315 Invalid PO Number (DWN)
320 Invalid Currency (DWN)
323 Invalid Requester ID (DWN)
325 Vendor Reference Missing (DWN)
330 Missing Document Date (DWN)
333 Determine Expense Type (DWN)
335 Suspected Duplicate (DWN)
340 Invalid Vendor VAT Number (DWN)
345 Invalid Recipient VAT Number (DWN)
348 Missing Date of Supply (DWN)
350 PO Not Released or Incomplete (DWN)
355 Vendor Address Mismatch (DWN)
360 Invalid Company Address (DWN)
365 Invalid Tax Info (DWN)
370 Vendor Mismatch (DWN)


375 Currency Mismatch (DWN)
380 Missing Mandatory Information (DWN)
385 Approval Required (DWN)
390 Vendor Audit Required (DWN)
395 Tax Audit Required (DWN)
3.1.6 Approval
An approval is required for invoices that cannot be verified by other means like
goods receipts or service entries. Therefore, invoices without purchase order are
routed to an approval process.
This can comprise two steps:
• Coding
The requester or coder enters cost object information.
• Approval
Invoice approval based on configured amount limits.
Coder and approver can access their work item using either SAP GUI or Fiori Task
Apps.
For more information, see Section 11 “Invoice Approval” in OpenText Vendor Invoice
3.1.7 Posting
You can configure the system to post invoices automatically when all exceptions are
resolved and approvals are done. Alternatively, the invoice can be processed and
posted manually.
In the baseline, all invoices are processed in the logistics invoice verification (MM)
and using the MIRO transaction.
For more information, see Section 33 “Posting invoices” in OpenText Vendor Invoice

3.2. Invoice processing with parked invoices
3.2 Invoice processing with parked invoices

The baseline configuration allows the handling of parked or held invoices. The
process is consisting of the same steps like the standard process:
1. Invoice entry
You can use the same inbound channels for incoming invoices as described in
the standard process. For more information, see “Invoice entry” on page 26.
Alternatively, you can use direct parking in MIRO or the respective Fiori Task
App as input channel.
2. Data enrichment
You can configure the data enrichment to exclude or include specific logic
modules when handling parked invoices.
You can configure the business rules to exclude or include specific exceptions
when handling parked invoices.
If a parked document is available, the VIM indexing screen is set to process
mode, all data changes must be done in the parked document. For this purpose,
the accountant has a new process option in the indexing screen (Display SAP
Document (MIR4)). This process option can be used to display the document in
MIR4 and change data.
4. Approval
The approval is performed as described in the standard process. For more
information, see “Approval” on page 34.
5. Posting
The posting is performed as described in the standard process. For more
information, see “Posting” on page 34.

Chapter 4
Multiple backend system
VIM can be deployed in many stand-alone systems. But you might want to use some
central resources, for example one of the following:
• a central invoice entry point, which includes scanning with Invoice Capture
Center (ICC).
• a central archive to archive all incoming invoices
• a central controlling point for management, which uses Central Reporting
For requirements like these, you can run VIM as a multiple backend system. This
means you have one central system with multiple satellite systems for invoice entry
and procurement logistics. Figure 4-1 shows an example for a multiple backend
system.
Figure 4-1: VIM as a multiple backend system
Important considerations for multiple backend systems
• There can be only one central system connected to one or more satellite
systems.

Chapter 4 Multiple backend system
• OpenText recommends connecting a single Content Repository to all

systems in the landscape to ensure that image links get propagated to all
systems.
• The number ranges for the Document Processing number are centralized
and hence should be maintained in the central system.
All satellite systems and the central system can make use of the central
number range.
• The VIM workflow can run in central or satellite systems, as needed.
OpenText recommends running the VIM workflow in the system where the
final SAP invoice gets posted.
4.1 Defining logical systems

In this step, you define the logical systems in your multiple backend system.
Systems in the landscape are referred using logical system IDs. In SAP terminology,
a logical system is a client. First, you must set up logical system IDs. In a second step,
you assign the logical system IDs to the clients in the SAP S/4HANA systems, see
“Assigning clients to logical systems” on page 39.
Note: It is possible that the logical system ID already exists. In this case, you
can ignore this procedure and the procedure “Assigning clients to logical
systems” on page 39.
To define logical systems:
1. Run the /n/OPT/VIM_LOG_SYS transaction.

Alternatively, run the /N/OPT/SPRO transaction and navigate to the menu path
OpenText Vendor Invoice Management Invoice Solution > Document
Processing Configuration > General Configuration > Multi-Backend
Scenarios > Define Logical Systems.
2. Click New Entries in the application tool bar.

4.2. Assigning clients to logical systems
3. Define the logical system, using the following parameters:
Log.System
Enter a name for the logical system you want to create.
Name
Enter a description of the logical system.
4. In case you want to change an entry:
a. Select the appropriate line.
b. Select Change Field Contents from the Edit menu.
c. Enter the new text.
d. Click Replace.
5. Click to save your settings.
4.2 Assigning clients to logical systems

In this step, you assign a client to each logical system. The ID of the logical system is
used as a unique ID. It has a unique assignment to a client in an SAP S/4HANA
system. Logical systems in the landscape are assigned to their respective clients in
their respective systems.
To assign clients to logical systems:
1. Run the /n/OPT/VIM_ASGN_CLNT transaction.

Scenarios > Assign Client to Logical System.

2. Select the line of the client you want to assign to a logical system.
3. To display details, click the button in the application tool bar.
4. In the Logical system field, enter the ID of the logical system to which you want
to assign the selected client.

4.3. Maintaining RFC destinations
4.3 Maintaining RFC destinations

Remote Function Call (RFC) is the standard SAP interface to communicate between
SAP S/4HANA systems. Using RFC, the central system in a multiple backend system
can communicate with every satellite system.
In this step, you maintain RFC destinations for each logical system that you want to
communicate to.
Recommendations
• OpenText recommends using RFC destinations for System Communication

that have the same name as the logical system.
• For Dialog Communication, OpenText recommends to use trusted RFC

connections.
For more details on setting up RFC destinations, see the SAP Help.
To maintain RFC destinations:
1. Run the SM59 transaction.

Scenarios > Maintain RFC Destinations.
2. From RFC Connections, open ABAP Connections (Type 3).
3. Double-click the connection you want to maintain.

4. Enter the connection parameters, like Description, Target Host, and System
Number.
4.4 Working with the System Landscape Directory

(SLD)
The SLD helps to get the overview of the system landscape; for example of the
following settings:
• How many systems are involved? And which ones?

• Which one is the central system? Which ones are the satellite systems?
• How does the central system communicate with each satellite system? Using
which RFC?
In the SLD, you must maintain all systems with which interaction can happen. This
includes the own system.
Terminology note
“Own system” means the system where the activity is being done or where the
current SLD is being maintained.

4.4. Working with the System Landscape Directory (SLD)
All systems must be defined as logical systems before they can be used in the SLD.
See “Defining logical systems” on page 38 and “Assigning clients to logical systems”
on page 39 for details.
Logical systems are client dependent, hence in a given system T01, client 800 and
client 900 could be set up as different systems with different logical system defined.
4.4.1 Maintaining the SLD

You must maintain the SLD manually in all SAP S/4HANA systems involved.
To maintain the SLD:
1. Run the /N/OPT/VIM_SLD transaction.

Scenarios > System Landscape Directory > System Landscape Directory.
2. Double-click a line to display details for a logical system.

3. Maintain logical systems, using the following parameters:
Description
Enter a description for the system.
System Type
Select the proper SAP S/4HANA System Type.
RFC for System Comm.
Enter the RFC destination for communicating to the system. OpenText
recommends using this RFC destination with system or communication
users, not with dialog users.
On the own system, insert NONE.
RFC for Dialog Comm
Enter the RFC destination for communicating by active dialog screen.
OpenText recommends using a trusted RFC destination in this case. See the
SAP documentation on how to set up trusted connections between SAP S/
4HANA systems.
Classification
Select the classification of the system. The following values are available:
• Central System
• Satellite System
The values above are relevant for multiple backend systems.
• External System
External System refers to any system which is not an SAP S/4HANA
system. For example, a non-SAP system is treated as an External System.

4.4. Working with the System Landscape Directory (SLD)
An SAP Supplier Relationship Management (SAP SRM) system could

also be part of the landscape. SAP SRM is an SAP system but not of ERP
type. Therefore, an SAP SRM system must also be classified as an
External System.
• Single System Landscape
Select this value if your system landscape comprises only one system.
Central System
Enter the Central System if the own system is classified as Satellite
System.
Status
Select the status of the system. Available values: Active or Inactive.
VIM Version
Enter the VIM version number of the remote system that is used for cross
release multiple backend.
Note: The fields VIM Version, SP Level and Custom Patch are used
for cross release multiple backend. They must correspond to the
values used when maintaining the names of the release dependent
data structures. For more information, see “Implementing cross
release multiple backend functionality” on page 47.
SP Level
Enter the VIM support package number of the remote system that is used
for cross release multiple backend.
Custom Patch
If you have additional changes of the related data structures, for example
using append structures, use this field to maintain an additional attribute to
distinguish the structure definitions.
4.4.2 Setting up the SLD in a multiple backend system

Note: This configuration is only necessary for multiple backend systems. See
“Setting up the SLD in a single system landscape” on page 46 for single
system landscapes.
In multiple backend systems, one SAP S/4HANA system is the central system; the
other SAP S/4HANA systems are satellite systems.
To set up the SLD in a multiple backend system:

1. In the central system, define all logical systems (see “Defining logical systems”
on page 38) for all systems involved (SAP or non SAP). Make sure that the
logical system ID is unique in the entire landscape.
2. Assign the client to the logical system, see “Assigning clients to logical systems”
on page 39. This action is only relevant for the own system. Normally, it is

always assigned so crosscheck if the own system is already assigned to the

client.
3. Maintain the SLD in the central system, as described in “Maintaining the SLD”
on page 43, for each of the systems involved.
Once you finished setting up the SLD in the central system, login to the satellite
systems and do the following:
4. Define the logical system (see “Defining logical systems” on page 38) for the
central system. The name must be the same as in the central system.
5. Assign the client to the logical system (see “Assigning clients to logical systems”
on page 39) for the own system if it is not yet assigned.
6. Maintain the SLD in the satellite systems, as described in “Maintaining the

SLD” on page 43, for the central system and the own system.
For the own system, set RFC for System Comm. to NONE, and leave RFC for
Dialog Comm blank.
For the central system, assign proper RFC for System Comm. You may skip
RFC for Dialog Comm.
4.4.3 Setting up the SLD in a single system landscape

Note: This configuration is only necessary for single system landscapes. See
“Setting up the SLD in a multiple backend system” on page 45 for multiple
backend systems.
In a single system landscape, OpenText recommends maintaining the SLD with the
following basic information:
To set up the SLD in a single system landscape:
1. Define the logical system (see “Defining logical systems” on page 38) for the
own system if it is not already defined.
2. Assign the client to the logical system (see “Assigning clients to logical systems”
on page 39) for the own system. Normally, it is always assigned so crosscheck if
the own system is already assigned to the client.
3. Maintain the SLD, as described in “Maintaining the SLD” on page 43. The
following parameters are relevant:
• System Type
• RFC for System Comm.: set to NONE.
• RFC for Dialog Comm: leave blank.
• Classification: Single System Landscape

4.5. Implementing cross release multiple backend functionality
4.5 Implementing cross release multiple backend

functionality
As of VIM 16.3, it is possible to run different VIM versions and support package
levels in a multiple backend scenario. Because of complexity, not all possible
multiple backend functions are supported. Support is provided for:
• Centrally controlled DP document numbers

• Starting VIM workflows in satellite systems, initiated by central system
• VIM Invoice Workplace, when run on the central system: running work items,
displaying document data. VIM Invoice Workplace can still be run in the satellite
systems, but to access only local work items.
• VIM Analytics, when run on the central system – all functions. VIM Analytics
can still be used in the satellite systems, but to access only local documents.
All other multiple backend scenarios are currently not supported, including
restarting workflows and sending documents back into central system, running
business rules or duplicate check in remote systems and Central Reporting.
Notes
• VIM functions with multiple backend when different releases or support

packages are used as long as all data structure definitions in all systems are
identical. However, many data structures are changed relatively often, as
result of new features and customer requirements. Therefore most likely
their definitions will differ across releases or support packages.
• Multiple backend processing is supported also when different systems are
running on different SAP releases. For example, when one VIM system is
running on SAP ERP and another one is running on SAP S/4HANA. In such
cases, the same potential problems of data structure compatibility can arise.
You can use the new multiple backend logic provided by OpenText to
resolve such problems when you set up reference data structures and
corresponding configuration.
• OpenText does not maintain any lists of structure changes or compatibility
across releases or support packages. You can verify in each particular case,
how the structures used in each scenario are defined.
• OpenText only supports landscapes running the same release/support
package, and, in case of differing release/support package levels, only the
scenarios described in the list above, when using the special configuration
described in this section.
In the supported scenarios, when doing remote calls, it is checked whether the
remote (satellite) system has a different VIM release / support package combination,
as maintained in the System Landscape Directory. It might have the same

combination as the caller central system, or the corresponding configuration is not

maintained or is inconsistent. In these cases, the call is performed with the same data
structures as defined on the caller central system.
In case of a different release / support package combination, data structures in the

remote satellite system can be defined in a way that results in short dumps in the
RFC calls. This happens when the structure itself or its include structures are
changed from support package to support package, and not all systems in the
landscape are upgraded at the same time.
To prevent the dumps, you need to make the calls with the remote system data
structures. The reference structures must first be created in the caller central system,
using different structure names. The corresponding data structure names are read
from customizing, the data structures are created appropriately and populated with
data, using MOVE-CORRESPONDING statements. The RFC call is then performed with
the data structures that correspond to the remote satellite system. This works in both
directions, for passing data to the satellite system, and for getting the data from the
satellite system. If some fields do not exist in the target structure, they will remain
empty.
Create the reference structures in exactly the same way as they look like in target
systems. To ensure the binary compatibility of the structures, create all include and
nested structures as well. Expanding the includes, leading to flat structures, may
lead to data alignment problems and is therefore not recommended. To verify the
compatibility, run the SE11 transaction and, on the menu, follow Utilities > Runtime
Object > Display for both original and reference structures, and compare the fields
offsets. Also beware of potentially different data element definitions in different
systems.
Example:
• Material number data element MATNR can be defined as 18 or 40 characters long.

• Similarly, if one of the systems is SAP S/4HANA 1809 or later, the lengths of amount fields
may differ from earlier releases.
There are several reference data structures that you need to create for each differing
remote system. This is explained in “Maintaining release dependent data structures”
on page 49.

4.5. Implementing cross release multiple backend functionality
4.5.1 Maintaining release dependent data structures

For each differing VIM release / support package combination in the landscape, you
need to create several reference data structures, because there are several functional
areas where the RFC calls are performed. OpenText recommends that you copy the
existing structures in the central system, expand the includes by using the menu
command Copy components in the SE11 transaction, and then perform the
necessary changes to synchronize the structure definitions with the definitions in the
satellite systems. The sequence of the fields must match and their types must match
or be compatible. The following list explains each functional area that needs to be
considered, also giving the area code name to be used in the customizing.
Functional areas
GEN_1HEAD
Generic use DP document header. This structure is mostly used to pass DP
document header data when starting the DP workflow. Standard VIM structure
name: /OPT/VIM_1HEAD (start with this structure when copying).
GEN_1ITEM
Generic use DP document item. This structure is mostly used to pass DP
document item data when starting the DP workflow. Standard VIM structure
name: /OPT/VIM_1ITEM.
VAN_HEAD
Document header structure in VIM Analytics. This is used to read and display
documents. Standard VIM structure name: /OPT/VVA2_OUT_DOC_HDR_ST.
VAN_ITEM
Document item structure in VIM Analytics. This is used to read and display
documents. Standard VIM structure name: /OPT/VVA2_OUT_LINE_ITEM_ST.
WP_ITEM
Document item structure in VIM Invoice Workplace. This is used to read and
display documents. Standard VIM structure name: /OPT/CPMC_OUTPUT_ITEM_
ST.
LBA_LOG
Structure for detailed approval log display for level based approvals, used in
VIM Analytics and VIM Invoice Workplace. Standard VIM structure name: /
OPT/LBA_LOG_DISP.
Note: You must define the structures as flat structures or transparent tables
(this happens when copying) but they are also used when needed to create
internal tables.
To maintain the reference data structures:
1. Run the /N/OPT/VIM_CRMB_DS transaction.



Scenarios > Cross release multibackend: structures.
2. For each combination of VIM version, support package level, and custom patch
number that is used in the system landscape directory (SLD), create entries for
all functional areas listed in Functional areas on page 49, using the following
parameters:
VIM Version
VIM version number as used in the SLD
SP level
VIM support package level as used in the SLD
Cust Patch
Custom patch. Additional value used to distinguish between structure
versions as used in the SLD
Struct. type
Structure type / functional area - according to Functional areas on page 49
and the explanations at the beginning of this section
Structure name
Structure name in the data dictionary

4.6. Maintaining channels
4.6 Maintaining channels

A channel uniquely identifies the source of an incoming invoice to the VIM system
across the landscape. Channels drive the System Determination Procedure in a
multiple backend system and drive the set of mapping to be executed.
For further details, see Section 7.3 “Maintaining channels” in OpenText Vendor Invoice
4.7 Maintaining Mapping IDs

Invoices come through different channels, for example from ICC, from IDOC, or by
email. Parameters or values of the incoming invoice will be mapped to parameters
or values of the indexing document. The mapping can be different depending on the
channel. Therefore for every channel a mapping set or mapping ID is assigned.
A Mapping ID can be created to logically group a mapping set for a particular

channel. A Mapping ID is tied to a channel so that proper mapping is executed for
an incoming invoice for that channel.
For further details, see Section 7.4 “Maintaining the VIM field mapping” in OpenText
(VIM-CGD).
4.8 Maintaining the system determination

In multiple backend systems, you can specify the system determination procedure to
determine in which system the VIM workflow should start. The system
determination is attached to the Channel ID. Thus, system determination works only
if the channel is maintained. See “Maintaining channels” on page 51. By default, if
no system determination ID is specified, the OpenText standard look up table of
Company Code and Logical System is used to determine the system.
To maintain the system determination:
1. Run the /n/OPT/VIM_SYS_DET transaction.

Scenarios > System Determination Procedure > Maintain System
Determination Procedure.
2. Click New Entries.

3. Maintain the System Determination ID, using the following parameter:
Sys Determination FM
If you want to determine the system where the VIM workflow should start
in a multiple backend system, enter a custom function module. The
interface of the function module should be compatible with /OPT/VIM_
SYSTEM_DETERMINE.
To maintain system determination based on the Company Code:
1. Run the /n/OPT/CC_LOGSYS transaction.

Scenarios > System Determination Procedure > System Determination via
Company Code.
2. Specify a mapping of company code and logical system in a multiple backend

system.

4.9. Working with ICC in a multiple backend system
4.9 Working with ICC in a multiple backend system

A multiple backend system can also include Invoice Capture Center (ICC); see
Figure 4-1: “VIM as a multiple backend system” on page 37.
On VIM side, the central system gets the invoice data from the staging tables of the
satellite systems and consolidates the data in its own staging table. Together with
the data, the central system also stores the information about the satellite system
where the data stems from.
For more information, see Section 3.3.4 “More than one SAP ERP or SAP S/4HANA
system involved” in OpenText Business Center Capture for SAP Solutions -
Customization Guide (CPBC-CGD).
ICC downloads the data to its database. This affects the following types of download
data:
Vendor data
This type of data is needed to determine the vendor ID of the invoice. This is
relevant, for example, if the vendor is only given in a satellite system. For more
information, see Section 3.4.8.2 “Specifying vendor ID detection” in OpenText
Business Center Capture for SAP Solutions - Customization Guide (CPBC-CGD).
Purchase order data
This type of data refers to the purchase order that is the basis of the invoice. The
downloaded purchase order data can be used to determine the vendor ID. For
more information, see Section 3.4.8.2 “Specifying vendor ID detection” in
OpenText Business Center Capture for SAP Solutions - Customization Guide (CPBC-
CGD).
Company code data
This type of data is needed to determine the company code of the invoice. You
must import this database table from a text file, there is no download for this
database table. You must prepare the text file manually. VIM provides only an
initial text file to start with. You must export the company code data from each
satellite system separately. The separate files must be merged manually. For
more information, see Section 3.2.5 “Company code detection” in OpenText
Business Center Capture for SAP Solutions - Customization Guide (CPBC-CGD) and
Section 3.4.11 “Specifying company code detection” in OpenText Business Center
Capture for SAP Solutions - Customization Guide (CPBC-CGD).

Chapter 5
Using the Inbound Configuration with a different

workflow
You might want to integrate ICC in an invoice processing solution different from
VIM. For this scenario, you can use the Inbound Configuration as access layer to
ICC.
The Inbound Configuration is not delivered separately. Therefore, VIM must be

installed completely with a special license agreement. It is not necessary, though, to
do the complete VIM customizing. You must only customize the Inbound
Configuration.
5.1 Overview
The Inbound Configuration provides a function module interface and a workflow
interface to the invoice processing system. VIM uses the function module interface
for mapping the extraction results into field contents of the document tables. VIM
uses the workflow interface to trigger the document processing workflow.
To integrate a different invoice processing solution, the following variants are

possible:
1. Using the mapping infrastructure in VIM and trigger a user document

processing workflow
2. Using a user mapping infrastructure, then go back to VIM, and let VIM trigger a
user document processing workflow
3. Using a user mapping infrastructure, which triggers the user document
processing workflow at the end of the mapping
See the following table for additional information about the particular variants.
Variant Support for Mapping function Workflow

multiple backend
environments
1 Yes Standard VIM Copy of WS00275269,
configured in constant MAIN_
WF_TEMPLATE
2 Yes User function configured Copy of WS00275269,
in table /OPT/VIM_MAP configured in constant MAIN_
WF_TEMPLATE

Chapter 5 Using the Inbound Configuration with a different workflow
Variant Support for Mapping function Workflow

multiple backend
environments
3 Yes User function configured Leave constant MAIN_WF_
in table /OPT/VIM_MAP TEMPLATE empty. Can be
triggered by mapping function.
Remarks
• Variant 1 is the easiest way to do it.

• Variant 2 has advantages if you cannot use the standard mapping. This can
happen because you are using many extraction fields that are not contained in
the VIM document tables /OPT/VIM_1HEAD and /OPT/VIM_1ITEM.
• Variant 3 is interesting if you do not want to use the SAP workflow engine.
5.2 Interfaces
5.2.1 Function module interface
The function module must use an interface like the VIM function module /OPT/DO_
MAPPING.
FUNCTION /OPT/DO_MAPPING.
*"-----------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(MAPPING_ID) TYPE /OPT/MAPPING_ID OPTIONAL
*" REFERENCE(DOC_ID) TYPE /OPT/DOCID OPTIONAL
*" REFERENCE(P_AREA) TYPE CHAR1 OPTIONAL
*" EXPORTING
*" REFERENCE(RC) TYPE SY-SUBRC
*" REFERENCE(I_DOC_HEADER) TYPE /OPT/VIM_1HEAD
*" TABLES
*" EXTDATA_HEAD STRUCTURE /OPT/VIM_1REXTDATA OPTIONAL
*" EXTDATA_ITEM STRUCTURE /OPT/VIM_1REXTDATA OPTIONAL
*" I_DOC_ITEMS STRUCTURE /OPT/VIM_1ITEM OPTIONAL
*" RETURN STRUCTURE BAPIRET2 OPTIONAL
*"-----------------------------------------------------------------
The function module is called in the central system after extraction and after
validation. It is also called during system determination (determination of the
backend system). This call enables you to handle the case that the backend system
depends on recognition results.
The function module is called in the target system in non-ICC scenarios. It is called
before the workflow is started (respectively when the workflow would be started if
it were configured).
The call point is provided in the parameter P_AREA with the following values:
• E - source system: extraction

• V - source system: validation
• S - source system: system determination

5.2. Interfaces
• X - target system: non-ICC scenario

• W - target system: before the workflow is started or if no workflow is configured
Data tables The document number is given as a parameter, except in the case where the function
is called for system determination. Existing data for the document can be found in
the corresponding table /OPT/VIM_1HEAD or in the business object /OPT/V1001.
The recognition results for field types Header and Item are provided in the tables
EXTDATA_HEAD and EXTDATA_ITEM.
Further recognition results or validation results can be found in the database table /
OPT/VIM_1EXT_H.
Error handling The function module may return messages, which are written to the application log.
If the return table contains error messages, and the flag to ignore mapping errors in
table /OPT/VIM_CHNL is not active, the Inbound Configuration sets the document to
status 84 (Mapping Error). The processing of the document is stopped. You can
continue the processsing by a manual interaction using the ICC admin tool.
Note: There is a return parameter rc present in the function, but it is not used.
5.2.2 Standard VIM mapping in the user function

If you want to call the VIM standard function inside your own function, you must
take the relevant coding from /OPT/DO_MAPPING into your function module. You
cannot call /OPT/DO_MAPPING itself because that would end up in an infinite loop.
MOVE mapping_id TO v_mapping_id.
SELECT SINGLE mapping_fm INTO l_fm FROM /opt/vim_map

WHERE mapping_id = mapping_id.
* Map header data
PERFORM get_doc_data_from_ext_new IN PROGRAM /opt/saplvim_icc
TABLES extdata_head return
CHANGING v_mapping_id
i_doc_header
.
* check - is there any errors in mapping the header data

READ TABLE return INTO l_return WITH KEY type = 'E'.
* Map item data
IF NOT sy-subrc IS INITIAL.
PERFORM get_doc_item_from_ext_new IN PROGRAM /opt/saplvim_icc
TABLES extdata_item i_doc_items
return extdata_head
CHANGING v_mapping_id. .
ENDIF.
* Begin of Insert VIM 5.2 HF5

* Synchronize item texts after mapping
DATA: ls_item TYPE /opt/vim_1item.
LOOP AT i_doc_items INTO ls_item.
* MOVE 'DO_MAPPING' to ls_item-sgtxt.

IF ls_item-sgtxt IS INITIAL.
IF NOT ls_item-maktx IS INITIAL.
MOVE ls_item-maktx TO ls_item-sgtxt.
MODIFY i_doc_items FROM ls_item.
ENDIF.
ELSE.
IF ls_item-maktx IS INITIAL.
MOVE ls_item-sgtxt TO ls_item-maktx.
MODIFY i_doc_items FROM ls_item.
ENDIF.
ENDIF.
ENDLOOP.
* End of Insert VIM 5.2 HF5
ENDIF.
5.2.3 Workflow interface

The workflow interface is started in the central system using RFC. That means, the
interface runs in the target system. The workflow interface is used if the constant
MAIN_WF_TEMPLATE is set in the target system.
The workflow container contains many elements, but only very few of them will
have values when the workflow is started.
The following screenshot shows an example. The only element that is useful at the
beginning is the reference to the index document.

5.2. Interfaces
When the workflow has been started successfully, the document is set to a final
status in the Inbound Configuration. That means status 00 if the document stays in
the central system, and status 77 if it was sent to a target system. The same status
handling is applied when no workflow is configured.
If you want to use this interface, copy the VIM main workflow WS00275269 using
the PFCP transaction, and build your user workflow.
Error handling It is not possible to return an error status from the started workflow. The Inbound
Configuration does not monitor the workflow status.

5.3 Tables and structures

The following tables and structures are used for the document handling in the
Inbound Configuration.
5.3.1 Configuration tables

/OPT/VIM_SYS_LD
System landscape directory. It is used in multiple backend environments.
/OPT/VIM_CHNL
Channel table. It is used to find the mapping ID for the channel. It contains the
Ignore Mapping Error flag to control error handling.
/OPT/VIM_MAP
Mapping ID. It is used to determine the mapping procedure (VIM standard or
user specific).
/OPT/VIM_T109_N
Mapping control table. It is used to determine field mapping. It contains a user
exit for each field.
5.3.2 Transaction tables

/OTX/PF01_T_1EXT
External results. Recognition and validation results are stored in this table before
the mapping interface is called. You can refer to this table using the registration
number.
/OPT/VIM_1HEAD
DP document header. The workflow that is associated to the early archiving of
the document using the SOA0 transaction creates an entry in this table. When the
mapping interface is called, a table entry contains the reference to the image,
scan date, and related data. VIM standard mapping adds recognition result data
to the table entry.
/OPT/VIM_1ITEM
DP document items. This table is filled by VIM standard mapping.
/OPT/VIM_1LOG
Log table for VIM dashboard. This table contains the status changes and error
messages.
SLG1
SAP Application Log. VIM writes application log entries using object /OPT/VIM,
subobjects ICC, ICC_TEXT and ICC_CUSTOM. The following log entry is written in
subobject ICC_CUSTOM, when the customer mapping function is called:

5.4. Log points
The message text shows the mapping ID and the call point.
5.3.3 Structures
/OPT/VIM_1REXTDATA
This structure is used for the recognition results that are presented to the
mapping interface. It consists of a field name (50 characters, case-sensitive) and
of a field value (255 characters, case-sensitive).
5.4 Log points

In Document Processing, there are some log points that are used when the customer
mapping function module is called.
To add log points 69 and 70:
1. Run the /OPT/IT_LOG_PNTV transaction.
2. Add log points 69 and 70, as shown in the following screenshots.

Log point 69:

Log point 70:
The log entry has the document number as key (external ID in SLG1) and prints
the mapping ID and the call point as information text.
5.5 Customizing VIM and Inbound Configuration

If you are using the Inbound Configuration, you must customize only some parts of
VIM.
• You have to schedule the background jobs for the Inbound Configuration and for
the ICC download. For more information, see Section 7.2 “Scheduling batch jobs
for data download from SAP S/4HANA for ICC integration” in OpenText Vendor
Invoice Management for SAP Solutions - Administration Guide (VIM-AGD) and
Section 2.2 “Batch jobs for Inbound Configuration” in OpenText Vendor Invoice
Management for SAP Solutions - Administration Guide (VIM-AGD).

5.5. Customizing VIM and Inbound Configuration
• In the VIM Invoice Configuration (/n/OPT/SPRO transaction) you need the

following nodes:
– OpenText Vendor Invoice Management Invoice Solution> Document

Processing Configuration> General Configuration> Incoming Document
Processing> ICC Configuration
– OpenText Vendor Invoice Management Invoice Solution> Document
Processing Configuration> General Configuration> Multi-Backend
Scenarios

Chapter 6
Validating invoices in ICC or indexing in VIM?
Validation The OCR recognition server extracts values from the invoice document. After this
background step, the result can be verified and potentially corrected using the
Validation Client for SAP® Solutions (Validation Client). The ICC Validation Client
is a separate tool that connects to SAP S/4HANA and VIM to retrieve one invoice
image after the other for validation.
Validation is not a mandatory step. You can configure the system to perform
validation on all invoices, only on some invoices (for example, if specific fields are
missing), or to even skip this step completely.
Leasing Starting with IES 16.7 and BCC/ICC 16.7, leasing invoices are supported by the
invoices OpenText OCR solution. To differentiate between leasing invoices and other
invoices and documents, a new classification field is mapped from OCR extraction
and/or validation into VIM. In the Validation Client, the field is represented as a list
with the following values:
• 01 - supplier invoice
• 02 - leasing invoice
If the OCR is not determining the correct invoice type, the user who validates must
set the correct value.
Indexing The invoice data fields can also be changed inside VIM in the VIM indexing screen.
The VIM indexing screen provides the advantage that it runs inside SAP and
therefore has access to SAP search helps and context data for the invoice.
The VIM indexing screen provides a viewer plug-in with similar features as the ICC
Validation Client: Values that have been identified by OCR are highlighted. Other
values can be transferred into VIM indexing fields by single click entry. To use this
feature, a SAP GUI plug-in must be installed on the client PC.
MIRO As a third option, you could use neither the ICC Validation Client nor the VIM
indexing screen but complete data in the MIRO transaction. To access MIRO, click the
Post Invoice process option on the VIM indexing screen. There is a disadvantage,
however: MIRO does not support highlighting of invoice data on the invoice image.
This section provides some information to help you decide which tool is better
suited for your requirements. It also gives some hints on the necessary
configuration.
An important goal is that the invoice is touched only once during the whole process.
You can specify validation rules in a way that no VIM exception will be raised if
possible.

Chapter 6 Validating invoices in ICC or indexing in VIM?
6.1 Some background about the tools

ICC Validation Client
• In the validation screen, you jump from input field to input field pressing the
TAB key. When you are finished, you go on to the next invoice (Submit and
Open button). The order of invoices is chosen by the system. You cannot choose
invoices by yourself.
For more details on navigation in the ICC Validation Client, see Section 3.15
“Capturing data using the keyboard” in OpenText Validation for SAP Solutions -
User Guide (CPBC-UGD) and Section 3.18 “Working with table fields” in
OpenText Validation for SAP Solutions - User Guide (CPBC-UGD).
• Depending on the configuration of the ICC Validation Client, the Mark for
Training button is available. Using it might help to improve the recognition
results. For more information, see Section 3.11 “Marking documents for training
(only BCC)” in OpenText Validation for SAP Solutions - User Guide (CPBC-UGD)
and Section 2.6 “Training” in OpenText Business Center Capture for SAP Solutions -
VIM indexing screen
• You choose yourself which invoice you want to work on, using VIM Invoice
Workplace or the SAP inbox. This approach provides flexibility in invoice
selection.
6.2 Deciding which tool to use

You must consider some aspects of validation and data entry to decide if you use the
ICC Validation Client or the VIM indexing screen.
Generally, ICC validation addresses companies with dedicated teams of processors,

focusing on recognition details and maybe training. On the other hand, VIM
indexing addresses companies with few processors preferring few user interfaces,
and focusing on the reference to SAP data (for example, purchase order and vendor).
• You might want to validate only a part of the incoming invoices. This needs to be
configured in the validation determination by assigning archive document types
to validation groups.
• The decision also must consider the users who will perform the task, for example
their experience in working with an SAP S/4HANA environment.
The user’s background also plays an important role. An accountant might prefer
working in the VIM indexing screen because they can jump to SAP S/4HANA
from there.
The ICC Validation Client rather addresses pure data collectors. It might be more
intuitive for users.
• There might be a risk that mandatory fields are not found during recognition.
These fields can be critical for determining the VIM document type, the user

6.3. Defining the validation determination
roles to receive the invoice, and potentially even the backend system. In this case,
ICC validation should be done for invoices where such fields are missing.
• You may want to work in one step, by not separating the validation of OCR
results and the further processing of the data in VIM. In this case, switch off
validation through the ICC validation tool. The option to use single click entry
inside the VIM indexing screen allows for quicker indexing even in this step.
• The Automation Report shows which data completion or modification have been
performed how often in which workplace. This might help for your decision. For
more information, see Section 5 “Using the Automation Report” in OpenText
Vendor Invoice Management for SAP Solutions - Reference Guide for Invoice Solution
(VIM-RGD).
• The recognition quality also plays a role when determining the tool to go on
with: How many fields have been recognized? If you have a high recognition
rate, it might make more sense to go on with the VIM indexing screen; with a low
rate, the ICC Validation Client might be more suited.
For mandatory fields, see Section 5 “Field references for Invoice Solution (Invoice
Capture Center)” in OpenText Business Center Capture for SAP Solutions -
Customization Guide (CPBC-CGD). The list of mandatory fields may vary for the
different country applications.
After you have made your decision, you must configure the validation
determination accordingly. You define validation rules that are then applied
automatically for the validation process.
6.3 Defining the validation determination

To define if and how validation is performed, you use the corresponding
customizing tools in ICC and VIM.
6.3.1 Configuring ICC validation in ICC

To decide if validation is triggered, you configure central invoice fields as
mandatory fields in the ICC settings. To do this, select the Field cannot be empty
check box. For more information, see Section 3.6.1 “Adding a field” in OpenText
Business Center Capture for SAP Solutions - Customization Guide (CPBC-CGD). The list
of mandatory fields may vary for the different country applications.
If one of the mandatory fields is empty after recognition, the ICC Validation Client
will show the field in red color. The invoice cannot be submitted without entering
data or confirming explicitly that no data can be entered. Fields which are used for
the Validation determination rule in VIM should be set to mandatory in ICC.

Chapter 6 Validating invoices in ICC or indexing in VIM?
6.3.2 Configuring ICC validation in VIM

The main customizing tool for validation is the validation determination. For more
information, see Section 5.3 “Customizing validation” in OpenText Vendor Invoice
Management for SAP Solutions - Configuration Guide for Foundation (BOCP-CGD).
• Validation determination
You create a Validation Determination ID (validation group) and link it to an
Archive Document Type. By linking to an Archive Document Type, you
configure that only invoices linked to this archive document type are selected for
validation.
For each Validation Determination ID, you can select how validation is
performed:
– Validate never
– Validate always
– Validate For Selected Fields
If you select this option, you must maintain the Validation Determination
Fields. In the baseline, the following fields are considered: BUKRS, LIFNR, and
XBLNR.
The concept is similar to the ICC settings. If one of the mandatory fields is
empty after recognition, the ICC Validation Client will be started for this
invoice.
You can also specify a custom function module. The Validate Check function
module will determine whether validation is required or not.
• Validation framework
The validation framework is used to configure validation rules. Besides
validation determination, this comprises the following configuration:
– Defining Frequently Used Default Values

– Maintaining Channel IDs
– Validating DP Documents with Mapping Error
– Assigning Validation Agents
For more information, see Section 5.3 “Customizing validation” in OpenText

Vendor Invoice Management for SAP Solutions - Configuration Guide for Foundation
(BOCP-CGD).
• During runtime, the program /OTX/PF01_P_IDF_TRIGGER runs business rules to
check if validation is required or not. If validation is required, the status of the
invoice is set to Ready for Validation. If validation is not required, the DP
workflow is started, and the invoice proceeds to the VIM indexing screen.
Depending on the rules defined for automatic posting, the invoice can be posted
automatically. In other words: For “no touch” invoices, all fields defined as

6.3. Defining the validation determination
mandatory in the VIM Validation determination rule must be delivered correctly

by ICC recognition and thus not run in exception handling in ICC Validation.

Chapter 7
Handling line items in ICC or VIM
Handling line items of invoices plays an important role for end to end automation.
The goal to reach in this context is optimizing the rate of invoices being
automatically posted. This section discusses the pros and cons of handling line items
in ICC or VIM.
Automation The following conditions define automation:
• Invoices pass touchless through ICC and VIM.

• Invoices do not need to be processed by ICC Validation.
• Invoices do not need to be processed by the VIM indexing screen.
Prerequisites There are a couple of organizational and technical prerequisites that you must
consider:
Invoice volume and complexity
• Analyze the invoice volume per vendor and find the best lever for
enhancements.
• To ensure a good cost-performance ratio, enhance recognition for standard
invoices from vendors with highest invoice volumes. Consider regular and
reliable vendors first.
• Do not focus on complex invoices which are to be processed manually
anyway because of exceptions.
Invoice quality
• Clean images without stamps and annotations

• Clean invoice layout without designer ambitions. Fields with colored or grey
background, for example, become black pixels during binary scanning and
thus disturb the reading flow.
Quality of the data downloaded from SAP S/4HANA
• Vendor data
• Recipient data
• PO data
Invoices might contain little information about the vendor. For example, US
invoices do not contain tax registration or bank account number. In this case,
it makes sense to derive the vendor from the PO.

Chapter 7 Handling line items in ICC or VIM
Scanning equipment: impact on image quality
• Scanner hardware
• Scanner parameters
ICC or VIM The basic question is: Where does it make more sense to perform line item mapping,
inside ICC or inside VIM? Here are some recommendations:
• You should avoid a setup where the same task must be performed twice.
• The VIM indexing screen provides more customizing features than the ICC
Validation. Regarding the line item mapping between invoice and PO data, ICC
provides only few customizing features whereas VIM provides much more
features. For example, mapping customer specific material numbers is usually
easier to implement in VIM.
• The decision also must consider the users who will perform the task, for example
their experience in working with an SAP S/4HANA environment.
The user’s background also plays an important role. An accountant might prefer
working in the VIM indexing screen because they can jump to SAP S/4HANA
from there.
The ICC Validation Client rather addresses pure data collectors. It might be more
intuitive for users.
7.1 ICC line item recognition

This section describes the line item recognition as performed on ICC side. Line item
recognition must be distinguished from line item mapping.
Line item recognition recognizes invoice item data, without using PO download
data. The underlying DOKuStar method for line item recognition takes text lines
found by pure OCR as a starting point.
These text lines are analyzed for occurrences of syntactical structures like table
header keywords, amounts, quantities, units of measure, phrases typical for
summarizing lines at the end of the table, and so on.
Results of this first step are used to find table header and end of table as well as
horizontal position of columns. Logical checks like calculation of unit price x
quantity = item price are also used in this second step. All this results in a list of line
items, each line item consisting of one or more text lines.
The following list shows some recognition use cases:
• PO invoices with price or quantity discrepancies

• Invoices related to multiple POs. This case should be excluded where possible.
Consider changing the process on vendor side.

7.2. Line item mapping
• Invoices with discounts and unplanned costs. For more information, see “Use
case 2: Invoices with planned or unplanned expenses” on page 75.
• PO invoices related to blanket POs (periodic delivery). For more information, see
“Use Case 3: Invoices related to blanket orders” on page 77.
ICC 7.0 introduced some new features regarding line items:
• All line items found on the invoice are delivered, also discount items and
additional costs. This is accomplished by a new customizing function for custom
line item type determination. For more information, see Section 3.4.6 “Specifying
line item processing” in OpenText Business Center Capture for SAP Solutions -
• ICC delivers the complete line item text to VIM, to allow customer specific PO
data mapping on VIM side, for example by using numeric values (like material
numbers) from the line item text.
7.2 Line item mapping

ICC ICC line item mapping (SnapMatch) tries to match recognized invoice item data
with downloaded PO details data, and if available, also GR data, for assigning a PO
number and a PO item number to every line item. For more information, see Section
3.4.6.1 “Specifying line item mapping” in OpenText Business Center Capture for SAP
Solutions - Customization Guide (CPBC-CGD).
ICC standard mapping does not use material numbers but only quantity, unit price,
total price, and, with low priority, the line item description. On VIM side, customer
specific mapping is easier to implement because ICC line item mapping provides
only limited customizing features.
VIM VIM 5.2 SP3 introduced an enhanced line item mapping. For more information, see
Section 9.1.11 “Maintaining the PO line determination” in OpenText Vendor Invoice
VIM offers basically three variants for line item matching, which can be configured
per document type:
• Setting PO
Ignore the line item data coming from ICC and derive the line item data from the
PO(s).
• Settings MO and M2
Ignore the line item data coming from ICC and derive the line item data from the
MIRO proposal.
• Settings OK and OD
Match the PO and GR data against the data provided by ICC, and, based on the
PO and GR data, completing the data in the line item fields where it is missing.

Note: Only settings OK and OD prevent VIM from adding line items to the
recognized line items.
OpenText recommends that you keep the PO header download. If the Check PO
numbers against downloaded data check box is selected in the Settings dialog box,
ICC checks if PO and vendor fit. For more information, see Section 3.4.7 “Specifying
order number processing (PO number)” in OpenText Business Center Capture for SAP
For more information about the VIM line item mapping strategy, see Section 9.11.1
“Configuring indexing line matching from OCR results” in OpenText Vendor Invoice
ICC Validation To perform the line item data handling in ICC Validation, you must adjust the VIM
rules for Validation determination. For more information, see Section 5.3
“Customizing validation” in OpenText Vendor Invoice Management for SAP Solutions -
Configuration Guide for Foundation (BOCP-CGD).
Note: Not all invoices must go to Validation.
The ICC Validation client can be customized to show line item data only for invoices,
when a PO was recognized (assumed PO invoices). You can configure this in ICC
Customizing; see OpenText Business Center Capture for SAP Solutions - Customization
Guide (CPBC-CGD).
The line item data completion can be performed in various locations:
• ICC Validation (for PO/for Non PO/for specific vendors)

• VIM indexing screen
• MIRO transaction
The use cases that are described in the following sections are only relevant for the
VIM side.
7.3 Use case 1: Invoices matching PO - highly

automated posting
This is the ideal use case. It has more organizational than technical aspects:
• A 1:1 relation between PO and invoice is required.
– Order only few items per invoice.

– Avoid price or quantity discrepancy.
– Exclude blanket POs.
• The document type configuration contains auto-posting for certain process types.
• The vendor belongs to the “white list” vendor group.

7.4. Use case 2: Invoices with planned or unplanned expenses
• For white list vendors of a certain company code range (or other definition) the
Business Rule Framework configuration contains the following
– Activation of small number of rules that are absolutely necessary

– Compliance rules are set to relaxed testing (counter 1,000 or other)
You must adjust the following VIM configuration settings:
• Document type configuration. For more information, see Section 9.1

“Configuring DP document types” in OpenText Vendor Invoice Management for
SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD) and Section 9.2
“Configuring automatic posting” in OpenText Vendor Invoice Management for SAP
Solutions - Configuration Guide for Invoice Solution (VIM-CGD).
• Business Rule Framework configuration. For more information, see Section 9.5
“Business Rule Framework” in OpenText Vendor Invoice Management for SAP
• PO line determination should be set to setting PO. For more information, see
Section 9.1.11 “Maintaining the PO line determination” in OpenText Vendor
Invoice Management for SAP Solutions - Configuration Guide for Invoice Solution
(VIM-CGD).
Important
• ICC line item data is no prerequisite for auto posting. Posting on header
level is possible if the total amounts of invoice and PO match.
• As a consequence, the ICC line item data does not need to be verified in
ICC Validation.
7.4 Use case 2: Invoices with planned or unplanned

expenses
This use case aims at automation support for specific invoices (specific business
scenarios, specific business segments). As a purpose, ICC should deliver more line
item information to VIM, for example discounts, material overhead costs, and
incidental costs. All invoice item lines, also negative items, should be delivered.
For your environment, you must customize an identifier for invoice item types. To
do this, you must create a custom phrase list. For more information, see Section
3.4.6.3 “Specifying extraction of additional costs and discounts” in OpenText Business
Center Capture for SAP Solutions - Customization Guide (CPBC-CGD).
Expenses The following screenshot shows an invoice with expenses:

1
Expenses (or discounts) related to invoice items (for example material overhead
costs)
2
Expenses (or discounts) related to all invoice items (for example transportation
costs, volume discount)
Freight The following screenshot shows the ICC Validation of an invoice including line
items with material overhead (freight).

7.5. Use Case 3: Invoices related to blanket orders
Planned and Planned and unplanned expenses are handled in the following way:
unplanned
expenses • Planned expenses are included in the PO. A mapping is possible.
• Unplanned expenses are not included in the PO. Depending on the customizing,
unplanned expenses might raise an exception.
7.5 Use Case 3: Invoices related to blanket orders

A blanket order is defined as a purchase order with multiple delivery dates over a
period of time. The PO contains the total quantity of the delivery. For every partial
delivery, an invoice is issued, for example monthly. This might lead to an exception.
Before processing the invoice, it is required to post the GR. If the GR matches the
invoice, automatic posting will succeed.
Note: In this case, you must use PO line determination setting OK or OD. Other
settings might add line items that are not on the invoice.

7.6 Secure line item number input

A customer system might not make use of goods receipts and service entry sheets.
Additionally, a high volume of invoices might be partial invoices. In this case, the
automation rate for documents coming in from ICC/BCC is bad.
Line item mapping in ICC/BCC (see “Line item mapping” on page 73) cannot be
used because there is not enough data available that could be used. So nearly all
documents must be processed manually because there are no matching criteria
available for automatic matching of invoice lines to PO items.
Starting with ICC 7.5 SP5 / BCC 16 Update 1, the following new features are
available for line item processing:
• Deliver line item number
• Secure keyword
For more information, see Section 3.4.6 “Specifying line item processing” in
CGD).
These features have been created to make use of the line item numbers coming in
from ICC/BCC. The automation rate can be increased if the item line numbers are
PO line numbers.
• A line item number exported from ICC/BCC with Deliver line item number
selected is treated as a secure line item number if the invoice vendor is on the
trusted vendor list. For more information, see Section 8.6 “Maintaining the
trusted vendor list” in OpenText Vendor Invoice Management for SAP Solutions -
• A line item number exported from ICC/BCC with Secure keyword selected is
directly treated as a secure line item number.
Technically, the secure line item numbers are handled in a subroutine for enhanced
mapping called /OPT/VIM_EXIT_MAP_SLN. This subroutine checks some
prerequisites of PO and invoice. If the following prerequisites are met, the line item
numbers coming in from ICC/BCC are populated into the line items of the invoice:
• Invoice contains exactly one PO number.
• PO is configured without invoice verification.
Notes
• Posting of input with secure line item numbers is done with amount and
quantity coming in from ICC/BCC. This is important especially in the case of
partial invoices.

7.6. Secure line item number input
• You have to use setting OK (see “Line item mapping” on page 73 on PO line
determination settings) to make sure that only the lines coming in from ICC/
BCC get processed and used for posting.

Chapter 8
Field references for ICC
This chapter describes recognition and processing details for the fields of invoice
applications. Most of the fields described in this chapter are created for all countries,
but do not deliver results. These fields are set to not visible in the settings. For which
country a field delivers a result is named under the tag Countries.
Note: If an entry exists for VIM internal name, the field value is visible in VIM
baseline screens or can be made visible by configuration. It can be included in
the business rule Missing mandatory information by configuration.
Statements under VIM process focus on the Business Rules or Check Rules. If
there are no business rules for a field but the field value is used elsewhere, this
is mentioned. If nothing is stated under VIM process, the VIM baseline makes
no use of this field except for showing it in the screens or checking it in
business rule Missing mandatory information.
8.1 Header fields

Bill Of Lading
Name internal / InvoiceBOL / (no field available)

VIM
Export Yes
Countries All
Validation not visible, not mandatory
BCC recognitio Customizable field.
n / format Can be activated by configuration settings. Recognition is trained on
customer's site with customer's invoices.
Training should be done for the most frequent vendors by an
administrator in Customizing Client using representative invoice images.
VIM process -
Company Code
Name internal / CompanyCode / BUKRS

VIM
Export Yes
Countries All
Validation visible, mandatory

Chapter 8 Field references for ICC
BCC recognitio Four different methods are available to determine the company code. You
n / format can use a single, fixed company code for all documents of the current
application, a separate company code for each archive document type,
you can use automatic company code detection or you can use automatic
company code detection with PO number support.
Configuration: For automatic detection, you need a database in text file

format.
VIM process The company code takes on a key function in the SAP ERP or SAP S/
4HANA system.
The company code must exist in table T001.
Recipient Name
Name internal / InvoiceRecipientName / RECIPIENT_NAME

VIM
Export Yes
Countries All
BCC recognitio Value is determined using recipient data.
n / format
Deliver OCR result by default.
Default column confidence 0.

VIM process -
Recipient Name 2
Name internal / InvoiceRecipientName2 / (no field available)

VIM
Export Yes
Countries All
n / format

VIM process -
Recipient Vat Number
Name internal / InvoiceRecipientVatID / RECEPIENT_VAT_NO

VIM
Export Yes

8.1. Header fields
Countries All
n / format

VIM process There are two business rules for this field. If a business rule fails, an
exception Invalid Recipient VAT Number is raised; for Australia an
exception Invalid Recipient ABN Number is raised.
SAP System
Name internal / System / TARGET_SYSTEM

VIM
Export Yes
Countries All
BCC recognitio Logical SAP ERP or SAP S/4HANA System.
n / format
Is determined in the same way as the company code (see description
above).
VIM process Target SAP ERP or SAP S/4HANA system to which the document shall be
transferred.
Reference Number (Invoice Number)
Name internal / InvoiceNumber / XBLNR

VIM
Export Yes
Countries All
BCC recognitio Vendor invoice number. This is extracted using keyword search.
n / format
For some countries with larger invoice reference numbers up to 60
characters, recognition may not work out of the box but require capturing
and training with ART.
VIM process The reference number is used as a search criterion when documents are
changed or displayed.
In correspondence, the reference number is sometimes printed in place of
the document number.
For a credit memo, Reference Number and (depending on the country)

Invoice Date must be filled. Otherwise, an exception Incomplete
Credit Memo is raised.

Invoice Date
Name internal / InvoiceDate / BLDAT

VIM
Export Yes
Countries All
BCC recognitio Invoice date is extracted using keyword search.
n / format
Check: less than one year old.
Format: display format is independent of recognized format.

VIM process Date on which the original document was issued.
When the business rule is applied, InvoiceDate must have been filled.
Otherwise an exception Missing Invoice Date is raised.
Date of Supply
Name internal / InvoiceDeliveryDate / SUPPLY_DATE

VIM
Export Yes
Countries -
Validation visible: optional, mandatory: optional
BCC recognitio This field is trained on customer's site with customer's invoices. Training
n / format should be done for the most frequent vendors using representative invoice
images showing the field. Training should be performed by an
administrator using the Customizing Client
The field is mandatory for specific countries.
Out of the box it is delivered for Germany, Austria, Switzerland and

Poland.
VIM process The supply date is transferred in the invoice header text field.
Depending on the country of the vendor address, the date of supply can
be a mandatory field.
Then the exception Missing date of supply is raised.
ESR Number
Name internal / ESRReferenceNumber / ISR

VIM
Export Yes
Countries Switzerland

8.1. Header fields
BCC recognitio Swiss payment reference number. The entire string is delivered only for
n / format Switzerland.
Format: specific format with check digit.

VIM process POR Subscriber Number derived from ICC ESR Number.
If the business rule applies and the ESR check is activated via Z-Constant
ESR_CHECK_REQUIRED, the ESR transferred from ICC is checked against
the master data.
Credit Memo
Name internal / InvoiceCreditMemo / CREDIT_MEMO

VIM
Export Yes
Countries All
BCC recognitio Determined using keywords (invoice, credit memo) This field is used to
n / format mark the document as either an invoice (“ ”) or a credit note (“X”).
The document is searched for keywords or phrases that indicate a credit

note. In all other cases, Invoice is assumed.
VIM process The Invoice type is converted.
If the Invoice Type is Credit then the field Credit Memo is clicked on. If
it's about a credit memo, the field Reference Number (and depending on
the country the Reference Date for Credit Memo) has to be filled.
Otherwise an exception Incomplete Credit Memo is raised.
Vendor Number
Name internal / InvoiceVendorNumber / LIFNR

VIM
Export Yes
Countries All

BCC recognitio Vendor master data are periodically downloaded from SAP at runtime.
n / format Therefore the Hot Spot SAP Download Link is used to fetch data from
SAP regularly (table /OPT/VIM_STG_LIF).
For vendor determination, automation method SnapMatch is used.

Following database columns are relevant:
• Company
• Company1
• Street
• PO Box
• Phone
• Fax
• Bank Account
• VAT Number
• Email
• IBAN
• S.W.I.F.T. Code
• WWW address
The search is stopped once a match is found.
If there is a match, the vendor number is copied from the vendor table into
the results file.
If there is no sufficient match, the field remains empty. Fields required for
the vendor search are by default not displayed and they are not exported
in the result file.
Format: max. 10 characters
Vendor data download by HotSpot; table /OPT/VIM_STG_LIF

VIM process The vendor number must be valid, that means a vendor master item must
exist for this number. Otherwise an exception Invalid Vendor is raised.
If a PO number is known, the system checks whether the determined

vendor is identical to the vendor in the PO. If not, an exception Vendor
mismatch is raised.
If one of the fields HSNM1, STREET, CITY1, PSTLZ, REGIO, or LAND1

does not match with the corresponding field of the vendor master, an
exception Vendor Address Mismatch (PO) or Vendor Address
Mismatch (NPO)
is raised.
Vendor Name
Name internal / InvoiceVendorName / VEND_NAME

VIM
Export Yes

8.1. Header fields
Countries All
BCC recognitio Value is determined using downloaded vendor master data.
n / format
Must be contained in vendor data download.

VIM process Vendor name from ICC is transferred into this field. By modifying the
index data manually, the vendor name will be refreshed from the vendor
master.
Vendor Name 2
Name internal / InvoiceVendorName2 / (no field available)

VIM
Export Yes
Countries All
n / format

VIM process -
Vendor VAT Number
Name internal / InvoiceVatID / VENDOR_VAT_NO or PAN_NO

VIM
Export Yes
Countries All
Validation visible, not mandatory
n / format
Deliver database entry checked by OCR by default.

VIM process VAT number is checked against the vendor master data.
If the value does not match the VAT registration number (field LFA1-
STCEG) in the vendor master data, an exception Invalid Vendor VAT
No. is raised.
Australia: If value does not match the VAT registration number (field
LFA1-STCEG) in the vendor master data, an exception Invalid Vendor
ABN No. is raised.
India: If the business rule fails, an exception Missing Vendor PAN

Number or Mismatch Vendor PAN Number is raised.
Vendor VAT Number 1
Name internal / InvoiceVatID1 / VENDOR_TAX_NO or STC_NO

VIM
Export Yes
Countries All
n / format

VIM process France: If business rule fails, an exception Invalid Siret Number is
raised.
India: If business rule fails, an exception Missing Vendor STC Number

or Mismatch Vendor STC Number is raised.
Vendor VAT Number 2
Name internal / InvoiceVatID2 / TIN_TOT

VIM
Export Yes
Countries All
n / format

VIM process India: If business rule fails, an exception Missing Vendor TIN/TOT
Number or Mismatch Vendor TIN/TOT Number is raised.

8.1. Header fields
Vendor VAT Number 3
Name internal / InvoiceVatID3 / LST_NO or GST_REG_NUM

VIM
Export Yes
Countries All
n / format

VIM process India: If business rule fails, an exception Missing Vendor LST Number
or Mismatch Vendor LST Number is raised.
If business rule for GST_REG_NUM fails. an exception Missing/

Invalid Vendor GST Reg.No (PO/NPO) is raised.
Vendor VAT Number 4
Name internal / InvoiceVatID4 / CST_NO

VIM
Export Yes
Countries All
n / format

VIM process India: If business rule fails, an exception Missing Vendor CST Number
or Mismatch Vendor CST Number is raised.
Vendor VAT Number 5
Name internal / InvoiceVatID5 / ECC_NO

VIM
Export Yes
Countries All


n / format

VIM process India: If business rule fails, an exception Missing Vendor ECC Number
or Mismatch Vendor ECC Number is raised.
Vendor Bank Account Number
Name internal / InvoiceVendorBankAccount / BANKN

VIM
Export Yes
Countries All
n / format

VIM process Value is used to determine the partner bank type.
Vendor Bank Name
Name internal / InvoiceVendorBankName / BANKA

VIM
Export Yes
Countries All
n / format

Vendor Bank Number
Name internal / InvoiceVendorBankNumber / BANKL

VIM
Export Yes

8.1. Header fields
Countries All
n / format

Vendor City
Name internal / InvoiceVendorCity / REMIT_AD_CITY1

VIM
Export Yes
Countries All
n / format

VIM process Check rule: field has to match the city of the vendor master data.
Otherwise an exception Vendor Address Mismatch is raised in the DP
workflow.
Vendor IBAN
Name internal / InvoiceVendorIBAN / IBAN

VIM
Export Yes
Countries All
n / format


Vendor POBOX
Name internal / InvoiceVendorPOBOX / (no field available)

VIM
Export Yes
Countries All
n / format

VIM process -
Vendor POBOXZIP
Name internal / InvoiceVendorPOBOXZIP / (no field available)

VIM
Export Yes
Countries All
n / format

VIM process -
Vendor State
Name internal / InvoiceVendorState / REMIT_REGIO

VIM
Export Yes
Countries All
n / format

8.1. Header fields
VIM process Check rule: field has to match the region code of the vendor master data.
Otherwise an exception Vendor Address Mismatch is raised in DP
workflow.
Vendor Street
Name internal / InvoiceVendorStreet / REMIT_STREET

VIM
Export Yes
Countries All
n / format

VIM process Check rule: field has to match the street of the vendor master data.
workflow.
Vendor SWIFT
Name internal / InvoiceVendorSWIFT / SWIFT

VIM
Export Yes
Countries All
n / format

Vendor ZIP
Name internal / InvoiceVendorZIP / REMIT_PSTLZ

VIM
Export Yes
Countries All


n / format

VIM process Check rule: field has to match the zip code of the vendor master data.
workflow.
PO Number
Name internal / InvoiceOrderNumber / EBELN

VIM
Export Yes
Countries All
BCC recognitio Optionally, PO numbers can also be checked against the downloaded
n / format purchase orders. Only purchase orders with matching company code,
vendor number, and SAP ERP or SAP S/4HANA target system are
checked.
Maximum: 10 characters.
PO download by SAP Download Link
Table:
/OPT/VIM_STG_POH (header),
/OPT/VIM_STG_POI (items)
VIM process If a PO Number is transferred, VIM processes the invoice as PO invoice.
Otherwise, the NPO VIM process starts.
Purchase Order must exist in table EKKO; otherwise an exception Invalid

PO number (PO) is raised in DP workflow.
If there is a ReleaseGroup in PO, the PO must be released or an

exception PO is not released is raised.
PO Number is used to determine the company code and the DP document

type.
PO Number is used in automatic and manual line item matching to find

out the relevant items of the invoice.
PO Number List
Name internal / ListPO / EBELN (in table /OPT/VIM_1PO_DN)

VIM
Export Yes

8.1. Header fields
Countries All
BCC recognitio -
n / format
VIM process PO Number List is used in automatic and manual line item matching to
find out the relevant items of the invoice.
Delivery Note List
Name internal / ListDN / LFSNR (in table /OPT/VIM_1PO_DN)

VIM
Export Yes
Countries All
BCC recognitio If a PO was found, the contents of the column DELIVERY for that PO (in
n / format the PO database) are searched on the invoice.
If the option Do not check against PO is enabled, all contents of the

column DELIVERY (in the PO database) of all POs from the found vendor
and company code are searched on the invoice. Enable this option only if
each of your vendor is associated exactly to only one company code.
The result of the search is filled into this field.

VIM process DN note list is used in automatic and manual line item matching to find
out the relevant items of the invoice.
Requester Email
Name internal / InvoiceRequesterEmail / EMAIL_ID

VIM
Export Yes
Countries -
BCC recognitio Valid requestor email addresses have to be specified in the application
n / format settings.
ICC matches recognized email addresses against specified items.
Format: [email protected], maximum: 255 characters

VIM process Only the first 80 characters are considered.
Check rule: If Email- ID does not exist in table /ORS/USERMAP, the

exception Invalid Requester ID is raised.

Gross Amount
Name internal / InvoiceTotalAmount / GROSS_AMOUNT

VIM
Export Yes
Countries All
BCC recognitio All amount fields are searched as a group. Net amount, tax rates, tax
n / format amounts, gross amount, and currency are recognized. The different
amounts and tax rates are checked against the gross amount.
With country setting Brazil, for NFS-e invoices only the currency Real is
valid and tax amounts are not extracted.
VIM process Check rule: all amount values must be numeric.
Amounts are converted to internal currency (local currency).
Net Amount
Name internal / InvoiceNetAmount / NET_AMOUNT

VIM
Export No
Countries All
BCC recognitio Net amount and other amount values are checked against gross amount
n / format during recognition.
VIM process -
Currency
Name internal / InvoiceCurrency / WAERS

VIM
Export Yes
Countries All
BCC recognitio This field contains the currency symbol. The recognized currency code is
n / format converted to the corresponding ISO 4217 code.
ICC searches currencies in the neighborhood of amount values. It searches

only for currencies that are configured in the application settings.
If a dollar sign is found, no currency is returned because it cannot be

determined whether the dollar sign indicates currency AUD, CAD, HKD,
or USD.

8.1. Header fields
VIM process Check rule: The currency must exist in SAP ERP or SAP S/4HANA
tableTCURC and it must match the currency of the PO. Otherwise an
exception Invalid Currency or Currency Mismatch is raised in the
DP workflow.
If ICC does not deliver a currency, VIM tries to fill the field from PO.
VAT Amount
Name internal / InvoiceVatAmount / VAT_AMOUNT

VIM
Export Yes
Countries All, except Brazil
BCC recognitio This field contains the VAT amount if only one VAT amount has been
n / format found on the invoice.
VIM process Used in check rules for exceptions Invalid Tax Info
VAT Amount 1
Name internal / InvoiceVatAmount1 / TAXAMT_1

VIM
Export Yes
BCC recognitio This field contains the VAT amount if only one VAT amount has been
VIM process -
VAT Amount 2

VIM
Export Yes
BCC recognitio This field contains the VAT amount if two VAT amounts have been found
n / format on the invoice.
VIM process -

VAT Amount 3

VIM
Export Yes
BCC recognitio This field contains the VAT amount if three VAT amounts have been
VIM process -
VAT Amount 4

VIM
Export Yes
BCC recognitio This field contains the VAT amount if four VAT amounts have been found
n / format on the invoice.
VIM process -
Total Tax Amount
Name internal / InvoiceTotalTaxAmount / TOT_TAX_AMOUNT

VIM
Export Yes
Countries US
BCC recognitio Restriction to a single amount field, applicable for US only.
n / format
This field contains the tax amount.
VIM process If Auto Calc is filled, then Tax/Amount is ignored. This is SAP ERP or SAP
S/4HANA standard behavior.
If VAT amount / tax amount is not filled, no auto-calc is active and no tax
code can be determined, an exception Invalid Tax Info is raised.
Canadian Goods Tax Amount
Name internal / InvoiceVatAmountGST / TAXAMT_1

VIM
Export Yes

8.1. Header fields
Countries Canada
BCC recognitio Found Canadian goods tax amount, according to the customized tax rate.
n / format
VIM process Used in Tax Code Determination for Canada.
Canadian Harmonized Tax Amount
Name internal / InvoiceVatAmountHST / TAXAMT_3

VIM
Export Yes
Countries Canada
BCC recognitio Found Canadian harmonized tax amount, according to the customized tax
n / format rate.
Canadian Provincial Tax Amount
Name internal / InvoiceVatAmountPSTQST / TAXAMT_2

VIM
Export Yes
Countries Canada
BCC recognitio Found Canadian provincial tax amount, according to the customized tax
n / format rate.
VAT Rate
Name internal / InvoiceVatRate / ZERO_TAX_RATE

VIM
Export Yes
Countries All, except Canada
BCC recognitio Tax rates (percentage) implemented for all supported countries.
n / format

VIM process VIM transforms tax rate to SAP tax code depending on SAP customizing.
If the Tax/VAT rate is not filled and Zero-Tax-rate is not allowed, the
exception Invalid Tax Info is raised.
Allow Zero tax rate is for allowing VIM to recognize physical value 0
as a valid tax rate.
VAT Rate 1
Name internal / InvoiceVatRate1 / TAXRATE_1

VIM
Export Yes
n / format
VIM process -
VAT Rate 2

VIM
Export Yes
n / format
VIM process -
VAT Rate 3

VIM
Export Yes
n / format
VIM process -

8.1. Header fields
VAT Rate 4
Name internal / InvoiceVatRate / TAXRATE_4

VIM
Export Yes
n / format
VIM process -
Canadian Goods Tax Rate
Name internal / InvoiceVatRateGST / TAXRATE_1

VIM
Export Yes
Countries Canada
BCC recognitio Found Canadian goods tax rate, according to the customized rate.
n / format
Canadian Harmonized Tax Rate
Name internal / InvoiceVatRateHST / TAXRATE_3

VIM
Export Yes
Countries Canada
BCC recognitio Found Canadian harmonized tax rate, according to the customized rate.
n / format
Canadian Provincial Tax Rate
Name internal / InvoiceVatRatePSTQST / TAXRATE_2

VIM
Export Yes
Countries Canada

BCC recognitio Found Canadian provincial tax rate, according to the customized rate.
n / format
VIM process Used in Tax Code Determination for Canada
Freight Amount
Name internal / InvoiceFreightAmount / FREIGHT_AMOUNT

VIM
Export Yes
Countries -
n / format
Can be activated by configuration settings. Recognition is trained on

administrator in the Customizing Client using representative invoice
images.
VIM process Freight Amount is checked by table WebflowConstantTable (/ptgwfi/
z_const). If tolerance limit is exceeded, an exception is raised.
Freight Amount and Handling charges both are for unplanned costs, but
they refer to different costs. Handling charges in turn points to labor costs
etc., which is different to freight costs or freight amount. Together these
fields provide a break-up of unplanned costs.
Handling Charges
Name internal / InvoiceHandlingCharges / HANDLING_CHARGES

VIM
Export Yes
Countries -
n / format
Can be activated by configuration settings. Recognition is trained on

administrator in Customizing Client using representative invoice images.
VIM process Freight Amount and Handling Charges are booked in all as unplanned
delivery costs in MIRO.

8.1. Header fields
Payment Reference
Name internal / InvoicePaymentReference / KIDNO

VIM
Export Yes
Countries Scand. 1)
BCC recognitio Special Scandinavian reference number.
n / format
VIM process Used in check rule for exceptions Invalid Payment Reference.
1) Denmark, Finland, Norway, Sweden
Tax Invoice
Name internal / TaxInvoice / TAX_INVOICE

VIM
Export Yes
Countries Australia, Ind. Singapore, New Zealand
BCC recognitio Keyword “Tax Invoice” on the specified countries above.
n / format
VIM process -
Invoice Code
Name internal / InvoiceCode / INVOICE_CODE

VIM
Export Yes
Countries China
BCC recognitio Formula type number.
n / format
VIM process China: Used in check rule for exceptions Missing/Invalid Invoice
Code
Invoice Category
Name internal / InvoiceCategory / CLASSIFIER

VIM
Export Yes
Countries All countries


BCC recognitio 01 Down payment
n / format 02 VAT invoice goods[a][b]
03 VAT invoice services[a][b]
04 Revision invoice goods[a]
05 Revision invoice services[a]
06 Correction invoice goods[a]
07 Revision of correction invoice (goods)[a]
08 TORG12 (goods)[a][b]
09 Acceptance ACT services[a][b]
10 Proforma invoice[a]
11 Import invoice[a]
12 Combination of VAT invoice (goods) + TORG12[a][b]
13 Combination of VAT invoice services + ACT[a][b]
14 Nota fiscal de serviços eletrônica[b][c]
20 VAT special[b][d]
21 VAT common[b][d]
22 Non-VAT[b][d][e]
23 Transport[b][d]
24 Import[d]
25 Other
26 Triangulation[d]
VIM process All countries: Used in preprocessing and check rules for several
exceptions.
[a] Only Russia
[b] This categorie is delivered by the automatic classification.
[c] Only Brazil
[d] Only China
[e]
The following subcategories are classified as 22 Non-VAT out of the box in a China (Mainland)
application: Construction, Insurance, Service
In ICC, the field contains the text string in the language of the application whereas
the corresponding number is transferred to VIM.
Secret Code
Name internal / InvoiceSecretCode / (no field available)

VIM
Export Yes
Countries China
BCC recognitio Tax number of the invoice.
n / format
VIM process -

8.1. Header fields
Secret Code 1
Name internal / InvoiceSecretCode1 / SECRET_CODE1

VIM
Export Yes
Countries China
BCC recognitio Second tax number of the invoice.
n / format
VIM process China: Used in check rule for exceptions Missing/Invalid
Characters in Secret Code
Secret Code 2

VIM
Export Yes
Countries China
BCC recognitio Third tax number of the invoice.
n / format
Characters in Secret Code.
Secret Code 3

VIM
Export Yes
Countries China
BCC recognitio Fourth tax number of the invoice.
n / format
Secret Code 4

VIM
Export Yes
Countries China


BCC recognitio Fifth tax number of the invoice.
n / format
GST Partner
Name internal / InvoiceGSTPartnerNumber / GST_PART

VIM
Export Yes
Countries India
BCC recognitio GST Partner Number
n / format
VIM process India: If business rule for GST_PART fails, an exception Missing/
Invalid GST Partner (PO/NPO) is raised.
Excise Duty
Name internal / InvoiceExciseDuty / EXC_DUTY

VIM
Export Yes
Countries India
BCC recognitio Excise duty amount on the invoice.
n / format
VIM process -
Education Cess
Name internal / InvoiceEducationCess / EDC_CESS

VIM
Export Yes
Countries India
BCC recognitio Education cess amount on the invoice.
n / format
VIM process -

8.1. Header fields
S&H Education Cess
Name internal / InvoiceSAHECess / SAHE_CESS

VIM
Export Yes
Countries India
BCC recognitio S&H education cess amount on the invoice.
n / format
VIM process -
Place Of Supply
Name internal / InvoiceplaceOfSupply / PLC_SUP

VIM
Export Yes
Countries India
BCC recognitio No automatic extraction.
n / format
VIM process -
Remit-To Address: House No

Supplier's address to which the billing should happen.For US invoices only.
Name internal / RemitHouseNumber / REMIT_HSNM1

VIM
Export Yes
Countries US
BCC recognitio Identify from invoice.
n / format
VIM process Check rule: field has to match with the House No of vendor master.
workflow.
Remit-To Address: Street

Supplier's address to which the billing should happen.For US invoices only.
Name internal / RemitStreet / REMIT_STREET

VIM

Export Yes
Countries US
n / format
VIM process Check rule: field has to match with the Street of vendor master. Otherwise
exception Vendor Address Mismatch is raised in DP workflow.
Remit-To Address: City

Supplier's address to which the billing should happen. For US invoices only.
Name internal / RemitCity / REMIT_AD_CITY1

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match with the City of vendor master. Otherwise
exception Vendor Address Mismatch is raised in DP workflow.
Remit-To Address: ZIP

Name internal / RemitZIP / REMIT_PSTLZ

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match with the Postal Code of vendor master.
Otherwise exception Vendor Address Mismatch is raised in DP
workflow.
Remit-To Address: Country

Name internal / RemitCountry / REMIT_LAND1

VIM

8.1. Header fields
Export Yes
Countries US
n / format
VIM process Check rule: field has to match with the Country of vendor master.
workflow.
Remit-To Address: Region

Name internal / RemitRegion / REMIT_REGIO

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match with the Region of vendor master.
workflow.
Ship-To Address: House No

For US invoices only.
Name internal / ShipHouseNumber / SHIPTO_HSNM1

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match the House No of company code master
data. Otherwise an exception Invalid Company Address is raised in
DP workflow.
Ship-To Address: Street


Name internal / ShipStreet / SHIPTO_STREET

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match with the street of company code master
DP workflow.
Ship-To Address: City

Name internal / ShipCity / SHIPTO_AD_CITY1

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match the city of company code master data.
Otherwise an exception Invalid Company Address is raised in DP
workflow.
Ship-To Address: Postal Code

Name internal / ShipZIP / SHIPTO_PSTLZ

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match the zip code of company code master data.
Otherwise an exception Invalid Company Address is raised in DP
workflow.
Ship-To Address: Country


8.1. Header fields
Name internal / ShipCountry / SHIPTO_LAND1

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match the country code of company code master
DP workflow.
Ship-To Address: Region

Name internal / ShipRegion / SHIPTO_REGIO

VIM
Export Yes
Countries US
n / format
VIM process Check rule: field has to match the region code of company code master
DP workflow.
Ship-To Address: Original Invoice Date

For Russian invoices only.
Name internal / InvoiceDateOriginalInvoice /

VIM
Export Yes
Countries Russia
BCC recognitio This field is searched in a Russian application for the corrective invoices.
n / format
VIM process -
Ship-To Address: Original Invoice Number


Name internal / InvoiceNumberOriginalInvoice /

VIM
Export Yes
Countries Russia
BCC recognitio This field is searched in a Russian application for corrective invoices.
n / format
VIM process -
Ship-To Address: Contract Number

Name internal / InvoiceContractNo /

VIM
Export Yes
Countries Russia
BCC recognitio This field is searched in a Russian application for TORG12 invoices.
n / format
VIM process -
Ship-To Address: Consignor Name

Name internal / InvoiceConsignorName /

VIM
Export Yes
Countries Russia
BCC recognitio This field is searched in a Russian application for VAT invoice goods.
n / format
VIM process -
Ship-To Address: Consignor Address

Name internal / InvoiceConsignorAddress /

VIM
Export Yes

8.1. Header fields
Countries Russia
n / format
VIM process -
Ship-To Address: Consignee Name

Name internal / InvoiceConsigneeName /

VIM
Export Yes
Countries Russia
n / format
VIM process -
Ship-To Address: Consignee Address

Name internal / InvoiceConsigneeAddress /

VIM
Export Yes
Countries Russia
n / format
VIM process -
Ship-To Address: Payer Address

Name internal / InvoicePayerAddress /

VIM
Export Yes
Countries Russia

BCC recognitio This field is searched in a Russian application for TORG12 invoices.
n / format
VIM process -
SplitPayment
Name internal / SplitPayment / SplitPayment

VIM
Export Yes
Countries Poland
BCC recognitio Keyword “Mechanizm Podzielonej Płatności” on the specified countries
n / format
VIM process The field SplitPayment, when active, triggers a business rule exception
(Invoice subject for payment split).
8.2 Line item fields

Line item processing is specified in the Settings dialog at the InvoiceItems field
node.
Delivery Note Number
Name internal / ItemDeliveryNote / LFSNR

VIM
Export Yes
Countries All
BCC recognitio Depends on configuration settings for PO item mapping. Prerequisite is
n / format that PO download data also contain delivery note numbers.
Only purchase orders with matching company code, vendor number and
SAP ERP or SAP S/4HANA target system are checked.
VIM process -
HSN/SAC Code
Name internal / ItemHsnSacCode / HSN_SAC

VIM
Export Yes
Countries India

8.2. Line item fields
BCC recognitio Recognition is trained on customer's site with customer's invoices.

n / format
administrator in the Customizing Client using representative invoice
images.
VIM process If business rule fails, an exception Missing/Invalid HSN/SAC Code
(PO/NPO) is raised.
Insecure PO Line Number
Name internal / ItemNumber / EBELP_N

VIM
Export Yes
Countries All except China (Mainland), China (Traditional), Japan, Thailand, Korea
BCC recognitio Only digits
n / format
VIM process An insecure PO line number is accepted by VIM only if only a single PO
number is exported for the current invoice. If both, PO number and
insecure PO number are transferred, it is checked whether the vendor is
present in the Trusted Vendor List. If it is present, the number is treated
as secure PO line number, and the exported data from the PO line are
posted, enhanced by some data from the PO, such as tax code and unit of
measure if necessary.
Note: The Secure Vendor List is a restriction. If it is empty, there are

no restrictions. In this case, all vendors are treated as secure.
PO Number
Name internal / ItemOrderNumber / EBELN

VIM
Export Yes
Countries All

BCC recognitio ICC only accepts PO numbers consisting of 10 digits within specified
n / format ranges depending on the first two digits. By configuration, purchase order
numbers can also be mapped with downloaded purchase order data.
The order number processing is specified in configuration settings.
Only purchase orders with matching company code, vendor number, and
SAP target system are checked.
Maximum: 10 characters.
PO download.
Table /OPT/VIM_STG_POH (header)

/OPT/VIM_STG_POI (items)
VIM process Purchase Order must exist in table EKKO. Otherwise the exception
Invalid PO number (PO) is raised in DP workflow.
If there is a Release Group defined in PO, the PO has to be first released or

exception PO is not released is raised.
PO Line Number
Name internal / ItemPOLineNumber / EBELP

VIM
Export Yes
Countries All
BCC recognitio ICC extracts the invoice line items and tries to determine the PO Line
n / format Number via the downloaded purchase order data.
Matching fields are:

• Quantity
• Unit
• Amount
If there is a match in each of the three fields and the item can be clearly
determined, the PO Line number is transferred, otherwise PO line number
remains empty.
VIM process If both PO number and PO line number are transferred, no automatic
determination is performed. If the rule is applied and PO line number is
not transferred, the line item matching functions in VIM are executed.
Depending on the configuration, the following exceptions can occur:
Unable to match PO lines, Unable to determine PO line no or
Manual check needed for indexing lines

Amount
Name internal / ItemAmount / WRBTR

VIM
Export Yes
Countries All
BCC recognitio Item amount.
n / format
VIM process The amount is used in various checks and is necessary to post the invoice.
Quantity
Name internal / ItemQuantity / MENGE

VIM
Export Yes
Countries All
BCC recognitio Decimal with three decimal places
n / format
VIM process If the business rule is applied and the quantity is not transferred from ICC,
the exception Item Quantity missing is raised.
Secure PO Line Number
Name internal / ItemSecurePOLineNumber / EBELP_S

VIM
Export Yes
Countries All except China (Mainland), China (Traditional), Japan, Thailand, Korea
BCC recognitio only digits
n / format
VIM process A secure PO line number is accepted by VIM only if only a single PO
number is exported for the current invoice.
If both, PO number and secure PO line number are transferred, the

exported data from the PO line are posted, enhanced by some data from
the PO, such as tax code and unit of measure if necessary.
Unit of Measure
Name internal / ItemUnit / BSTME

VIM

Export Yes
Countries All
BCC recognitio The recognized unit is converted to SAP internal Code.
n / format
Three characters.
VIM process Check rule: If Unit of Measure is transferred from ICC, it must be defined
in table T006. Otherwise the exception Invalid UOM is raised.
Check rule: Unit of Measure must match with Unit of Measure of the PO
item.
Item Description
Name internal / ItemDescription / SGTXT

VIM
Export Yes
Countries All
BCC recognitio Up to 255 characters (alphanumeric) are transferred to SAP/VIM.
n / format
VIM process If the business rule is applied and no Item Description is transferred from
ICC, the exception Missing Item Description is raised.
Unit Price
Name internal / ItemUnitPrice / NETPR

VIM
Export Yes
Countries All
BCC recognitio Price for one piece
n / format
VIM process If the business rule is applied and the unit price is not transferred from
ICC, the exception Item unit price missing is raised.
Tax Amount
Name internal / ItemVatAmount / TAX_AMOUNT

VIM
Export Yes
Countries All except Canada

BCC recognitio Tax amount on the invoice.

n / format
VIM process The customizing table /OPT/VIM_T100 is the control table for tax
determination. For each document type you can choose whether the tax
amount should be auto calculated or entered.
For the tax determination following scenarios are possible:

• OT tax determination
• OT tax table
• OT tax logic
• Customer tax determination
• Customer tax function module
Canadian Goods Tax Amount
Name internal / ItemVatAmountGST / TAXAMT_1

VIM
Export Yes
Countries Canada
BCC recognitio Canadian goods tax amount in the items.
n / format
Canadian Harmonized Tax Amount
Name internal / ItemVatAmountHST / TAXAMT_3

VIM
Export Yes
Countries Canada
BCC recognitio Canadian harmonized tax amount in the items.
n / format
Canadian Provincial Tax Amount
Name internal / ItemVatAmountPSTQST / TAXAMT_2

VIM
Export Yes
Countries Canada

BCC recognitio Canadian provincial tax amount in the items.

n / format
Tax Rate
Name internal / ItemVatRate / ZERO_TAX_RATE1 or TAX_CODE1

VIM
Export Yes
Countries All
BCC recognitio Tax rate (percentage) recognized in item lines.
n / format
To extract tax identifiers automatically, a custom invoice items column
and rules for extracting the most frequent tax identifiers must be
implemented.
VIM process Tax rate is transferred without check from ICC to DP item field Tax Rate1.
If all line items are blank for Tax rate field, the transfer from header to
item takes place.
The Tax Code should be determined: Customizing table /OPT/VIM_T100

is the control table for tax determination. For each document type you can
choose whether the tax amount should be auto calculated or entered.
For tax determination, following scenarios are possible:

• OT tax determination
• OT tax table
• OT tax logic
• Customer tax determination
• Customer tax function module
Expense Type
Name internal / ItemQualifier / QUALIFIER

VIM
Export Yes
Countries All
BCC recognitio Item flag for additional costs and discounts.
n / format
Optional column; can be activated and customized at the InvoiceItems
field node.
VIM process Customizable processing of additional costs.

Condition Type
Name internal / ItemConditionType / COND_TYPE

VIM
Export Yes
Countries All
BCC recognitio -
n / format
VIM process -
Serial Number
Name internal / ItemSerialNumber / SERIAL_NO

VIM
Export Yes
Countries China
BCC recognitio Serial number in the items.
n / format
VIM process -

Chapter 9
Field references for IES
This section provides information about fields in Information Extraction Service

(IES).
The IES invoice scenario comes with a set of predefined invoice fields. These are
largely the same as for Invoice Capture Center (ICC). “IES header fields”
on page 123 and “IES line item fields” on page 127 describe the functionality of the
invoice fields. The configuration of the invoice fields covers the aspect of displaying
the fields in the Validation Client.
All standard invoice fields, which apply for all countries, are by default visible in the
Validation Client. You can adapt these default settings as required. Country specific
fields are by default hidden and can be configured as needed. No additional
parameters exist for standard invoice fields configuration.
Note: “Information Extraction Service” (“IES”) is used in this documentation

as a common technical term for both of the following OpenText products:
• OpenText™ Intelligent Capture for SAP® Solutions, formerly known as

OpenText™ Information Extraction Service for SAP® Solutions (IES on
premise)
• OpenText™ Core Capture for SAP® Solutions
9.1 Header fields

For a detailed description of the respective VIM business rules, see Part VI “Business
rules” in OpenText Vendor Invoice Management for SAP Solutions - Reference Guide for
Invoice Solution (VIM-RGD).
Note: Most invoice fields are extracted based on profile settings and learning.
However, some fields are not provided by the extraction and they always must
be set explicitly in the validation. Currently, there is one such field:
• DownPayment
Table 9-1: IES header fields
XML path VIM target field Description

AirWayBill AWBN_ID Air Waybill. Mapped as a list.
Document classifier:
Down payment
DownPayment CLASSIFIER Other

Chapter 9 Field references for IES

ESRNumber ISR Swiss ESR number
FreightOrder TOR_ID Freight order. Mapped as a list.
Freight settlement. Mapped as
FreightSettlement SFIR_ID a list.
IBAN. Field of step 1: not
displayed in validation.
A list of all IBAN numbers
found on the invoice. If
IBANNumber is not provided
by IES, the candidates list will
be checked against vendor
master data. If an IBAN
number from the candidates list
is found in the vendor master
data, it is put into the result
IBANCandidates IBAN field IBANNumber.
IBANNumber IBAN IBAN Number
IndiaQRIrnNumber INV_REF_NUM IRN number (India)
The following QR code fields for India without VIM target field are visible in the SAP
External Data. You can use them for the VIM mapping:
SellerGstin GSTIN of supplier (India)
GSTIN of recipient/buyer
BuyerGstin (India)
Invoice number as given by
supplier in his/her internal
DocNo system (India)
Document type, for example
invoice, credit note, debit note
DocTyp (India)
Date of the generation of
DocDt invoice (India)
Invoice value (taxable value
TotInvVal and gross tax, India)
ItemCnt Number of line items (India)
HSN Code of the main item
(the line item having the
MainHsnCode highest taxable value, India)
InvoiceAmountBlock-
DocumentCurrency WAERS Currency
InvoiceAmountBlock-Net-
Amount NET_AMOUNT Net amount

9.1. Header fields

Tax amount. If several tax
amounts are present on the
InvoiceAmountBlock- invoice, the amounts are
Taxblocks-Vat-Amount VAT_AMOUNT summed up.
InvoiceAmountBlock-
Taxblocks-Vat-Amount- Country specific tax amount
CA_GST TAXAMT_1 (Canada GST)
InvoiceAmountBlock-
CA_HST TAXAMT_3 (Canada HST)
InvoiceAmountBlock-
CA_PST TAXAMT_2 (Canada PST)
InvoiceAmountBlock-
IN_CGST TAXAMT_1 (India CGST)
InvoiceAmountBlock-
IN_IGST TAXAMT_2 (India IGST)
InvoiceAmountBlock-
IN_SGST TAXAMT_3 (India SGST)
Tax rate at the header level. If
several tax rates are present on
the invoice, only one of them is
accepted. See also description
for the VAT_AMOUNT field.
For invoices with several tax
InvoiceAmountBlock- rates, tax code determination
Taxblocks-VatRate ZERO_TAX_RATE must run at the item level.
InvoiceAmountBlock- Country specific tax rate
Taxblocks-VatRate-CA_GST TAXRATE_1 (Canada GST)
Taxblocks-VatRate-CA_HST TAXRATE_3 (Canada HST)
Taxblocks-VatRate-CA_PST TAXRATE_2 (Canada PST)
InvoiceAmountBlock- Country specific tax rate (India
Taxblocks-VatRate-IN_CGST TAXRATE_1 CGST)
Taxblocks-VatRate-IN_IGST TAXRATE_2 IGST)
Taxblocks-VatRate-IN_SGST TAXRATE_3 SGST)
InvoiceAmountBlock-Total-
Amount GROSS_AMOUNT Gross amount


InvoiceCategory INV_CAT Invoice Category (China)
InvoiceCode INVOICE_CODE Invoice Code (China, Russia)
Invoice Contract number
InvoiceContractNo CONTRACT (Russia)
InvoiceDate BLDAT Invoice date
InvoiceDateOriginalInvoice Date of original invoice
ORG_DATE (Russia)
InvoiceDeliveryDate SUPPLY_DATE Supply date
InvoiceDeliveryNote DN_LIST Delivery note list
InvoiceGstPartnerNumber GST_PART GST partner number
InvoiceNumber XBLNR Invoice reference
Number of original invoice
InvoiceNumberOriginalInvoice ORG_NUM (Russia)
InvoicePartners-CompanyCode BUKRS Company code
InvoicePartners-Supplier LIFNR Vendor number
InvoicePlaceOfSupply PLC_SUP Place of supply
InvoiceRequesterEmail EMAIL_ID Requester email
InvoiceRevisionDate REV_DATE Invoice revision date (Russia)
InvoiceRevisionDateOfCorrecti Revision date of correction
onInvoice REV_DATE_COR invoice (Russia)
InvoiceRevisionNumber REV_NUM Revision number (Russia)
InvoiceRevisionNumberOfCorr Revision number of correction
ectionInvoice REV_NUM_COR invoice (Russia)
InvoiceSecretCode1 SECRET_CODE1 Invoice secret code 1 (China)
KIDNumber KIDNO Payment reference number
Document classifier:
01 supplier invoice
LeasingClassification CLASSIFIER 02 leasing invoice
LeasingContractNumber RECNTXTOLD Leasing contract number
PONumber PO_LIST PO list
Recipient VAT registration
RecipientTaxNumber RECEPIENT_VAT_NO number


Service sheet number. Mapped
SESNumber SESNUMBER as a list.
SplitPayment SPLITPAYMENT Payment split flag (Poland)
QR code content. Not mapped
into VIM. Can be used for
SwissQRCode QRCODE extensions.
QR Bill structured information
SwissQRCode-BillInformation QR_STRUC_INFO (Switzerland)
QR IBAN. Mapped
programmatically into VIM
SwissQRCode-IBAN QRIBAN field IBAN.
SwissQRCode-
QRReferenceType QR_REF_TYP Swiss QR Code reference type
QR Bill unstructured
SwissQRCode-QRUnstructInfo QR_UNSTR_INFO information (Switzerland)
SwissQRCode-Reference ESRRE Swiss QR Code reference
Additionally, all further data is extracted from the QR Code for Switzerland. Data is not
named but numbered consecutively and provided this way. This data is visible in the SAP
External Data. You can use it for the VIM mapping.
TaxInvoice TAX_DESC Tax invoice flag
Vendor VAT registration
VendorTaxNumber VENDOR_VAT_NO number
WayBill WBN_ID Waybill. Mapped as a list.
9.2 Line item fields

For a detailed description of the respective VIM business rules, see Part VI “Business
rules” in OpenText Vendor Invoice Management for SAP Solutions - Reference Guide for
Invoice Solution (VIM-RGD).
The line item fields generally refer to all countries.
Table 9-2: IES line item fields
XML path VIM target field Description Remarks

AirWayBill AWBN_ID Air Waybill
Amount WRBTR Item amount
Country specific
tax amount
CA_GST TAXAMT_1 (Canada GST)


Country specific
tax rate (Canada
CA_GST_Rate TAXRATE1_1 GST)
Country specific
tax amount
CA_HST TAXAMT_3 (Canada HST)
Country specific
tax rate (Canada
CA_HST_Rate TAXRATE3_3 HST)
Country specific
tax amount
CA_PST TAXAMT_2 (Canada PST)
Country specific
tax rate (Canada
CA_PST_Rate TAXRATE2_2 PST)
Leasing invoice -
car registration
CarPlate CARPLATE plate number
Country of origin
CountryOfOrigin LANDX (Russia)
Country of origin
CountryOfOriginDigit digital code
alCode HERKL (Russia)
Customs
CustomsDeclarationN declaration
umber DECLARATION number (Russia)
No IES field, if
needed create as a
DeliveryNote LFSNR Delivery note custom field.
No IES field, if
needed create as a
custom field with
field type set to
Description SGTXT Document text description.
Leasing invoice -
DriverName DRIVERNAME car driver name
FreightOrder TOR_ID Freight order
FreightSettlement SFIR_ID Freight settlement
Freight settlement
FreightSettlementItem SFIR_ITEM item
Country specific
tax amount (India
IN_CGST TAXAMT_1 CGST)


Country specific
tax rate (India
IN_CGST_Rate TAXRATE1_1 CGST)
Country specific
tax amount (India
IN_IGST TAXAMT_2 IGST)
Country specific
tax rate (India
IN_IGST_Rate TAXRATE2_2 IGST)
Country specific
tax amount (India
IN_SGST TAXAMT_3 SGST)
Country specific
tax rate (India
IN_SGST_Rate TAXRATE3_3 SGST)
Item type:
Additional costs /
ItemType QUALIFIER Discount
LeasingContractNumb Leasing contract
er RECNTXTOLD number
MaterialNumber MAKTX Material number
PONumber EBELN PO number
Quantity MENGE Quantity
Serial number
SerialNumber SERIAL_NO (China)
Service sheet
SESNumber SHEET_NO number
Text SGTXT Item text
Unit BSTME Unit of measure
UnitPrice NETPR Unit price
VatAmount TAX_AMOUNT Item tax amount
VatRate ZERO_TAX_RATE1 Item tax rate
WayBill WBN_ID Waybill

Chapter 10
Processing electronic invoices
Electronic invoicing (e-invoicing) is gaining more and more acceptance. It is even

becoming mandatory in many countries. VIM provides support for electronic
invoices in Brazil for some years now. For more information, see “Scenarios for
special countries“ on page 189 > “Brazil” on page 189. With more countries
establishing their own standards of e-invoicing or building on general international
standards, VIM introduces new modules to support the process.
The new features include processing modules and configuration based on Inbound
Configuration that allow starting the VIM process with Early Archiving (OAWD file
upload) or email.
OpenText also provides an option to integrate the SAP Document Compliance

solution. This allows the process to be fully automated and supports feedback
functions required by country standards like Italian FatturaPA. For more details on
the provided functions, see “Integration with SAP Document Compliance”
on page 143.
Note: The integration with SAP Document Compliance is supported for the
Inbound Configuration scenario.
10.1 Country specific notes

This section provides country specific information, including installation notes for
special deliveries. Such deliveries allow to implement e-invoice processing with VIM
by importing a set of transports provided by OpenText outside of normal support
package cycle.
Note: The configuration steps are provided in “Configuration” on page 145.

They list country specific object names where applicable.
10.1.1 China - OFD - baseline configuration

Open Fixed layout Document (OFD) is a document format used in China for electronic
invoices. VIM Invoice Solution supports incoming invoices in OFD format. For older
versions (minimum VIM 7.5 SP4 or VIM 16.3), you can request a separate transport
delivery.
The current solution provides the support for starting a VIM process by uploading
OFD format files with Early Archiving (transaction OAWD) with Inbound
Configuration. It consists of Inbound Configuration processing classes and required
configuration.
Both PO and non-PO scenarios are supported. Invoice attachments (such as PDFs)
are supported.

Chapter 10 Processing electronic invoices
Note: VIM 7.0 IDH channel is not supported as part of baseline delivery.
10.1.1.1 ArchiveLink
The sample archiving document type /OPT/OFD is delivered for use with the
scenario.
10.1.1.2 Inbound Configuration

Channels The Channel definition OAWD_OFD is provided.
Note: These channels must be named identically with VIM input channels
described further in this chapter.
Document The Handler definition PS03OFD is provided. The steps provided for handlers are the
Handler following:
definitions
REG_VIM
Register inbound document in VIM
GETCONT
Store attached XML file in a database table of the Inbound Configuration for
later use.
PARSEXML
Parse the XML input and store the parsed values in a database table of the
Inbound Configuration.
IMG_ARCH
Archive any embedded attachments found in the XML input file.
IMG_LINK
Link the archived documents to the Inbound Configuration registration object.
PROCESSING
Finalize the Inbound Configuration process before starting the VIM workflow.
Inbound Config- Entries are provided for sample archiving document type /OPT/OFD.
uration Regis-
tration – Early If you use different document types, create the corresponding entries by using the
Archiving
provided ones as example.

10.1. Country specific notes
10.1.1.3 Configuring Invoice Solution

Channels The following predefined channel is delivered: OAWD_OFD - Document input for OFD
format.
All channels are using the following country specific mappings:
Mapping The following predefined mapping is delivered: XML_OFD - XML mapping for OFD
definition format.
All mapping definitions provided for e-invoicing scenarios are delivered along with
field enhancement configuration maintained in the sub-node for each mapping.
They provide mapping logic implemented programmatically. This mapping logic is
documented in “Mappings” on page 135.
10.1.1.4 Assigning transformations to scenarios

As mentioned in the white paper of e-invoice, you have to configure transformation
against the module PARSEXML. But as part of Chine e-invoice, there is no need to
configure the transformation. As part of this, you need to configure the following
new classes:
Module ID Module Class

PARSEXML /OPT/VIM_CL_MODULE_PARSE_OFD
GETCONT /OPT/VIM_GET_XML_CONT_FROM_OFD
Note: If you use the OAWD channel, you need to use the module GETCONT and its
relevant class.
10.1.1.5 Visualizing OFD format invoices

The visualization feature to render electronic invoices as PDF that is delivered with
VIM 7.6 / VIM 20.4 can be used with OFD invoices. In order to use that, add the
modules XML_VIS_SI and XML_VIS_CO as shown in the following screenshot:
To customize PDF Log profiles:
1. Run the /n/OPT/SPRO transaction and navigate to OpenText Vendor Invoice

Management Invoice Solution > Cross Component Configuration > PDF Log >
Maintain Customizing profiles.

2. Configure the PDF profiles XML_VIS_SI and XML_VIS_CO. For more information,
see the following screenshots:
3. The language (ZH) shown in the screenshots is a global setting for the
visualization step. If you use XML visualization for different scenarios
(countries), you need to maintain the language in further visualization
configuration settings, see the next step.
4. To define the visualization of XML, maintain the following tables:
• /OPT/VIM_XV_CODV
• /OPT/VIM_XV_ELEV
• /OPT/VIM_XV_GRPV
• /OPT/VIM_XV_SYNV
• /OPT/VIM_XV_TRAV
For more details, see “Visualization of XML invoices” on page 168. Sample
configuration is provided by OpenText. It includes element labels entered in
English. Make sure you change them to be in Chinese in the translation table /
OPT/VIM_XV_TRAV for the language ZH.

5. To display the Chinese language properly in the PDF document, maintain the
proper device type: In the view TSFDEVTY, maintain the following entry.
Adobe To be able to display the PDFs with Chinese characters correctly, you need to install
language pack the Asian and Extended Language Pack for your PDF viewer, for example Adobe
Acrobat DC, on all client (SAP GUI) workstations. For information on download and
installation, see the documentation of your PDF viewer.
10.1.1.6 Mappings
The e-invoicing solution for China provides intermediate XML mapping and final
VIM mapping.
To perform mappings:
1. To view the intermediate mapping, run the /N/OPT/XML_MAP transaction, mark

the root node eInvoice, and then double-click the node Mapping of XML data
and Semantic data:

2. To view the VIM mapping, run the /n/OPT/SPRO transaction and navigate to
Processing Configuration > General Configuration > Incoming Document
Processing > Maintain Mapping ID.
3. In the next screen, select the entry XML_OFD:
4. To view the provided entries, double-click the Field Mapping node.

5. To verify the enhanced mapping settings, double-click the Automated Field

Enhancement node:
10.1.2 Italy - FatturaPA

Starting on 1st of January 2019, electronic invoicing (e-invoicing) will become
mandatory for all B2B supplies of goods and services between parties established or
VAT-registered in Italy.
The e-invoicing process is using the Exchange System “Sistema di Interscambio”

(SDI), which will allow the Italian Revenue Agency to collect details of e-invoices.
The e-invoices must be transmitted in the format of Fattura PA, as defined by the
Italian government.

Figure 10-1: Overview of the process
Note: The interaction with the government system (connectivity / middleware)

is out of scope of the support provided by OpenText in VIM.
The current delivery provides the support for starting the VIM process by uploading
the XML files using one of the following ways:
• Early Archiving (OAWD transaction)

• Email - with Inbound Configuration
Such XML files can be received from SDI by several ways supported by the process,
like E-mail, sFTP, or through the SAP eDocument cockpit. Integration with SAP
Document Compliance is supported for automation of the process.
VIM currently supports the following scenarios with e-invoicing for Italy:
• PO based goods invoices

• Non PO invoices
• Invoice attachments (such as PDFs) are supported with Inbound Configuration.
VIM currently supports only one invoice per XML file. Invoices signed through
Aruba PEC are not supported directly: pure FatturaPA XML must first be extracted
from the signed message and then uploaded into Inbound Configuration, or the
integration with SAP Document Compliance must be used, which provides
extracted XML files for VIM.
Multiple invoices sent in one XML file are not supported.
You can implement XML invoice visualization in HTML format using the stylesheet
provided by the Italian Revenue Agency. The stylesheet must be modified to make it

work with VIM modules. For more information, see “Additional required
configuration” on page 153.
Alternatively, you can use the new visualization components to create a PDF
rendering of XML invoices. For more details, see “Visualization of XML invoices”
on page 168.
Note: OpenText currently does not provide configuration for Italian invoices.
10.1.3 Germany - XRechnung

German regulation for electronic invoicing (E-Rech-VO) mandates that, in the
future, all public sector institutions will support incoming invoices in electronic
form. The support will be implemented step by step at different levels. The
corresponding standard of the electronic invoices, XRechnung, is developed by the
Coordination Council for IT Standards (KoSIT). The XRechnung format is based on
two different XML schemas, UBL and UN/CEFACT. OpenText provides UBL
support since April 2019 (VIM 7.5 SP9 and VIM 16.3.3). UN/CEFACT support is
provided since April 2020 (VIM 7.5 SP11 and VIM 16.3.5).
The current delivery provides support for starting a VIM process by uploading XML
files with Early Archiving (OAWD transaction) or email - with Inbound Configuration.
Both PO based and Non-PO scenarios are supported. Invoice attachments (such as
PDFs) are supported with Inbound Configuration.
An example of transformation for XML invoice visualization is provided as a

separate download, to convert the XML into HTML format. That example
transformation is provided for UBL only and is currently not covered by standard
product support. The setup of the transformation is described in “Assigning
transformations to scenarios” on page 148.
Alternatively, you can use the new visualization components to create a PDF
rendering of XML invoices. For more details, see “Visualization of XML invoices”
on page 168.
Note: OpenText currently provides a limited configuration for both UBL and
CEFACT formats, with field labels only in English.

10.1.4 Germany and France - Support of ZUGFeRD and Factur-

X
ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland)/
Factur-X is a German and international specification for a format of electronic
invoices. It specifies the format of a XML file that can be added as attachment to PDF
files in PDF-A/3 format.
Both OCR engines Information Extraction Service and Business Center Capture are
able to separate the XML out of the PDF file. The XML file is then stored in table /
OTX/PF01_T_1IMG.
The following standards are supported:
• ZUGFeRD 1.0
• ZUGFeRD 2.0
• ZUGFeRD 2.1
• ZUGFeRD 2.1.1
For Information Extraction Service, there is no additional configuration needed to

activate the separation. For Business Center Capture, the separation must be
activated explicitly. For more information, see Section 3.4.17 “Specifying delivery of
ZUGFeRD/Factur-X/XRechnung files” in OpenText Business Center Capture for SAP
VIM provides new configuration options and inbound modules that simplify
processing of ZUGFeRD invoices and allow to configure inbound handlers capable
of processing different invoice formats in the same handler.
For example, in the same handler, it is possible to process XML invoices,

conventional PDF invoices, and PDF invoices with embedded XML (like ZUGFeRD).
Earlier, using an OCR step in a process started with an XML file would fail because
the step expects a PDF file to be present.
Such mixed processing is made possible with a new setting that allows the handler
to continue despite errors of a particular step, and two new handler step classes:
/OTX/PS03_CL_VIM_EXTR_EMBEDDED
A wrapper class for the standard IES extraction step that tolerates missing PDF
files when only an XML file is present
/OTX/PS03_CL_VIM_ARCH_EMBEDDED
A class to archive the XML file split from ZUGFeRD PDF
You can use the following Continue or Forward setting of an inbound step in mixed
handlers, to process both PDF and XML invoices:

A handler capable to process XML invoices, conventional PDF invoices, and

ZUGFeRD PDFs can consist of the following steps:
Continue/
Sequence Processing class Comment
Forward
/OTX/ Archiving of
1 Default
PF01_CL_MODULE_ARCHIVE images
Linking images to
2 /OTX/PF01_CL_MODULE_LINK Default
inbound object
VIM document
3 /OTX/PS03_CL_VIM_MODULE_REG Default
registration
/OTX/ OCR extraction
4 Default
PS03_CL_VIM_EXTR_EMBEDDED with IC4SAP
/OTX/
5 Default Waiting step
PF01_CL_MODULE_CC_WAIT
/OTX/ Archiving of
6 Default
PS03_CL_VIM_ARCH_EMBEDDED extracted XML
Storing archived
Continue after XML into the
7 /OPT/VIM_GET_XML_CONTENT
Error image table (pure
XML processing)
/OPT/ Continue after
8 XML mapping
VIM_CL_MODULE_PARSE_EDOC Error
Archiving of
/OTX/
9 Default extracted
PF01_CL_MODULE_ARCHIVE
attachments
Start of VIM
10 /OTX/PF01_CL_MODULE_PROCESS Default
invoice process
You can use the steps listed in the table with the inbound process initiated by image
upload, by an email, or by SAP Document Compliance integration.
Because of the different data formats being processed with the same inbound
handler, the channel override configuration must be used. For more information, see
Section 7.3.2 “Flexible channel selection” in OpenText Vendor Invoice Management for

10.1.5 Generic UBL format and delivery networks

To support more countries, OpenText releases generic UBL mappings with VIM 7.5
SP10 / VIM 16.3.4.
UBL based invoices delivered through PEPPOL network are contained within a UN/
CEFACT envelope (““Standard Business Document Header”). Such invoices must be
transferred through SAP Document Compliance that extracts the actual UBL from
the envelope. If you are not using SAP Document Compliance, such extraction must
be implemented as a project specific extension, because VIM supports pure UBL files
and does not support UN/CEFACT envelope.
Countries supported for generic UBL format:
• Netherlands
• Belgium
10.1.6 Mexico
VIM supports starting the process by uploading the Mexico XML files using one of
the following ways:
• Early Archiving (OAWD transaction)

• Email (VIM Inbound component)
VIM currently supports the following scenarios with e-invoicing for Mexico:
• PO based goods invoices

• Non PO invoices
Invoice attachments (such as PDFs) are supported with the VIM Inbound
component. VIM currently supports only one invoice per XML file. Multiple
invoices sent in one XML file are not supported.
You can implement XML invoice visualization in HTML format by creating a

customer specific transformation. Alternatively, you can use the visualization
component provided by VIM to create a PDF rendering of XML invoices. As part of
the visualization component, you can attach either simple or complex visualization
as PDFs.
To support the Mexico XML document processing, VIM provides the following
objects as part of the baseline:
Transformation
/OPT/TRANS_XML_FACTURA_MX
Handler
PS03_MXUID

10.2. Integration with SAP Document Compliance
Mapping ID
XML_MXUID
Business rules
Missing UUID Number (PO)
Missing UUID Number (NPO)
The new field LOGMX_UUID is introduced in the indexing screen which was there in
table /opt/vim_2head. This field is only activated when the country is Mexico
according to the baseline delivery.
There is a new function module to check the UUID number: /OPT/VIM_DET_PROC_

MX_UUID.
10.2 Integration with SAP Document Compliance

OpenText provides the following functions to integrate VIM with SAP Document
Compliance:
• Implementation of the BADI ES_EDOC_INCOMING to start VIM processing and to

provide navigation from eDocument cockpit into VIM.
• Navigation from VIM Analytics into eDocument cockpit
• Feedback (result, response) functions like ACCEPT or REJECT
After implementing SAP notes required for specific country scenarios and installing
the component OTBCSL38, the VIM process can be started using electronic invoices
that arrived in the SAP eDocument environment.
A manual start is possible by selecting a document in the eDocument cockpit and

clicking the Create Incoming Invoice button.
To start the VIM process automatically for currently available eDocuments, schedule
the report EDOC_BACKGROUND to run with the eDocument Process corresponding to
country scenario (for example ITINVIN for Italy) and the eDocument action INCOM_
AUTO.
For eDocuments sent into VIM, you can navigate from the eDocument cockpit into
VIM Analytics or into VIM Central Workplace depending on the processing step of
the document.
Note: Navigation into VIM Central Workplace is not possible for one specific
document. To help you to find the corresponding registration ID, the ID is
shown in a dialog box when switching transactions.
After the start of the VIM workflow, a navigation hotspot is shown in VIM Analytics
if the corresponding column is enabled:

This navigation function is provided starting with VIM 7.5 SP10 and VIM 16.3.4.
Feedback functions are performed in the following way:
Accept
Sent when an invoice is posted or parked successfully. If invoices are first
parked, or posted with a payment block, you can configure whether the message
is sent upon parking/posting or only when the invoice is posted without
payment block or released. Use the customizing view /OPT/V_EDOC2_ACT for
this.
Reject
Sent when an invoice is rejected from VIM Central Workplace, confirmed as a
duplicate, set to the Obsolete status, or when the standard Return to Vendor
function is run.
Note: When the Return to Vendor function is run, no email will be sent to
the vendor, because the email is generated by the SAP eDocument
framework if needed.
Additionally, the feedback functions are used to send the vendor determined by
VIM into the eDocument framework, to restrict access to documents based on Data
Privacy and Protection settings.
The database table /OPT/EDOC2_REG is used to store the link between the eDocument
and the VIM objects. To delete older entries from the table, OpenText provides the /
OPT/EDOC2_DATA_CLEANUP report.

10.3. Configuration
Selection screen parameters
Till date
Enter a date to delete all entries for eDocuments that were created on or before
this date.
Force cleanup
Select this check box to delete all existing entries.
Note: With entries deleted from the table, navigation and feedback functions
are not possible anymore. Therefore, only old entries for completely processed
documents must be deleted.
VIM provides a new inbound module that allows to use company code mapping of
the value as provided by SAP eDocument Framework. You can use this instead of
the standard mapping delivered with VIM, which matches company code tax ID
against the master data.
To use the new mapping module:
1. Before adding a new handler step, create a new status using the SM30
transaction, maintenance view /OTX/PF01_V_STA. Make sure there are no
conflicts, for example create the status in the range 900-999. Enter the
appropriate description for the status.
2. Add a new step to the inbound handler definition, with the class /OTX/PS03_
CL_MODULE_EDOC_CCODE. The new step must be placed before the last step
PROCESSING. In the End status column, enter the new status you have created in
Step 1 on page 145.
3. In the VIM customizing of the corresponding mapping, add a new header field
entry with the external field EdocCompanyCode and target field BUKRS.
4. If you receive the XML invoices only with SAP Document Compliance, remove
the extended mapping for BUKRS in the Automated field enhancement.
If you are using other input channels, keep the extended mapping for BUKRS.
10.3 Configuration
OpenText provides the important configuration, most of which is not project
specific. Along with this, OpenText provides sample ArchiveLink settings. That
allows to quickly set up inbound XML invoice processing through manual upload in
Early Archiving (OAWD transaction).
Note: For a description of minimal steps needed to achieve a completely

working solution, see “Quick start” on page 158.
OpenText recommends verifying that the provided settings do not introduce any
conflicts with the existing project specific configuration.

10.3.1 Provided baseline configuration

10.3.1.1 ArchiveLink sample configuration
Open Text provides sample configuration for the following archiving document
types:
/OPT/FATRA
Italy, FatturaPA
/OPT/RECHN
Germany, XRechnung
/OPT/UBL
Generic UBL format

Channels The following channel definitions are provided:
OAWD_FATRA VIM
Italian FatturaPA solution
OAWD_RECHN VIM
German XRechnung solution
OAWD_UBL VIM
Generic UBL solution
Note: These channels must be named identically with VIM input channels. For
more information, see “Email with Inbound Configuration” on page 160.
Document Two handler definitions are provided:

handler
definitions
PS03OFATRA
PS03RECHN
PS03UBL
The steps provided for handlers are the following:
REG_VIM
Register inbound document in VIM
IMG_ATUDF
Convert XML into HTML format and attach it to the Inbound Configuration
object. This step is currently provided only for the Italian solution. You need to

10.3. Configuration
maintain the name of the stylesheet used for transformation in the configuration
entry.
GETCONT
Store attached XML file in a database table of Inbound Configuration for later
use.
PARSEXML
Parse the XML input and store the parsed values in a database table of Inbound
Configuration.
IMG_ARCH
Archive any embedded attachments found in the XML input file.
IMG_LINK
Link the archived documents to the Inbound Configuration registration object.
PROCESSING
Finalize the Inbound Configuration process before starting the VIM workflow.
Inbound Config- Entries are provided for the following sample archiving document types:
uration Regis-
tration - Early • /OPT/FATRA
Archiving
• /OPT/RECHN
• /OPT/UBL
If you use different document types, create the corresponding entries by using the
provided ones as example.
10.3.1.3 VIM configuration

Channels The following predefined channels are delivered:
OAWD_FATRA
OAWD_RECHN
OAWD_UBL
All channels are using the respective country specific mappings listed in the
following.
Mapping The following predefined mappings are delivered:

definitions
XML_FATURA
XML_RECHN

XML_UBL
CEFACT
CEFACT XML Mapping
All mapping definitions provided for e-invoicing scenarios are delivered along with
field enhancement configuration maintained in the sub-node for each mapping. The
mapping definitions provide mapping logic implemented programmatically. This
mapping logic is described in “Special mapping logic” on page 156.
10.3.1.4 XML specific processing configuration

This section describes the configuration used to map the XML to VIM data. You can
perform the first two customizing activities using the view cluster /OPT/XML_MAP in
the SM34 transaction. Individual views are also provided for each activity, as
described in the following.
Assigning transformations to scenarios

You need to perform XML transformations according to country specific formats.
You can perform the assignment of the transformations in the Inbound
Configuration handler definition.
If the XML transformation name is not maintained in the step definition of the
Inbound Configuration handler, the transformation name is read from the
maintenance view /OPT/XML_TRAN_HV based on the root node in the input file.
OpenText delivers entries for FatturaPA, XRechnung, generic UBL, UN-CEFACT

version 1, and UN-CEFACT version 2 (which supports XRechnung in CEFACT
format).
For more information, see the following examples of configuring the modules for
Inbound Configuration handler:
Example 10-1: Independent handler
If using an independent handler for each format of invoice, maintain the

relevant transformation:
For XRechnung in UBL format, maintain the transformation /OPT/TRANS_XML_

EDOC_UBL or /OPT/TRANS_XML_RECHNUNG_UBL.
For UN-CEFACT version 1, maintain /OPT/TRANS_XML_EDOC_CEFACT1.

10.3. Configuration
For UN-CEFACT version 2, maintain /OPT/TRANS_XML_EDOC_CEFACT.
Example 10-2: Single handler
If using a single handler for the transformations mentioned in Example 10-1,

“Independent handler” on page 148, there is no need to maintain any
transformation:
If the transformations are not maintained, the transformation names are picked
up from the maintenance view /OPT/XML_TRAN_HV based on the root node:
Mapping XML elements

The solution is using a two-step-mapping procedure:
1. XML/External data to Semantic data model mapping

2. Semantic data model to VIM mapping
Step 1: XML to Use the maintenance view /OPT/XML_MAPV to maintain the entries in the SM30
Semantic data transaction.
model mapping
Transformation 1
Maintain the transformation name, which is used to convert the XML file to
Semantic data model.
Root Node
Maintain the root node provided in the XML file.

Transformation 2
Maintain the transformation name, which is used to convert the XML file to a
user-friendly display format.
Figure 10-2: Generic UBL solution
Figure 10-3: UN-CEFACT Version 1 solution

10.3. Configuration
Figure 10-4: UN-CEFACT Version 2 solution
Notes
• Semantic mapping is done for PO Goods invoices and Non PO invoices.

Service POs mapping is not delivered with baseline.
• Maximum nodes depth is limited to 4.
Example: FatturaElettronicaBody-DatiGenerali-DatiTrasporto-
DataOraConsegna
If the field appears to be on node hierarchy higher than 4, ignore the root node (for
example Fattura Elettronica Body) and provide the remaining path. Make sure
the external field name is unique.
The following new fields in the mapping were introduced with the patch of April
2020 (included in VIM 7.5 SP11 and VIM 16.3.5):
• Field Value
• Node Level
Sometimes the same node combination represents two different field values that
must be mapped into different target fields. The new fields can be used to
differentiate based on the adjacent XML node.
Example 10-3: Mapping field values into different target fields
The following node combination represents two different fields: Seller/

Vendor VAT number and Seller/Vendor Tax number (different target names in
VIM document header):
AccountingSupplierParty-Party-PartyTaxScheme-CompanyID
The content can be mapped differently based on the adjacent XML node. If the
adjacent node value is VAT, the field value is VAT number. If the adjacent node
value is space then the field value is TAX number. To implement such mapping,
maintain the field value and node level as shown in the following screenshot:

Step 2: This step is performed with provided VIM mappings maintained in the respective
Semantic data channels (XML_FATURA, XML_RECHN, and so on)
model to VIM
mapping
Mapping country specific codes to SAP codes
Country specific e-documents can use different codes to pass information that is
important for further processing. For example, suppliers can tell buyers their
preferred payment method. Values for such data are normally established by a
specific e-document format and are not known to target systems where invoices are
processed. To support the mapping of such data to values that can be used in the
processing system, a mapping table is provided: /OPT/EDOC_CODES. You can
maintain the language specific text for codes in the table /OPT/CODES_TEXT.
The delivery includes values used for FatturaPA processing.
Example 10-4: Values for FatturaPA processing
Document type
TD01 Invoice
SAP document type is RE.
TD04 Credit note
SAP document type is KG.
Payment method
MP02 Cheque
SAP payment method is A.
MP05 Bank transfer
SAP Payment method is C

10.3. Configuration
10.3.2 Additional required configuration

Basic settings ArchiveID for XML: set the repository name according to your archiving system.
10.3.2.2 HTML visualization of FatturaPA

To be able to view the HTML rendering of FatturaPA XML files, you can download
a stylesheet from the Italian Revenue Agency. You need to modify the stylesheet to
make it work with VIM modules. This section describes the necessary steps.
To modify the stylesheet for FatturaPA XML files:
1. Download the stylesheet from the Web site https://www.fatturapa.gov.it. Look

for “Foglio di stile per la visualizzazione della Fattura Ordinaria” in the Italian
language area because this is normally the most recent version.
2. In the STRANS transaction, create a new transformation. The transformation

name assumed in the baseline configuration is /OPT/TRANS_FATTURA_USER_
DISP. You can create the transformation in your name space and adjust the
configuration in the Inbound Configuration handler definition and in the
maintenance view /OPT/XML_TRAN_HV.
3. Set the transformation type to XSLT Program.
4. Paste the complete source of the downloaded stylesheet as the transformation

source.
5. Search for similar code as the following code, which exists as first line in the
transformation:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/
Transform" xmlns:a="http://ivaservizi.agenziaentrate.gov.it/docs/
xsd/fatture/v1.2" version="1.1">
6. Replace the code in Step 5 on page 153 with the following:

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:dt="serpro.sped.nfe.visualizador.fronteira.paineis.util.Formatacao"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:p=
"http://www.fatturapa.gov.it/sdi/fatturapa/v1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1"
xmlns:n0="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2"
xmlns:prx="urn:sap.com:proxy:PRT:/1SAI/TAS47553F10FD51AA9FB178:740"
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
version="FPA12">
7. Search for all occurrences of the following tags:
• a:FatturaElettronica
• p:FatturaElettronica

• n0:FatturaElettronica
Note: FatturaElettronica is a common part in the search criteria, so

make sure to search and replace with the prefixes a, p or n0.
8. Replace all occurrences of the mentioned search criteria with *.
Example: a:FatturaElettronica/FatturaElettronicaHeader must become */

FatturaElettronicaHeader.
9. Activate the transformation.
10.3.2.3 HTML visualization of XRechnung

To visualize XRechnung XML files by converting them into HTML and attaching the
result to VIM documents, you can download a stylesheet from OpenText My
Support.
To modify the stylesheet for XRechnung XML files:
1. On My Support, navigate to Patches > Vendor Invoice Management > Vendor

Invoice Management – E-invoicing, and download the file xr-
visualization.zip.
The archive contains the following files:
xr-visualization.txt - transformation source
Apache-LICENSE - Apache license
Notes
• The provided source file is a modified version of the XRechnung

visualization stylesheet, originally published under Apache license
terms by the Koordinierungsstelle für IT-Standards (KoSIT). For the
terms of the Apache license, see the provided file Apache-LICENSE.
• The current version is provided as an unsupported example
implementation only for the use by OpenText customers and partners
implementing VIM. As a Derivative Work, it is not licensed under the
terms of the Apache license anymore but is subject to your respective
VIM license.
2. In the STRANS transaction, create a new transformation, giving a name in your

namespace. Set the transformation type to XSLT Program.
3. Paste the source code found in the file xr-visualization.txt into the source
code field.
4. Activate the transformation.
5. Add a new step with the ID IMG_ATUDF into the Inbound Configuration handler
definition (standard is PS03RECHN for XRechnung), after the step REG_VIM:

10.3. Configuration
6. Use the module class /OPT/VIM_ATTACH_USER_FORMAT and enter your assigned

transformation name.
With this configuration change, an HTML file is attached to each VIM document
in addition to the original XML file. You can also use the Z-constant 005 / MAIN_
FILE_TYPE, described in “Optional configuration” on page 156, to set the
HTML file as main document image to be displayed in all dashboards
automatically.
10.3.2.4 Plug-in configuration for XML visualization
To configure the plug-in ID:

Management Invoice Solution > Cross Component Configuration >
Processing Plug-In Configuration > Define Plug-In IDs.
2. In the Plug-In Definition Overview screen, create a new plug-in ID to display

the XML in a user friendly format.
For more information, see Section 17.2 “Defining the plug-in ID” in OpenText
Vendor Invoice Management for SAP Solutions - Configuration Guide for Invoice
Solution (VIM-CGD).
To assign the plug-in ID to a plug-in type:

Management Invoice Solution > Cross Component Configuration >
Processing Plug-In Configuration > Assign Plug-In IDs to Plug-In Types.
2. In the Plug-In Type Mapping Overview screen, assign the plug-in ID to a plug-
in type.

For more information, see Section 17.3 “Assigning the plug-in IDs to plug-in
types” in OpenText Vendor Invoice Management for SAP Solutions - Configuration
10.3.3 Optional configuration

Related VIM Z constants
005 / EDOC_ATTACH_HTML
Archiving document type for XML visualization (HTML file, currently only for
Italy solution)
005 / PLUG_IN_OBJECTDISP
Function module name for URL generation. This is used for XML visualization.
Standard value for e-invoicing solution: /OPT/VIM_GET_ARCH_URL.
005 / MAIN_FILE_TYPE
This Z constant controls the file type of the main image assigned in the DP
document and the posted SAP invoice. Use the Z constant if you want to display
attached files (PDF) as main invoice image.
Example value: *;PDF;HTM. This will replace any original file (normally XML)
with PDF if attached, or with HTM if no PDF is found.
10.3.4 Special mapping logic

Special mapping logic is provided for company code and vendor number
determination. This is maintained as a function module for each VIM mapping that
is delivered. Company code and vendor number are determined based on tax
numbers maintained in company code and vendor master respectively. If a valid
purchase order is found on the invoice, the company code and vendor number will
be read from the purchase order.
If needed, you can copy the provided function modules and extend them to suit
project specific needs.
10.3.5 Integration of Inbound Configuration with SAP

Document Compliance
The inbound processing is triggered through the implementation of the EDOC_
INCOM_CONNECTOR. The implementation /OPT/EH_E_EDOC2_BADI_INCOMING is
delivered in an active state.
The BC set /OTBCSL38/EDOCU_INTEGRATION_SAP, provided with the installation of

the component OTBCSL38 delivers a baseline configuration that you must adjust to
your current settings. The rest of this section describes the delivered configuration.
The customizing view /OPT/V_EDOC2_ACT is used to activate the inbound processing

by Company Code, eDocument process, and eDocument type. You can enter an
asterisk as company code, which allows processing incoming documents for all
company codes, selecting the processing with the eDocument process and type.

10.3. Configuration
Each combination needs to be activated using the Active check box. The external
profile is a free text field to enter an identifier that serves as a link to the registration
settings of the Inbound Configuration (customizing node Inbound Configuration >
Document Handler > Registration > Custom / Others).
OpenText provides baseline configuration entries for processing activation. In the

following, you find an example entry for the processing of FatturaPA (Italy):
Additional settings
ACCEPT for Blocked

Select this check box if you want to send the ACCEPT feedback in the relevant
scenarios (for example Italy) for invoices blocked for payment immediately after
the posting. Clear the check box to determine that the ACCEPT feedback is sent
when the invoice is released for payment.
ACCEPT for Parked

Select this check box if you want to send the ACCEPT feedback in the relevant
scenarios (for example Italy) for parked invoices immediately after the parking.
Clear the check box to determine that the ACCEPT feedback is sent when the
invoice is posted.
The external profile for registration is delivered for supported scenarios. See the
following example entry for the processing of FatturaPA (Italy):
Note: The IDs of the channel, handler, and archiving document types must be
verified and adjusted according to your existing configuration.

In the provided baseline configuration, the inbound handler PS03_EDOC2 differs

from the typical handler used for processing with Early Archiving (OAWD). The step
GETCONT is replaced with GETDOCID, which is implemented by another class: /OTX/
PS38_CL_DOCID_UPDATE. The rest of the steps remains the same.
In addition to VIM configuration, the settings in SAP Document Compliance must

be adjusted to ensure that BADI implementation provided by OpenText is called:
In the SM30 transaction, in the EDOINCOMSOLDEFV view, maintain the entry for OPT
automation solution as shown in the following:
In the SM30 transaction, in the EDOINCOMSOLV view, maintain entries for each
scenario, company code and OPT automation solution. See the following example for
Italian invoices:
10.4 Quick start

This section lists minimal steps needed to achieve a completely working solution for
different scenarios.

10.4. Quick start
10.4.1 OAWD upload with Inbound Configuration

This section assumes that all baseline settings like channels and mappings are in
place and lists the additional, project specific steps based on VIM baseline.
To configure ArchiveLink for an OAWD upload:
1. Create new archiving document types:
Document type for XML files

One for XML files. /OPT/FATRA and /OPT/RECHN, and /OPT/VUBL are
provided by OpenText.
Document type for visualization HTML files

Assign the value to the Z-constant 005 / EDOC_ATTACH_HTML.
2. Set or verify attachments archiving document type, by Z constant 005 / ADDL_

DOCS_AR_OBJECT.
3. Link VIM Foundation, VIM Invoice Solution, and SAP BOR objects mentioned
in the following list to the new archiving document types:
• /OPT/V1001
• /OTX/PF01R
• BKPF
• BUS2081
4. Assign the new XML archiving document type to the Inbound Configuration
workflow (object /OTX/PF01R, template WS00297300).
5. In the OAWS transaction, add a new OAWD upload node.
To configure VIM Foundation for an OAWD upload:
• In the VIM Foundation customizing, assign handler and other parameters to the
new archiving document type for early archiving:

10.4.2 Email with Inbound Configuration

To configure an email solution with Inbound Configuration:
1. Create new archiving document types:

/OPT/FATRA and /OPT/RECHN, and /OPT/UBL are provided by OpenText.

2. Set or verify attachments archiving document type, by Z constant 005 / ADDL_

DOCS_AR_OBJECT.
3. Create new identically named channels in Inbound Configuration and VIM

Invoice Solution. The VIM channel must use the mapping according to the
scenario. Example: XML_RECHN mapping for XRechnung.
4. Maintain SAPconnect settings for incoming email similarly to the following

screenshot. As Inbound Configuration Exit Name, use /OTX/PF01_CL_
REGISTER_MAIL.
5. In the Inbound Configuration customizing, Registration - Mail Overview,

maintain an entry for the chosen email address. Use the channel and archiving
document types created before. Most of the time, the baseline inbound handler
definition can be used for the email channel too.

10.4. Quick start
For more information, see Section 4.4.2.3.6 “Customizing inbound email

registration” in OpenText Vendor Invoice Management for SAP Solutions -
10.4.3 Integration of Inbound Configuration with SAP

Document Compliance
This section assumes that you have configured SAP Document Compliance to
receive the inbound invoices for required scenarios. The baseline configuration for
the OpenText eDocument solution and for the component OTBCSL38 must be present
in the system.
This section also assumes that all baseline settings like channels and mappings are in
place. It lists the additional, project specific steps based on VIM baseline.
To configure the integration of Inbound Configuration with SAP Document

Compliance:
1. ArchiveLink
Create new archiving document types:

/OPT/FATRA and /OPT/RECHN, and /OPT/UBL are provided by OpenText.

2. Set or verify attachments archiving document type, by Z-constant 005 /

ADDL_DOCS_AR_OBJECT.
3. Link VIM Foundation, VIM Invoice Solution, and SAP BOR objects to the new
archiving document types, as shown in the following list:
• /OPT/V1001
• /OTX/PF01R
• BKPF
• BUS2081
4. Assign the new XML archiving document type to the Inbound Configuration
workflow (Object /OTX/PF01R, template WS00297300).
5. For each of the scenarios (for example FatturaPA), configure the SAP Document
Compliance integration settings together with Inbound Configuration
registration settings:

a. In the SM30 transaction, in the /OPT/V_EDOC2_ACT view, adjust the settings

for your scenario or create new ones by copying the existing.
b. In the VIM Foundation customizing > Inbound Configuration >

Registration > Custom / Others, verify the archiving document types
provided with the standard configuration.
c. Enter the archiving document for the main XML document and the one
used for attachments.
d. If you want to use your own inbound handler, and not the provided PS03_
EDOC2, verify the handler steps. Make sure to use the step GETDOCID instead
of GETCONT. The rest of the settings must be the same as used for the Early
Archiving scenario (channel and classification).
10.5 Generic Peppol/UBL mapping

10.5.1 XML mapping
There are two cases in extending of mapping:
Case 1: Newly added section

In the XML document, a new section was added, and it was not covered under
the transformation. The system is not parsing the newly added section in the
XML document.
Case 2: Transformation
A section of the XML document is being parsed by transformation, but the field
is not included in the mapping.
10.5.1.1 Case 1: Newly added section
Method 1
Enhance the transformation as mentioned in “Enhancing the transformation”
on page 166 and get the external field as mentioned in “Case 2: Transformation”
on page 163.
Method 2
In the XML document, there are different nodes in different hierarchies. A field
can be mapped by using its path over the hierarchy:
To map a field:
1. Identify the section in the XML document that is not being parsed.
Example: Suppose that the highlighted part was added in the XML document:

10.5. Generic Peppol/UBL mapping
2. Determine the combination of nodes to map the field. To get the

combination, get the current node and the nodes above, up to 4 levels
including the current node.
In the example, the value of node <IdPaese>IT</IdPaese> is mapped.
The field node is IdPaese.
The nodes above are IdFiscaleIVA, DatiAnagrafici, and
CedentoPrestatore.
The mapping path for the field is: CedentoPrestatore-DatiAnagrafici-
IdFiscaleIVA-IdPaese
10.5.1.2 Case 2: Transformation

To use transformation to parse a section of the XML document:
1. If you want to get the combination of nodes that was already covered in the
transformation, go to the STRANS transaction, enter the relevant transformation
name, and click the Test button.

2. On the next screen, enter the source file path and click the View HTML button.
The output is displayed as a pair of EXTFIELD and EXTVALUE. The data enclosed
between EXTFIELD tags is the path that needs to be entered as External Field in
the mapping configuration.
To configure the XML mapping:
1. In both described cases, when you extend the transformation or when you
identify the path, determine the external field name, that is the path made of
XML nodes, separated with dashes. Add the external field name to the field
mapping table.

2. Go to /OPT/XML_MAP transaction.
3. Select an existing transformation and root node entry, or add a new

transformation if you have created one.
4. Optional If there is any transformation for user display format, configure it in the
third column.
5. If a new transformation has been added, save the entry.
6. Select the transformation and double-click the subnode Mapping of XML data
and Semantic data in the Dialog Structure.
7. On the next screen, enter the transformation name, root node. The root node
should be the top node of the XML document.
Example: XML documents and its root nodes:
8. In the Serial number column, enter a unique number.
9. In the External Field column, enter the combination of nodes as mentioned in

Step 1 on page 164.
10. Select the Field Type, either Header or Item.
11. Enter a meaningful name in the Semantic Name column. It is better to enter a
name in UBL format. Make sure that there are no spaces in the name.
12. For more details about the remaining columns, see “Mapping XML elements”
on page 149.

10.5.2 Enhancing the transformation

To create or enhance the transformation:
1. Divide the data in the XML document into three parts: header data, item
section, and attachments.
2. Enclose header data between tags <HEAD_DATA> and </HEAD_DATA>. The

system will consider the data between these tags as header data.
3. Similarly, enclose item data between tags <ITEM_DATA> and </ITEM_DATA>.
4. Similarly, enclose attachments and its relevant data between tags

<ATTACH_DATA> and </ATTACH_DATA>.
5. Enclose the external field name between the tags <EXTFIELD> and </
EXTFIELD>.
6. Enclose the field value between tags <EXTVALUE> and </EXTVALUE>.
7. Enclose every pair of external field name and the corresponding field values
between tags <ITEM> and </ITEM>.
8. Enclose all listed tags between tags <RESULT> and </RESULT>.
Example:
9. Identify the section of the XML document that needs to be mapped, and decide
whether its data must be mapped as a header field, item field, or attachment.
Example: Suppose the highlighted part was newly added in the XML document:

The highlighted part was identified as header data.
10. Identify the corresponding node level in the hierarchy in the XML document. In
the example, it is at level 3. Get the previous nodes up to root node.
11. Get the combination of nodes:

Node at level 1 / Node at level 2 / Node at level 3
Example: /p:FatturaElettronica/FatturaElettronicaHeader/
CedentePrestatore
12. Based on the combination, write the following code:

<xsl:apply-templates select="/p:FatturaElettronica/
FatturaElettronicaHeader/CedenteP restatore"/
This syntax results into the transformation navigating over the child nodes of
the node set as the parameter.
13. To process further, write the following code:

<xsl:template match="/p:FatturaElettronica/FatturaElettronicaHeader/CedentePr
estatore">
<xsl:apply-templates select="DatiAnagrafici"/>
<xsl:apply-templates select="Sede"/>
<xsl:call-template name="select-for-each"/>
</xsl:template>
To process “leaf nodes” that provide values and do not start a nested structure,
the following statement can be used to extract all node values:
In the following example, a section of data was newly added in the XML
document. This section can be divided further as shown in the following: main
node, sub nodes, which start a nested structure, and value nodes.

14. The value (leaf) nodes can be processed with the syntax select-for-each. But
other sub nodes need to be processed further to get the value nodes. To get the
relevant data of those sub nodes, add the following code:
<xsl:apply-templates select="DatiAnagrafici"/>
<xsl:apply-templates select="Sede"/>
15. To process further, add the following code in the transformation:

<xsl:template match="DatiAnagrafici">
<xsl:apply-templates select="IdFiscaleIVA"/>
<xsl:apply-templates select="Anagrafica"/>
</xsl:template>
<xsl:template match="Sede">
</xsl:template>
16. Finally process the value nodes using the following code:
10.6 Visualization of XML invoices

VIM is able to process electronic invoices in XML format, mapping the XML data to
VIM fields and starting VIM workflows. As XML is not easily readable for end users,
most of them will prefer to see a rendering of the received XML, for example, in
HTML or PDF format.
Earlier deliveries of VIM components for electronic invoices allowed to use XSLT
transformation to create an HTML rendering. An inbound handler class was
provided to call a transformation and archive the result. Disadvantage of this
technique was the need to create a transformation that required experience with
XSLT. Example transformation was provided for the German XRechnung format
and could also be downloaded for Italian FatturaPA from Italian tax authority.
The new visualization mechanism developed by OpenText allows to create PDF

renderings of XML files by specifying the XML elements to be displayed in new
configuration tables. The configuration reflects the XML structure, in addition

10.6. Visualization of XML invoices
allowing to easily group display elements, provide text labels in different languages,
or convert special codes into meaningful texts, all without the need to write any
code.
The currently provided delivery includes a minimal configuration for UBL format,
oriented towards the German XRechnung invoices. You can create configuration for
other formats as part of customer implementation projects. OpenText will work
further on improving and extending the visualization capability.
To create PDF renderings, SAP Smartforms technology is used. Two Smartforms are
provided.
• One Smartform is used to render a limited number of most frequently used

invoice fields in a fixed layout, aiming to render the data close to how typical
vendor invoices look like. The format is more easily readable and provides a
quick overview. For more information, see “Complex XML Visualization” in
“Basic customizing” on page 169.
• Another Smartform is used to render unlimited number of fields, but in a more
linear format. You can use this format to display much more fields, as there are
no size constraints of form areas. For more information, see “Simple XML
Visualization” in “Basic customizing” on page 169.
You configure the Smartforms using the same VIM customizing that is used for the
PDF process log. You can use custom developed forms, provided they use the same
interface as described in “Basic customizing” on page 169.
10.6.1 Basic customizing

To configure the XML visualization:

Management Invoice Solution > Cross Component Configuration > PDF Log >
Maintain Customizing profiles.
The following profiles are provided:
XML_VIS_SI
Simple XML Visualization
XML_VIS_CO
Complex XML Visualization
2. Configure the profiles as shown in the following example:

Example 10-5: Complex XML Visualization
You can change the following relevant customizing settings:
Form Name
Enter the name of the used Smartform: /OPT/VIM_XV_COMPLEX
Language
Enter the language of the output. You can overwrite this in the XML syntax
definition, see the explanation below
Document Type
Enter the archive document type. Standard: /OPT/XV_CO for complex and /
OPT/XV_SI for simple

Figure 10-5: Simple list output | /OPT/VIM_XV_SIMPLE
Figure 10-6: Complex, invoice-like output | /OPT/VIM_XV_COMPLEX
You can copy standard Smartforms and replace them by custom Smartforms. The
visualization class integrates them by using the following interfaces:

Interface of the simple output Smartform:

EXPORTING
control_parameters = SAP Standard
output_options = SAP Standard
user_settings = SAP Standard
simple_output = Type /OPT/VIM_XV_SIMPLE_OUTPUT1_TT
IMPORTING
job_output_info = SAP Standard
Interface of the complex output Smartform:

EXPORTING
control_parameters = SAP Standard
output_options = SAP Standard
user_settings = SAP Standard
header_l1_label = Type string128
header_r1_label = Type string128
footer_l1_label = Type string128
footer_r1_label = Type string128
footer_l1_v1_label = Type string128
item_v1_label = Type string128
header_l1 = Type /OPT/VIM_XV_VALUE_TAB_TT
header_r1 = Type /OPT/VIM_XV_VALUE_TAB_TT
item = Type /OPT/VIM_XV_VALUE_TAB_ITEM_TT
tax = Type /OPT/VIM_XV_VALUE_TAB_TAX_TT
footer_r1 = Type /OPT/VIM_XV_VALUE_TAB_TT
IMPORTING
job_output_info = SAP Standard
Note: You must use the Z constant 005 / MAIN_FILE_TYPE to ensure the
transfer of multiple files into the VIM process, even if you do not plan to make
the PDF files to be main invoice images. Example value to keep XML as main:
*;XML;HTM. Or, to make PDFs main images: *;PDF;HTM.

10.6.2 Inbound component integration

The visualization is created from the XML, provided at the Inbound component of
Vendor Invoice Management for SAP Solutions (Inbound component), using the
following different channels.
ArchiveLink setttings
The PDFs are created during the inbound processing and archived first to the
Inbound component object (/OTX/PF01R). Later, at workflow start, they are archived
to the VIM object (/OPT/V1001). It is mandatory to maintain entries in the OAC3
transaction with the objects /OTX/PF01R (Inbound component), /OPT/V1001 (VIM)
and the used archive document types.
Table 10-1: Inbound component object

/OTX/PF01R /OPT/XV_CO X A3 TOA01
/OTX/PF01R /OPT/XV_SI X A3 TOA01
Table 10-2: VIM object

/OPT/V1001 /OPT/XV_CO X A3 TOA01
/OPT/V1001 /OPT/XV_SI X A3 TOA01
Handler and module settings

There are two classes that need to be integrated into the module handler:
• Simple XML Visualization /OTX/PS03_INB_XV_CONV_SIM

• Complex XML Visualization /OTX/PS03_INB_XV_CONV_COM
To configure handler and module settings:

1. Run the /n/OTX/PF00_IMG transaction and navigate to OpenText Vendor
Invoice Management Foundation > Inbound Configuration > Document
Handler > Modules.
2. To create PDF visualization, add the class for simple and/or complex
visualization as a module in the handler:

Note: The screenshot shows the earlier delivered step to create an HTML
rendering, see “HTML visualization of FatturaPA” on page 153. When
using the new PDF rendering, you can switch of HTML rendering as
needed.
Both PDFs can be created and passed into the DP document. One of them can be
set as leading document by using configuration. For more information, see Z
constant 005 / MAIN_FILE_TYPE in “Optional configuration” on page 156.
10.6.3 Customizing XML scenarios and mapping

To define the configuration of the PDF rendering, run the SM30 transaction and
maintain the following maintenance views:
/OPT/VIM_XV_SYNV
Maintain syntax. Each XML format will use distinct syntax.
/OPT/VIM_XV_GRPV
Maintain mapping groups. You can group elements to reflect the hierarchical
structure. Examples of groups: supplier address data, invoice gross/net
amounts.
/OPT/VIM_XV_ELEV
Maintain elements and assign them to groups.
/OPT/VIM_XV_CODV
Maintain Code/Values. This defines the conversion of special code values to
meaningful texts. Example: you can label UBL document type 380 as Supplier
Invoice.
/OPT/VIM_XV_TRAV
Maintain translations of labels for groups and elements. Groups labels are used
for area titles, element labels are displayed next to elements.
10.6.3.1 Determination of syntax

A syntax entry defines special XML syntax and is required for each type of XML /
XML syntax.
• The syntax entry determines XML syntax, based on External Field Name / Field
Value pairs. You can use a substring for value.
• The syntax entry determines the Root Node.
• The syntax entry determines the output Language. If set, it overrides the one set
in the PDF log configuration.
• Show all is reserved for future use.

Example 10-6: Root node and syntax determination key/value
10.6.3.2 Groups and elements

You can use groups and elements to map XML data to areas and fields in the PDF
rendering.
To maintain groups:
1. Run the SM30 transaction, with view /OPT/VIM_XV_GRPV.

2. Customize fields using the following parameters:
XML Syntax
The defined XML syntax

Syntax Entry
The name of the group
XML Path
The path that has to be followed in the input file to find the start of the
group. Do not specify the root element.
Example: In the XML UBL format, the field group of the invoice receiver begins at
the path AccountingCustomerParty-Party.
Mapping Area
Mapping to a specific box on the complex output
List Sequence
Sequence of the group in the simple output
Mapping Area Each group of fields can be found by following a distinct XML path in the input file
and an assignment to a special box (mapping area) on the complex Smartform
layout.
The following list shows the number of elements for each group/box on the complex
layout:
• Header left, Box 1: 2 Lines/Elements

• Header right, Box 1: 2 Lines/Elements


For the simple list output, you must specify the sequence of the group and the
elements of the group.
Example 10-7: Invoice lines
• Mapping Area (complex output): Item to Line items

• List Sequence (simple output): at position 12 of the list output (simple
output)
• Multiple Appearance: for line items and tax items
Example values:

• Mapping area (complex output) : Footer right, Box 1

• List sequence (simple output): at position 7 of the list output (simple
output)
You must assign elements to a group to make them visible in the PDF.
To assign elements to a group:
1. Access the /OPT/VIM_XV_ELEV maintenance view.
2. Assign elements to a group, using the following parameters:
XML Syntax
The defined XML syntax
Syntax Entry
The assigned group
Element
The name of the element
XML Path
The specific path of the element is root node + group + element.
Sibling Element
Another element, which can be used as sibling element
List Sequence
Sequence of the element within the group
Code Type ID
Replace special codes with a meaningful value, like debit/credit

No Output
For sibling elements: Select this check box to avoid them being displayed
separately.
Note: Sibling elements are used when two values in the same group need
to be displayed as a pair, one next to another. Typical examples are
amount and currency, or quantity and unit of measure.
Example – The currency is placed next to the amount. The element
AmountLinesCur has been used as a sibling to display currency for the
element AmountLines.
Codes XML might contain codes. In this case, you can use a special value defined by the
specific XML format, code conversion, to display meaningful texts next to or instead
of the code.
For example, in German XRechnung, the Invoice Code 380 means Commercial
Invoice. To replace the code by a meaningful text, you can maintain the Code Type
ID in the /OPT/VIM_XV_ELEV maintenance view.

Values can be printed with or instead the code. To replace the code with the Invoice
Code ID, select the check box Replace w. Code.
10.6.3.3 Code IDs

To replace different codes with meaningful descriptions, you can maintain the
view /OPT/VIM_XV_CODV.
To replace codes with meaningful descriptions:
1. Access the /OPT/VIM_XV_CODV maintenance view.
2. Customize codes, using the following parameters:
XML Syntax
Enter the defined XML syntax, or * for all syntaxes.

Code Type ID
The ID of the code
External Field Name
The value in the XML structure
Language
Language to be used in the Smartform
Long Field Label
The value to be replaced with the value in the XML Structure
Example 10-8: UnitCode and Debit/Credit
10.6.3.4 Translating labels for groups and elements

1. Access the /OPT/VIM_XV_TRAV view.
2. Maintain field labels for groups and elements, otherwise the technical name is
printed on the PDF. Use the following parameters:
Definition Type (Def type)

Element or Group
Syntax Entry
Name of the element or group
Language
Language to be used in the Smartform
Long Field Label
Field label

10.7. Known issues
10.7 Known issues

10.7.1 Mapping of date fields
The standard delivery performs mapping with conversion for several date fields. If
the date values in the resulting DP document are invalid and contain non-allowed
characters, you can make the mapping remove those characters by maintaining the
Ignore characters field in the corresponding mapping entry.

Chapter 11
Configuring Public Sector Management
Starting with VIM 7.5 SP11 / VIM 16.3.5, VIM introduces new functions to support
processes in Public Sector Management (PSM). This section describes the functions
of PSM and their configuration.
VIM provides the following functions:
• Use of the route ID to route documents within the organization. You can use the
fields and logic with the German electronic invoices in the XRechnung format,
which supports the “Leitweg-ID” (route ID). This complements the support for
German electronic invoices that was delivered earlier but it is not limited to this
scenario. You can use the route ID fields as VIM role template fields.
• New fields typically used for SAP Funds Management are introduced at
document item level.
• Accounting data can be derived from the Funds Management configuration done
in the transaction FMDERIVE. This is supported in the DP indexing screen, in the
approval process, and as a separate logic module. You can use the logic module
if some invoices are posted in background without manual processing.
11.1 Routing documents with the route ID

To support routing of invoices within organizations, new fields are introduced at the
DP document header level. Currently those fields are used to process electronic
invoices in the German XRechnung format and its element Leitweg-ID but the usage
is not limited to this scenario.
The complete route ID is a long string typically mapped from an electronic invoice
into the VIM field ROUTE_ID. The value can then be split into the parts ROUTE_ID1
and ROUTE_ID2.
Route ID field Example Comment

ROUTE_ID = Routing ID 99011222-12345-67 Complete route ID
ROUTE_ID1 = Department ID 222 R&D
ROUTE_ID2 = Department Sub ID 12345 R&D Munich
These fields are available in the DP indexing screen, Process tab. The fields are not
enabled by default. Depending on the project requirements, the original route ID can
be displayed read-only, with two other fields open for input. You can use the new
fields later in the following ways:

Chapter 11 Configuring Public Sector Management
DP workflow role setup

The fields are exposed as attributes using the BOR object /OPT/V1001 and can be
used as role template fields.
VIM Analytics
The fields are exposed as selection criteria and as output fields. To restrict the
report access, a new authorization check J_6NIM_BRO is implemented for that.
VIM Invoice Workplace
The fields are exposed as output fields.
To split the value of ROUTE_ID into ROUTE_ID1 and ROUTE_ID2, you can use the
logical module /OPT/CL_D_LM_SPLIT_ROUTE_ID. The module splits the value
according to the Z constant 005 / ROUTE_ID_SPLIT. The constant value must contain
four values separated with slashes and it must contain the start and length of each
component <ROUTE_IDx> in the original value ROUTE_ID:
Start of ROUTE_ID1 / Length of ROUTE_ID1 / Start of ROUTE_ID2 / Length of ROUTE_

ID2
Note: Spaces are used for readability, no spaces are allowed in the actual
constant value.
Example 11-1: Z constant ROUTE_ID_SPLIT
To facilitate value selection if manual input is needed, you can use the customizing
table /OPT/VIM_ROUTEID to maintain possible values for ROUTE_IDs along with
their descriptions. Follow the VIM customizing path: Run the /n/OPT/SPRO
transaction and navigate to OpenText Vendor Invoice Management Invoice
Solution > Cross Component Configuration > Public Sector Management >
Maintain Route IDs.

11.2. Line item fields relevant for PSM
11.2 Line item fields relevant for PSM

Some fields typically used for account assignment related to SAP PSM processes are
supported in VIM documents. The following table lists field names that are used in
the configuration:
DP document item
Approval screen
field and approval
configuration for all Available in
screen configuration
Field scenarios - key item COA setup
key item field for
field (table /OPT/ structure?
coding (table /OPT/
FIELDS_V)
CODING_V)
Earmarked Funds:
KBLNR EARMARKED_FUND X
Document Number
Earmarked Funds: EARMARKED_FUNDP
KBLPOS
Document Item OS
Commitment Item FIPOS CMMT_ITEM X
Funds Center FISTL FUND_CENTER X
Fund GEBER FUNDS
Functional Area FKBER FUNCTIONALAREA
11.3 Derivation of accounting data

If you use the derivation of accounting data through the Funds Management
module (FMDERIVE), VIM can perform the corresponding account assignment at the
following points:
• DP indexing screen
• Approvals of Non PO invoices (coding step):
This is supported for SAP GUI, Approval Portal, and Fiori scenarios.
• Logic module in the DP workflow:
You can use this to derive accounting data in background, for example before
automatic posting.
Activate the derivation through Z constant 005 / DERIVE_ACCTDATA:

Chapter 11 Configuring Public Sector Management
For each field that must be transferred from the derivation results, enter the field
name in the SAP standard structure COBL, in the approval coding fields mapping:

Chapter 12
Scenarios for special countries
VIM supports many countries “out-of-the-box”. However, for some countries, a

special configuration is necessary. These countries have a specific business
background and incoming invoice processes. In the baseline, VIM delivers the
configuration as characteristic specific customizing.
This applies to the following countries:
• “Brazil” on page 189

• “Canada” on page 194
• “China” on page 201
• “India” on page 209
• “Northern Ireland” on page 214
• “Poland” on page 216
• “Russia” on page 220
• “Spain” on page 223
• “Switzerland” on page 224
• “Thailand” on page 228
This chapter describes the specific business background and incoming invoice
processes of these countries. It also describes how VIM supports the processes and
requirements for these countries.
Note: For country specific information about processing electronic invoices,

see the subsections of “Country specific notes” on page 131. This refers to
Belgium, France, Germany, Italy, Mexico, and the Netherlands.
12.1 Brazil
This section describes the main incoming invoice processes in Brazil, and how ICC
and VIM support them. Other processes with smaller volumes are not covered.
Limitation: Processing of Brazilian invoices for Goods according to Nota

Fiscal eletrônica (NF-e)
• OpenText™ Vendor Invoice Management for SAP® Solutions 16.3 (VIM)

does not provide out of the box support for processing of NF-e invoices.
• VIM provides different incoming channels including an XML preprocessing
step. But VIM does not deliver out-of-the box stylesheets meeting the latest
NF-e standards.

Chapter 12 Scenarios for special countries
• VIM is not a middleware product that interacts with SEFAZ or other

external web services. Many aspects of the VIM implementation depend on
the tool used to establish this type of communication.
• VIM does consider creating the SAP NF-e object in addition to the invoice
posting in SAP but VIM does not provide all NF-e specific fields required
for all industries and invoice types according to NF-e 4.0 standard in VIM
baseline.
• OpenText therefore recommends working with the OpenText consulting

group or a VIM implementation partner who has the specific expertise to
deliver a configuration and extension based on the VIM framework meeting
your specific requirements around processing of Brazilian NF-e invoices.
Best automation results are achieved if the customer has created POs for goods,
services, and transports.
For Brazil, the following types of invoices can be distinguished:
• Goods invoices
• Service invoices
• Transport invoices
• Imported goods invoices
VIM support is integrated in the PO_S4 document type.
Notes
• VIM does not provide XML validity checking functionality or any other
SEFAZ communication facility. This has to be covered by other tools.
• VIM provides an example XML style sheet. This is only delivered as a simple
example to show the way the XML transformation works. If this feature is
used to process incoming NF-e XML documents in VIM, it is necessary to
create a customer-specific XML transformation, meeting latest NF-e standard
and all industry specific requirements and additional fields created as
extension (Maintain Service Modules - Transform - Transformation).
It also might be necessary to enhance the mapping (Maintain Mapping ID);
for more information, see Section 7.4 “Maintaining the VIM field mapping”
in OpenText Vendor Invoice Management for SAP Solutions - Configuration Guide
for Invoice Solution (VIM-CGD).
The style sheet /OPT/IDH_TRANS_XML_NFE needs to be copied and changed.
The new style sheet should contain fields that are already included in the
tables /opt/vim_1head or /opt/vim_1item. Otherwise, it is required to
implement table appends and enhanced data handling.

12.1. Brazil
12.1.1 Goods invoices

All goods invoices must be electronically registered at the ministry of finance
(SEFAZ) before shipping. The registered and signed invoice is an XML document,
called Nota Fiscal Electronica (NFe). It is sent to the customer using input channel
Email, File system or FTP.
Goods must be accompanied by a printed version of the NFe, called DANFE.
No deviation is allowed between delivered goods and billed goods. Either the whole
delivery plus invoice are rejected or the whole delivery plus invoice are accepted.
Figure 12-1: Brazil: goods invoice process
Supporting the goods invoice process with VIM

1. The VIM DP document process is started when an XML document (NFe) arrives
via email or other configured input channel.
2. VIM triggers PO mapping and standard Business Rule checks.
3. The DP document process waits until the GR is posted.
4. With all required data being available, the invoice is posted automatically in the
background.
5. If the posting fails, somebody has to perform one of the following actions:
• change or complement the invoice data manually

• post the invoice manually

12.1.2 Service invoices

All service invoices must be registered at the local city tax portal at the vendor’s city.
The vendor creates the Nota Fiscal Electronia de Servicos (NFS-e) invoice, sends it to
the city tax portal, and receives the NFS-e in PDF format from the city tax portal.
The vendor now sends the NFS-e (PDF) to the customer, normally using email. The
customer checks the validity of the NFS-e with the city tax portal. This must be done
outside of VIM.
Supporting the service invoice process with ICC and VIM

1. The process is started for the ICC input channel as configured (for example
OAWD with PDF file).
2. ICC extracts the header data. The following fields are relevant for Brazil:
• Tax Invoice
• Invoice Category
The validation step is optional.

3. After ICC has finished, a VIM DP document process is started based on the PO
data delivered by ICC.
If no PO data has been delivered from ICC, the accountant must select or enter a
PO number manually.
4. VIM triggers Business Rule checks.
5. With all required data being available, the invoice is posted automatically.

12.1.3 Transport invoices

All transport invoices must be registered at and signed by the ministry of finance
(SEFAZ). The vendor creates the Conhecimento de Transporte (CT-e) XML invoice
and sends it to the SEFAZ to be signed. After receiving the signed XML invoice, the
vendor sends it to the customer, normally using email. The customer checks the
validity of the CT-e with the SEFAZ. This must be done outside of VIM.
Supporting the transport invoice process with VIM

1. The VIM DP document process is started when an XML document (CT-e) arrives
via email or other configured input channel.
2. VIM triggers PO mapping and standard Business Rule checks.
If no PO data is available, the accountant must select or enter a PO number
manually.

12.1. Brazil
3. With all required data being available, the invoice is posted automatically in the
background.

12.1.4 Imported goods invoices

A foreign vendor delivers goods and sends a paper invoice to the customer. For the
transport of the goods within Brazil it is compulsory to have a DANFE. Usually it is
the customer who creates an NFe and a DANFE and sends it to the ministry of
finance (SEFAZ) to be registered and signed. After registration and signing, the
DANFE is sent to the customs office to be used for the goods transport.
Supporting the imported goods invoice process with ICC and VIM
This process is only relevant for a couple of customers and contains some manual
steps.
1. A paper invoice arrives. It is scanned and sent to ICC.

2. ICC extracts data and delivers the results. Validation is optional.
3. A VIM DP document is started.
4. Invoice data has to be completed manually.
5. The process waits until the goods receipt is posted.
6. With all required data being available, the invoice is posted automatically.

12.1.5 Business rules

The following business rules are specific for Brazil. For more information, see
Section 23.78 “Brazil - Missing NF Data (PO)” in OpenText Vendor Invoice Management
for SAP Solutions - Reference Guide for Invoice Solution (VIM-RGD) and the subsequent
sections.
• Missing NF Data (PO)

• Missing NF Customizing (PO)
• NF Validation Check Failed (PO)
• Wait for GR - Simple Check (PO)
• Wait for GR - Enhanced Check (PO)

12.1.6 Indexing screen fields

The following indexing screen fields are specific for Brazil.
• NF-e Number
• Nota Fiscal Type
• Protocol Number
• Processing Date
• Processing Time
• Random Number
• Check Digit
• Electronic NF check box
• Service NF check box
12.2 Canada
VIM provides a configuration specific for Canada. For Canada, all business rules as
in the standard rules for the US have been kept intact. One new business rule
Invalid Sales Tax for the Region has been introduced. In Canada, multiple tax
rates (GST, PST, HST, QST) are applicable, based on the province. Therefore, the tax
code derivation feature has been enhanced to derive tax codes that are based on
multiple tax rates.
Before tax code derivation, the system validates whether the supplied tax rate fields
are applicable for the region. Therefore, it uses the Invalid Sales Tax for the
Region business rule. However, to move past the Invalid Sales Tax for the
Region business rule check, the system must know the ship-to-region for the
incoming vendor invoice. The external system (for example OCR or IDOC) might
not supply a ship-to-region. The region can be derived automatically, based on
certain settings. For more information, see “Determining the ship-to region”
on page 195.
When the ship-to-region is known and the Invalid Sales Tax for The Region
business exception does not occur, the system proceeds further to determine the tax
code, based on the multiple tax rate fields supplied. For more information, see
“Determining the tax code” on page 198.
You can perform all Canada-specific customizing by running the /n/OPT/SPRO

transaction and navigating to OpenText Vendor Invoice Management Invoice
Solution > Document Processing Configuration > Document Type Configuration >
Specific Country Settings > Canada.

12.2. Canada
12.2.1 Determining the ship-to region

To determine the ship-to region:

Management Invoice Solution > Document Processing Configuration >
Document Type Configuration > Specific Country Settings > Canada >
Maintain Ship-To-Region Determination.
2. In the Cty field, enter CA for Canada.

In the CoCd From and CoCd To fields, define a range of company codes.
In the Vendor From and Vendor To fields, define a range of vendors.
3. In the Options column, select one of the following options:
Company Code
The system will determine the region from the address maintained in the
company code address for the range of vendors and company codes.
You do not have to maintain an entry in the Region and Custom FM fields.
Company Code -> Purchase Order

The system will determine the region from the company code address. If no
region is retrieved from the company code, this option automatically
switches to the purchase order to obtain the region. The purchase order can
be selected either from the header data or the item data. The system
determines the region from the plant address that is stored at item level.
You do not have to maintain any entry in the Region and Custom FM
fields.
Purchase Order -> Company Code

Same action as in Company Code -> Purchase Order. However, the system
will first try to obtain the region from the purchase order. If this fails, the
company code is used to obtain the region.
You do not have to maintain an entry in the Region and Custom FM fields.
Fixed Value
You must maintain the region explicitly in the Region field.

Custom Function
You can define a custom logic to find the region by defining the Z function
module explicitly in the Custom FM field.
The following is an example interface of the custom function:
FUNCTION ZXXXXXXXXXXX
*"------------------------------------------------------------
*"*"Local Interface:
*" EXPORTING
*" REFERENCE(REGION) TYPE REGIO
*" TABLES
*" INDEX_ITEM STRUCTURE /OPT/VIM_1ITEM OPTIONAL
*" CHANGING
*" REFERENCE(INDEX_DATA) TYPE /OPT/VIM_1HEAD OPTIONAL
*"------------------------------------------------------------
4. Save your settings.
ICC If ICC is used as OCR, ICC does not explicitly supply the ship-to region. In this case,
VIM uses the Company Code/PO (based on the selected configuration option) to
derive the ship-to region. There might be cases where you cannot use a Company
Code/PO to derive the ship-to region. In these cases, you must use custom functions
or manual entries, for example, if one of the following cases applies:
• The Company Code address cannot be treated as the ship-to address. In this case,
do not use the Company Code option to derive the ship-to region. Use the custom
function option.
• A PO or a combination of multiple POs has any line items with varying ship-to
regions for various PO line items (based on different receiving plants at PO line
item level). In this case, do not use the PO as an option to derive the ship-to
region. Use the custom function option.
• Without the ship-to region determined automatically or supplied, new business
rules for validation of tax rate fields/tax code determination fail on VIM side.
Manual user input is needed.
• ICC does not supply taxes at line item level. ICC should supply taxes only at
header level. The same tax rate at the header is applicable for each line item if no
lines are supplied with a tax rate. Different line items in the vendor invoice might
have different tax rates. For example, if a combination of free goods line (tax-free)
and lines with a tax rate exists in the vendor invoice, use the custom function
option.

12.2. Canada
12.2.2 Maintaining tax fields for the region

An incoming vendor invoice is validated against the tax province relationship table.
This section describes the maintenance of this table.
To maintain tax fields for the region:

Maintain Tax-Province Relationship.
2. Specify the province-specific taxes for the regions.

Ideally, you can use the default values. If there is any change in the tax codes for
provinces, the default values may no longer make sense. In this case, you can
perform the necessary changes in the Country Specific Tax - Province
Relationship view.
The Invalid Sales Tax for the Region exception is triggered in the following
cases:
• The tax rate fields supplied in the incoming invoice do not match with the
allowed fields maintained.
• The ship-to region is empty. The ship-to region must be determined to
proceed.

12.2.3 Determining the tax code

You control the tax code determination at the DP document type level (transaction /
n/OPT/VIM_1CX1). For more information, see Section 9.1.12 “Maintaining tax code
determination” in OpenText Vendor Invoice Management for SAP Solutions -
The following options are available:
• SAP Tax Determination Logic with OT Tax Table

• Tax Determination using Open Text Tax Table
• SAP Tax Determination Logic
• Customer Tax Determination
• Tax Code from Vendor Master
SAP Tax Determination Logic with OT Tax Table

The tax code is searched in the standard SAP transaction FTXP by comparing the
tax lines (GST, PST, and so on) for the particular province. If the tax code is still
not determined, the Canada-specific OpenText tax table Tax Code
Determination Configuration for Canada is used to determine the tax code.
To open the Tax Code Determination Configuration for Canada table, run the /
n/OPT/SPRO transaction and navigate to OpenText Vendor Invoice
Maintain Tax Code Determination using OT Table.
In this table, you can maintain tax rates for a region.

12.2. Canada
Note: Enter * in the Vendor From field if it is applicable for all vendors.
Avoid an overlap of key fields. All fields in the screenshot are key fields,
except the Tax Code field. If key fields overlap, the system will pick the tax
code corresponding to the first match.
Tax Determination using Open Text Tax Table

Only the table Tax Code Determination Configuration for Canada is used to
determine the tax code. For more information, see SAP Tax Determination
Logic with OT Tax Table on page 198.
SAP Tax Determination Logic

The tax code is searched in the standard SAP transaction FTXP by comparing the
tax lines (GST, PST, and so on) for the particular province.
The system searches a tax code for multiple tax lines by comparing the
keywords for the tax lines (like GST, PST, and so on). These keywords are
maintained in the customizing transaction: Run the /n/OPT/SPRO transaction
and navigate to OpenText Vendor Invoice Management Invoice Solution >
Document Processing Configuration > Document Type Configuration >
Specific Country Settings > Canada > Maintain Search Keyword for Tax Rate
Fields/Text for Line Item Tax Fields.
Note: The Find Text for Field at Header and Line Item Level table with its
entries is provided by default. Therefore, you do not have to maintain or
change anything, unless some exceptional cases occur.
Keywords – Assigning a keyword to a particular field specifies the kind of field.

For example, if GST is the keyword for the TAXRATE_1 field, this means that the
TAXRATE_1 field is the GST tax rate field for Canada.
Entries in the KeyWord column are language dependent.

The following fields at header level should be maintained for the tax line
keyword:
• TAXRATE_1: Maintain GST, if this field is supposed to store the GST tax
rate.
• TAXRATE_2
• TAXRATE_3
• TAXRATE_4
The following fields at line level should be maintained for the tax line keyword:
• TAXRATE1_1
• TAXRATE2_2
• TAXRATE3_3
• TAXRATE4_4
Labels – Besides maintaining keywords, the Find Text for Field at Header and
Line Item Level table is used for maintaining labels for tax rate fields and tax
amount fields at line item level.
Note: For header level fields, you maintain texts in view /OPT/VIM_IDX_T.
Use the SM30 transaction or run the /OPT/SPRO transaction and navigate to
Processing Configuration > General Configuration > Translations/Labels
for Index Screen Fields. For more information, see Section 9.1.7
“Customizing field labels in the index screen” in OpenText Vendor Invoice
Management for SAP Solutions - Configuration Guide for Invoice Solution (VIM-
CGD).
For the line item level, the following fields should be maintained for texts:
• TAXAMT_1
• TAXAMT_2
• TAXAMT_3
• TAXAMT_4
• TAXRATE1_1
• TAXRATE2_2
• TAXRATE3_3
• TAXRATE4_4
Customer Tax Determination

You can create a custom logic to find the missing tax code. Embed the logic in
the Z function module. The following shows an example interface of the custom
function:

12.3. China
*FUNCTION ZXXXXXXXXX
*" TABLES
*" INDEX_ITEM STRUCTURE /OPT/VIM_1ITEM
*" CHANGING
*" REFERENCE(INDEX_DATA) TYPE /OPT/VIM_1HEAD OPTIONAL
Tax Code from Vendor Master

You can select this check box with any of the other options. If the logic fails to
determine the missing tax code from the selected option, the tax code is found
through the vendor master.
To configure this, use Z constant 005 / VENDOR_TAX_CD_FIELD to determine
one of the Tax Number N fields in the Control screen of the XK02 transaction.
This field (STCD1, STCD2, STCD3 or STCD4) must contain the tax code.
Note: When using Business Partner functions (transaction BP) to maintain
vendor data, it might be impossible to designate a special field to store tax
codes in vendor master because it depends on the tax number category
configuration. In this case, avoid using the option Tax Code from Vendor
Master to avoid unwanted effects. You can use the option only if tax
number category configuration is done in a way that one field (of
STCD<x>) is always left unused when entering tax/VAT numbers and thus
will be used to store default tax codes.
12.3 China
This section describes the main incoming invoice processes in China, and how ICC
and VIM support them. For China, the following types of major invoice categories
are supported:
• Special VAT invoices

• Common VAT invoices
• Transportation invoices
On ICC side, you can customize an application with country setting for China. For
more information, see Section 3.4.3 “Customizing a Chinese (Mainland) application”
in OpenText Business Center Capture for SAP Solutions - Customization Guide (CPBC-
CGD).
For China, there is no PO field on the invoice form. Customers are using the notes
field to add the PO.
Import invoices are currently not supported in the Chinese ICC application. For
import invoices, a separate ICC application for international invoices must be used.
For other invoice categories, currently, data needs to be captured manually. Support
for more invoice categories will be implemented following the roadmap.
GTS A government-certified Golden Tax Software (GTS) is used to generate special VAT
invoices, VAT calculation and statutory reporting. A VAT invoice received by the
purchaser can be cross-checked using GTS. For more information, see the website of
the Chinese Tax administration: http://www.chinatax.gov.cn/2013/n2925/

Various implementation considerations
• Electronic invoicing is only allowed for international companies.

• Beginning with January 1st, 2010, the VAT invoice verification with tax
authorities should happen within 180 days of the VAT invoice issue date. Before
January 1st, 2010, the period was 90 days.
• It is possible to have multiple invoice documents for one transaction (example:
freight provided by a third party).
• For invoices with an amount higher than 100,000 Renminbi, 2 or more forms
must be used. In ICC and VIM, these forms are currently treated like single
invoices if they arrive as separate image files. If a PO reference exists, they can be
consolidated in SAP S/4HANA using the PO reference.
• If there are more than 6 line items, an appendix is added to the invoice. If invoice
and appendix arrive in one image file, ICC detects them as related.
Physical storage is required (5 years minimum) for the following:
• Duplicate invoices
• Invoice originals
• Original PO
12.3.1 ICC fields

ICC captures the following fields specific for Chinese invoices:
Note: For more information, see the corresponding subsections in Section 5

“Field references for Invoice Solution (Invoice Capture Center)” in OpenText
Business Center Capture for SAP Solutions - Customization Guide (CPBC-CGD).
• Invoice category: see “China” on page 201
Note: If the invoice category is not filled, the validation user must choose
the invoice category manually.
• Invoice code: 10 digits (12 digits for Ordinary invoices)
• Secret code: 108 characters (in 4 strings of 27 characters each)
• Item serial number: 20 characters
• Total amount: only numeric values are recognized in ICC, not the Chinese text.

12.3. China
12.3.2 Special VAT invoices

The invoice category Special VAT invoice is determined from the invoice code; the
indicator is the 10 digit number, digit 1 to 4 on 8th position.
Special Value-Added Tax invoices (special VAT invoices) are issued by general
taxpayers to their customers when selling commodities or providing taxable
services. A special VAT invoice is only issued to general commercial customers, but
not to normal consumers and small scale VAT payers.
For special VAT invoices, the VAT is applicable (deductible). Special VAT invoices
make up about 80% of all invoices. They are typically used for B2B.
Fraud prevention
Special VAT invoices are printed by the supplier using the GTS. The recipient must
validate these invoices by uploading information to a web site supplied by the
government or tax authority. This check is crucial to avoid paying fraudulent
invoices and to reclaim tax.
The validation system is called Anti Forge Tax Control System (AFTCS). For more
information, see “Working with the AFTCS programs” on page 204.
The following list shows the invoice fields that are relevant for fraud prevention:
• Invoice code
• Invoice number
• Invoice date
• Buyers VAT registration
• Seller VAT registration
• Total amount
• Tax amount
• Secret code
12.3.3 Common VAT invoices

The invoice category Common VAT invoice is determined from the invoice code; the
indicator is the 10 digit number, digit 6 on 8th position.
Common VAT invoices are used as evidence of payment where special VAT
invoices do not apply. They are used by the following taxpayers:
• Business tax taxpayers

• VAT small-scale taxpayers
• VAT general taxpayers who are not allowed to issue special VAT invoices; for
example commercial business general taxpayers who engage in retail of

cigarettes, liquor, food, clothing, shoes and hats, makeup, and other consumer
goods.
Enterprises or individuals who are not able to issue special VAT invoices should
issue common VAT invoices when selling commodities, providing taxable services,
or conducting other operating activities.
For common VAT invoices, the VAT is mentioned on the invoice but it is not
deductible.
12.3.4 Transportation invoices

The invoice category Transportation Invoice is determined from the invoice code;
the indicator is the 10 digit number, digit 7 on 8th position.
Transportation invoices are relevant for export oriented manufacturers, they are a
specific type of service invoices, which do not go through GTS, but another
tax verification process.
PO number(s) are searched in the comments field.
From the invoice itself, it is not clear if Carrier or Shipper are to be identified as
the vendor. ICC will determine the one or the other depending on vendor download
data.
Capturing of the Shipment route is not implemented as this field does not exist in
VIM.
12.3.5 Working with the AFTCS programs

Chinese invoices require an Anti Forge Tax Control System (AFTCS) validation. This
section describes VIM programs you can use in this context. These programs are
used only for China.
AFTCS Admin Tool

The program is used to check and modify the validation statuses for the Chinese
invoices.
Download and Upload file for Anti Forge Tax Control System
The program is used to upload and download the data for the AFTCS
validation.

12.3. China
12.3.5.1 Working with the AFTCS Admin Tool

To check and modify validation statuses:
1. Run the /OPT/VIM_AFTCS_ADMIN transaction.
2. Enter selection criteria.
Note: The following list provides additional information about the more
complex options.
AFTCS Val. Ind.

Anti Forge Tax Control System (AFTCS) validation indicator
Enter one of the following parameters:
U
Upload
M
Manual
A
Administrator
<blank>
Not Verified
3. Click .
The program selects the DP documents based on the values provided in the
selection criteria. It considers only the DP documents for China.

4. Select the DP documents and set the AFTCS validation indicator for them.
5. Click the Confirm AFTCS Validation button in the application toolbar.

The program sets the validation indicator and releases the DP document from
the exception Verification Required.
12.3.5.2 Working with the Download and Upload file program

The program is used to upload and download the data for the AFTCS validation.
The data from the upload file is used to set the verification indicator of the DP
invoices.
To upload and download data for the AFTCS validation:
1. Run the /OPT/VIM_AFTCS_FILE transaction.

The selection screen differs depending on the type of File Operation.

12.3. China
Download File
Upload File
2. Download file
a. In File Operation, click Download File.

b. Enter selection criteria for the download.
c. Click .
The program creates a CSV file for the following fields:
• INVOICE_CODE
• XBLNR
• BLDAT
• RECEPIENT_VAT_NO
• VENDOR_VAT_NO
• GROSS_AMOUNT
• TAX_AMOUNT

• SECRET_CODE
3. Use the CSV file to manually check the invoices with the government authorized
software.
Note: This software is not part of the VIM functionality.
4. Upload File
a. After validation, upload the validated records in the same format (CSV file
with fields in the same order as downloaded).
b. Enter the path to the CSV file in File Path.
c. Click .
The uploaded records are used to release the corresponding DP documents
from the exception and the DP workflow will run the business rules again.

The following business rules are specific for China, each for PO and NPO. For more
information, see Part VI “Business rules” in OpenText Vendor Invoice Management for
SAP Solutions - Reference Guide for Invoice Solution (VIM-RGD).
• Missing/invalid invoice code format
• Missing/invalid characters in secret code
• Invalid common ordinary invoice (VAT exists)
• Invoice older than allowed
• Invalid vendor invoice number
• Check hand written invoice
• Verification required

The following indexing screen fields are specific for China:
• Secret code: 108 characters: 4 fields of 27 characters each
• Invoice code: 12 characters
• Validation code: 30 characters
• Not hand written check box: 1 character
• Serial number (for PO items): 20 characters

12.4. India
12.4 India
This section describes the main incoming invoice processes in India, and how ICC
and VIM support them. The localization for India in VIM enables you to handle
different types of taxes imposed in India. You can also handle the relevant account
numbers of vendors during processing an NPO or PO invoice in India. When
processing an invoice, the system cross-checks the information provided in the
vendor master record related to India.
Categories The following invoice categories are introduced for PO invoices for India:
Domestic Material
Invoices raised by vendors in India where the purchase order is a standard PO
Domestic Service
Invoices raised by vendors in India where the purchase order is a service PO.
Import Material
Invoices raised by vendors outside India where the purchase order is a standard
PO.
Import Service
Invoices raised by vendors outside India where the purchase order is a service
PO.
For NPO invoices, no invoice categories are introduced.
For information how to configure categories, see Section 15.1.1.7 “Invoice

categories” in OpenText Vendor Invoice Management for SAP Solutions - Configuration
Guide for Invoice Solution (VIM-CGD) and Section 15.2 “Invoice categories, category
groups, and mapping” in OpenText Vendor Invoice Management for SAP Solutions -
12.4.1 Introduction to GST

Goods and Services Tax (GST) is an indirect taxation in India. GST merges most of the
existing taxes into a single system of taxation. It was introduced as The Constitution
(One Hundred and First Amendment) Act 2016.
GST is a comprehensive indirect tax on manufacturing, sale and consumption of

goods and services throughout India (except state of Jammu and Kashmir), to
replace taxes levied by the central and state governments.
Merging several Central and State taxes into a single tax, GTS is intended to mitigate
cascading or double taxation, facilitating a common national market. GST is
expected to be levied only at the Destination Point.
As per information in public domain, GST is to be effective from 1 July 2017.

12.4.2 Tax components in GST

The following table shows the applicable tax components for different transactions:
Intra-state Union Interstate Imports Exports

territory
Tax component CGST+SGST CGST+UTGST IGST IGST Zero rated
12.4.3 Impact of GST invoices on VIM

• Capture and process GST related information from incoming invoices
• Calculate tax based on GST scenarios (CGST, S/UGST, and IGST)
• Post into SAP (Accounts Payable)
12.4.4 Supported scenarios for GST invoices

GST Support is enabled for the following scenarios:
• Material Invoices (MIRO)

• Import Procurement
• Service Procurement
• Reverse charge mechanism
• NPO Invoices (FB60)
12.4.5 Business rules relevant for GST

VIM 7.5 SP6 (VIM 7.0 SP10) introduces the following business rules / process types
as part of the GST implementation for VIM.
Business rules for PO invoices
• 419 - Missing/Invalid GST Partner (PO)

• 421 - Missing/Invalid Vendor GST Registration number (PO)
• 423 - Missing/Invalid HSN/SAC code (PO)
• 428 - Missing/Invalid Receiving Location GST Registration No (PO)
Business rules for NPO invoices
• 420 - Missing/Invalid GST Partner (NPO)

• 422 - Missing/Invalid Vendor GST Registration number (NPO)
• 424 - Missing/Invalid HSN/SAC code (NPO)
• 429 - Missing/Invalid Receiving Location GST Registration No (NPO)
The following business rules have been introduced for India in earlier versions:

12.4. India
Business rules for PO invoices
• GR Not Done - Simple Check
• Invalid Tax Description (PO)
• Missing Vendor ECC Number (PO)
• Mismatch Vendor ECC Number (PO)
• Missing Vendor CST Number (PO)
• Mismatch Vendor CST Number (PO)

• Missing Vendor TIN/TOT Number (PO)
• Mismatch Vendor TIN/TOT Number (PO)
• Missing Vendor LST Number (PO)
• Mismatch Vendor LST Number (PO)
• Missing Vendor PAN Number (PO)
• Mismatch Vendor PAN Number (PO)
• Missing Vendor STC Number (PO)
• Mismatch Vendor STC Number (PO)
Business rules for NPO invoices
• Invalid Tax Description (NPO)
• Missing Vendor PAN Number (NPO)
• Mismatch Vendor PAN Number (NPO)
• Missing Vendor STC Number (NPO)
• Mismatch Vendor STC Number (NPO)
• Missing Vendor CST Number (NPO)
• Mismatch Vendor CST Number (NPO)
• Missing Vendor TIN/TOT Number (NPO)
• Mismatch Vendor TIN/TOT Number (NPO)
• Missing Vendor LST Number (NPO)

• Mismatch Vendor LST Number (NPO)

12.4.6 Indexing screen fields relevant for GST

There are some screen fields that are exclusively used for Indian localization. For
general information about the screen field configuration, see Section 15.3.2
“Characteristic specific screen fields” in OpenText Vendor Invoice Management for SAP
To support the GST implementation for VIM, VIM 7.5 SP 6 (VIM 7.0 SP10)
introduces the following fields:
DP header fields
• GST_PART: GST Partner
• GST_REG_NUM: Vendor GST registration number
• PLC_SUP: Place of supply
• REC_GST_REG_NUM: Receiving Entity GST Registration Number
DP item field
• HSN_SAC: HSN/SAC code
• CUSTOMS_VAL: Assessable value
The following fields that are exclusive for Indian localization have been introduced
with earlier versions:
• TAX_Desc
• CST_NO
• PAN_NO
• STC_NO
• LST_NO
• ECC_NO
• EDC_CESS
• EXC_DUTY
• TIN/TOT
• SAHE_CESS
Except the ECC_NO field, which is marked as HIDE for Non PO invoices, all other
fields are INPUT fields for PO and Non PO invoices.

12.4. India
12.4.7 Known limitations regarding GST

Regarding posting of PO/NPO invoices (BDC 2200) using BAPI, see the following
limitations:
• SAP has not enabled MRM BAPI for GST scenario for India.
• Posting of GST invoices using BDC 2200 for India is not possible in a standard
SAP S/4HANA system. BDC 2200, which is used for posting of PO invoices, uses
the same BAPI, that is BAPI_INCOMING_INVOICE_CREATE.
• Partial support is possible for BDC 2200 with a modification to the BAPI. After
implementing modification, invoices can be posted with correct amounts along
with GST information from VIM using BDC 2200.
• Refer to CI-98 of VIM 7.0 SP10 (VIMI-19345) for specific instructions related to
the SAP BAPI modification.
12.4.8 Downloading Vendor Data to Staging Table

To integrate ICC into VIM, you must download the vendor database from SAP S/
4HANA to the /OPT/VIM_STG_LIF staging table. For more information, see Section
7.2.1 “Downloading the vendor database from SAP S/4HANA” in OpenText Vendor
Invoice Management for SAP Solutions - Administration Guide (VIM-AGD).
Note: In older versions of VIM, there was a separate download program to be

used for India localization. There is no need to use this program any more.
12.4.9 PO based excise invoices

VIM supports posting of PO based excise (manual) invoices. In the basic excise duty
(BED), an excise value is transferring from the MM pricing procedure to the tax
procedure. The corresponding logic is not included into standard VIM but can be
implemented if required, based on a correction instruction.
To get the correction instruction, contact OpenText Customer Support referring the
internal number VIMI-15704. The minimum support package level is VIM 7.0 SP4 or
VIM 7.5 SP1.
In SAP S/4HANA, there are two tax procedures TAXINN and TAXINJ for calculating
the excise tax in India.
TAXINN
• TAXINN is a condition-based tax procedure.

• The tax code must be maintained in condition record.
• The tax condition record is maintained using the FV11 transaction.
• TAXINN only supports condition-based excise determination.

TAXINJ
• TAXINJ is a formula-based tax procedure.

• TAXINJ was most commonly used with SAP R/3 4.7 but newer implementations
use TAXINN.
• Tax code plays a vital role because the tax rate is maintained in tax code in the
FTXP transaction.
Example 12-1: Scenario with the TAXINJ calculation procedure
Customer uses an excise value that passes from the MM pricing procedure to
the tax procedure. Also the value of central sales tax (CST) passes from the
Taxes screen to Conditions of the PO.
JEXC is a condition type used in the MM pricing procedure for manual excise.
A value or percentage entered in JEXC in the pricing procedure is transferred to
the tax procedure JM01 condition type (basic excise duty). Using subtotal 5 in
MM pricing procedure against condition type JEXC will pass on this value to
the basic excise duty JM01 in the tax procedure.
In the MM pricing procedure, also condition type NAVS (non-deductible tax) is

used. It passes the value of CST from the Taxes screen to Conditions of the PO.
12.5 Northern Ireland

In the process of the United Kingdom leaving the EU, a special agreement has been
made for Northern Ireland (NI), regarding support of goods invoices between the
EU and Northern Ireland. Starting with January, 1st, 2021 and until at least
December, 31st, 2024, goods deliveries between NI and the EU are still treated as EU
intra-community supplies in most cases. Services are not included into this.
For goods deliveries to or from the EU, companies residing in NI use a special VAT
ID that begins with prefix XI. This VAT ID is maintained in master data records in
SAP.
For more information about relevant changes in SAP functionality, see the following
SAP notes:
• 2768412 - Recommendations for Brexit in FI

• 2885225 - BREXIT: Through the Transition Period and Beyond
Note: Make sure that among the SAP notes suggested for implementation in
these notes, the note 3000100 or the corresponding support package is
implemented. It is required by the new VIM functionality.
Supported VIM supports the process in the following areas:

areas
• The OCR solutions IC4SAP and CC4SAP can recognize the new VAT IDs.

12.5. Northern Ireland
• VIM Foundation inbound staging tables include the new VAT IDs in new fields,
which can also be used in Business Entity Determination (version 2 of the profile
scenario PS08_INVOICE).
• Pre-VIM 7.6/20.4 version 1 of the IC4SAP and CC4SAP extraction profile scenario
PS08_INVOICE checks against the new tax IDs.
• VIM Invoice Solution business rules take the new VAT IDs into account when
validating VAT IDs.
• Country based characteristics logic can support the process by setting the
characteristic value to XI.
Limitations
• No changes to the standard invoice solution configuration is delivered. Settings

for matching logic of Business Entity Determination (when using IC4SAP/
CC4SAP) is provided in the BC sets.
• Currently older OCR solutions, ICC/BCC, do not support the new VAT IDs. As a
workaround for vendor recognition, the new VAT ID can be maintained in the
field STCD5, or tax category GB5 can be created for the BP transaction.
• If you use the new characteristic XI, you can copy the characteristic specific
configuration from the existing configuration for the United Kingdom and apply
appropriate changes.
• Determination of intra-community supplies is done by using the address data
only. There is no distinction of goods versus services implemented in standard.
You can implement a project specific user exit for this.
Using charac- To enable the new characteristic, the Z constant 005 / UK_NI_CHARACT must be set to
teristic XI X. Use the same Z constant to maintain the user exit (function module) name that is
called to distinguish between goods and services invoices, as described in the
following.
To set up characteristic XI, navigate to the following node in VIM customizing:
Run the /N/OPT/SPRO transaction and navigate to OpenText Vendor Invoice

Management Invoice Solution > Document Processing Configuration > Document
Type Configuration > Characteristic Specific Document Type Configuration.
You can use one of the existing configurations, for example GB, and copy the entries
into the new characteristic XI. After that, verify and adjust the settings at the
subnodes. Keep in mind that the settings for XI must most likely correspond to those
used for the United Kingdom before leaving the EU.
User Exit You can implement a user exit to extend the provided logic:
function
• To override the determined characteristic
• To provide the service invoice flag

You can set the service invoice flag in the exit depending on the invoice data. For
example, you can implement purchase order item checks or vendor checks, to detect
service invoices.
The function module must have the following parameters:
Importing parameter
IS_1HEAD of type /OPT/VIM_1HEAD - contains the invoice header
Changing parameter
CV_CHAR of type /OPT/DCHARCT_DE - contains the already determined
characteristic XI. Assign a new value, for example GB if the invoice is a service
invoice.
Exporting parameter
PV_SERVICE of type ABAP_BOOL - assign X if the invoice is a service invoice,
otherwise assign a blank value.
Maintain the function module name in the Z constant 005 / UK_NI_CHARACT instead
of the general value X used to enable the logic.
12.6 Poland
VIM supports the payment split functionality for Poland. The payment split
functionality works with a business rule exception. The user has to manually
perform the payment split.
The features that are provided in this version include the following:
• Business rule to trigger when field Splitpayment sent from OCR is active
• Process type 514 for PO document types

• Process type 515 for NPO document types
12.6.1 Activating the process types configuration

To configure process types for the payment split business rule:
1. Run the OPT/VIM_8CX1 transaction.

Alternatively, run the /OPT/SPRO transaction and navigate to OpenText Vendor
Invoice Management Invoice Solution > Document Processing Configuration
> Process configuration > Maintain Process Types.
2. Maintain process type 514 - Invoice subject for payment split(PO) as an

exception.
3. Configure the following user process options to the process type:

12.6. Poland
4. Maintain process type 515 - Invoice subject for payment split(NPO) as an

exception.
5. Configure the following user process options to the process type:
12.6.2 Configuring document types

In this step, you configure the split payment functionality for baseline document
types PO_S4 and NPO_S4.
To assign the payment split process type to document type PO_S4:
1. Run the /OPT/VIM_1CX1 transaction.

> Document Type Configuration > Maintain Document Types.
2. On the Document Type Definition Overview screen, mark the document type
PO_S4 and double-click Document Processes in the Dialog Structure.

3. Configure process type 514 - Invoice subject for payment split(PO).

4. Mark process type 514 and double-click Proc. Type. Det. Sequence in the
Dialog Structure.
5. On the Proc. Type. Det. Sequence Overview screen, maintain process type 514.
6. Mark the process type and double-click Sequence Steps in the Dialog
Structure.
7. On the Sequence Steps Overview screen, configure the process type with the
business rule check function /OPT/VIM_DET_PROC_SPLITPAYMENT.
8. Double-click Index Screen Options in the Dialog Structure.
9. On the Index Screen Options Overview screen, configure the DP document
process type.
To assign the payment split process type to document type NPO_S4:

1. Run the /OPT/VIM_1CX1 transaction.
> Document Type Configuration > Maintain Document Types.
2. On the Document Type Definition Overview screen, mark the document type
NPO_S4 and double-click Document Processes in the Dialog Structure.

12.6. Poland
3. Configure process type 515 - Invoice subject for payment split(NPO).
4. Mark process type 515 and double-click Proc. Type. Det. Sequence in the
Dialog Structure.
5. On the Proc. Type. Det. Sequence Overview screen, maintain process type 515.
6. Mark the process type and double-click Sequence Steps in the Dialog
Structure.
7. On the Sequence Steps Overview screen, configure the process type with the
business rule check function /OPT/VIM_DET_PROC_SPLITPAYMENT.
8. Double-click Index Screen Options in the Dialog Structure.
9. On the Index Screen Options Overview screen, configure the DP document

process type.
To configure the characteristic specific document type for Poland:
1. Run the /N/OPT/SPRO transaction and navigate to OpenText Vendor Invoice

Document Type Configuration > Characteristic Specific Document Type
Configuration.
2. On the Characteristic Specific Attributes Overview screen, mark the PL

characteristic and double-click Characteristic Specific Process Types in the
Dialog Structure.
3. On the Characteristic Specific Process Types Overview screen, configure the

process types 514 and 515:

12.7 Russia
This section describes the main incoming invoice processes in Russia, and how ICC
and VIM support them. In Russia, almost 100 percent of the invoices are based on a
purchase order. VAT invoices without goods entry or service entry must not be
posted without manual intervention.
A corrective invoice refers to an invoice that has arrived earlier at the customer. The
corrective invoice contains item changes that can be posted as invoice, credit memo,
subsequent debit, or subsequent credit.
VIM support is integrated in the PO_S4 document type.
Russian invoice forms do not have a field specified for the PO number. OpenText
recommends that the vendor is asked to print the PO number onto the invoice,
either into a special field or always into the same header location. Otherwise, it is
always a manual task for the accountant to find the matching PO.
Russian delivery note (TORG-12) and acceptance of service document (ACT) do not
contain information on PO or related invoice. Matching is very difficult. OpenText
therefore recommends scanning invoice and TORG-12 together or scanning invoice
and ACT together.
ICC tries to identify the invoice category based on key words. It might be necessary
to adjust it in the ICC validation screen. The following categories are supported, as
shown in the selection box of the validation screen:
• VAT invoice goods

• VAT invoice services
• Revision invoice goods
• Revision invoice services
• Correction invoice (goods)
• Revision of correction invoice (goods)
• TORG-12 (goods)
• Acceptance ACT (services)
• Proforma invoice
• Import invoice
• Combination of VAT invoice goods + TORG-12

12.7. Russia
• Combination of VAT invoice services and AccACT

• Other
The list shows some combinations of documents because, for example, an invoice
can come in together with the ACT in one PDF, or also the invoice without ACT
and the ACT come in separately, and then VIM has to wait until all documents are
complete before posting the invoice.
Revision invoices are not covered 100 percent by ICC and VIM.
12.7.1 Goods invoices

The goods invoice process is based on two printed documents: the bill of lading
(TORG-12) and the goods VAT invoice.
The vendor sends the VAT invoice to the customer. The TORG-12 is sent together
with the goods.
Supporting the goods invoice process with ICC and VIM

1. The VAT invoice and the TORG-12 should be scanned together and sent to ICC
for OCR.
2. ICC extracts header and item data, and identifies the invoice category.
3. From the VAT invoice, VIM starts the DP process.
4. VIM performs a PO mapping if the PO number is available from ICC.
5. VIM waits for the goods receipt.
6. If data is missing, VIM performs other checks.
7. With all the required data being available, the invoice can be posted
automatically.

12.7.2 Service invoices

The Russian service invoice process is based on 2 printed documents: the act of
acceptance (ACT) and the VAT invoice. The vendor sends the ACT and the VAT
invoice to the customer.
Supporting the service invoice process with ICC and VIM

1. The VAT invoice and the ACT are scanned together and sent to ICC for OCR.
2. ICC extracts header and item data, and identifies the invoice category.
3. From the VAT invoice, VIM starts the DP process.

4. VIM performs a PO mapping if the PO number is available from ICC.

5. VIM waits for GR or SES.
automatically.

12.7.3 Corrective invoices

In the corrective invoice scenario, goods arrive with quality or quantity differences
to TORG-12. The customer requests an invoice change. The vendor sends a
corrective invoice to the customer.
Supporting the corrective invoice process with ICC and VIM

1. The corrective invoice is scanned and sent to ICC for OCR.
2. ICC extracts header data including the original invoice number and date. ICC
also extracts item data including special item delta details. ICC identifies the
invoice category.
3. The VIM DP process is started.
4. VIM calculates which document lines need to be posted and how. VIM considers
only the difference to the original invoice.
For a quantity discrepancy, VIM creates an invoice or a credit memo.
For a price discrepancy, VIM creates subsequent debit or subsequent credit.
automatically.


12.8. Spain

The following business rules are specific for Russia. For more information, see
Section 23.83 “Russia - Wait for TORG-12/ACT - Simple Check (PO)” in OpenText
Vendor Invoice Management for SAP Solutions - Reference Guide for Invoice Solution
(VIM-RGD) and the subsequent sections.
• Wait for TORG-12/ACT - Simple Check (PO)

• Wait for TORG-12/ACT - Enhanced Check (PO)
• Original Invoice Mismatch (PO)

The following indexing screen fields are specific for corrective invoices:
• Original invoice number

• Original invoice date
• Contract number
12.8 Spain
To support Spanish “Suministro Inmediato de Información” (Immediate Supply of
Information; SII), SAP proposes in OSS note 2409025, version 6, to store long invoice
numbers into more than one field. This means the fields XBLNR or BKTXT or Custom
in BKPF.
In this context, VIM provides the LXBLNR field to hold the complete/entire long
invoice number in VIM. During DP processing/posting, VIM supports the following
options, aligned with SAP’s proposal, this means based on XBLNR and BKTXT in BKPF.
• Option 1
Prefix part goes to XBLNR. Sequence Number part goes to BKTXT.
• Option 2
Prefix part goes to BKTXT. Sequence Number part goes to XBLNR.
• Option 3
Based on Custom field in BKPF.
If you choose this option, this means a custom field in BKPF, to store either part or
complete invoice number. For this option, no out-of-the-box support is available.
You must customize BDC/BAPIs to save the invoice number into the custom field
while posting invoices.
Options 1 and 2 You configure two parts of the long invoice number, Prefix and Sequence Number,
using Z constant SET_REF_MAPPING_SP,to split into the fields XBLNR and BKTXT and
to post invoices accordingly.

The Z-constant SET_REF_MAPPING_SP allows configuring offset length for Prefix part
and Sequence Number part.
Example 12-2: Example values of Z-constant SET_REF_MAPPING_SP
• Option 1
Example value: X10,B25. 10 characters (Prefix) of the long invoice number
are mapped into XBLNR and the next 25 characters (Sequence Number) are
mapped into BKTXT.
• Option 2
Example value: B20,X16. 20 characters (Prefix) of the long invoice number
are mapped into BKTXT and the next 16 characters are mapped into XBLNR.
12.9 Switzerland
This section describes a VIM scenario for Switzerland: QR Bill, a new standard for
paper based invoices.
12.9.1 Processing Swiss QR Bills

Starting 30th of June 2020, Switzerland introduces a new standard for paper based
invoices: QR Bill. This standard defines the content of invoice payment slips. It
replaces the earlier standard Inpayment slip with reference (ISR), and adds a QR code
into the payment slip. The QR code is used to provide important information in a
reliable way, which can also be processed electronically much easier.
To support the introduction of the new payment slip standard, OpenText provides
new functions in the OCR solutions (ICC or BCC and IES) and in VIM.
Note: “Information Extraction Service” (“IES”) is used in this documentation

as a common technical term for both of the following OpenText products:
• OpenText™ Intelligent Capture for SAP® Solutions, formerly known as

OpenText™ Information Extraction Service for SAP® Solutions (IES on
premise)
• OpenText™ Core Capture for SAP® Solutions
VIM 16.3.4, VIM 7.5 SP10, ICC or BCC 16.7, and IES 16.7 introduce basic functions to
process Swiss invoices with QR code. Later support packages provide
improvements in the processing logic. This section provides an overview of
supported functions.

12.9. Switzerland
12.9.1.1 OCR support of QR Bills

The following QR code fields are supported by ICC or BCC and IES:
• IBAN / QR IBAN
• QR Bill reference
• QR Bill reference type
• QR unstructured message (Ustrd)
• QR structured additional data (StrdBkgInf)
In addition, if you use ICC or BCC, the complete content of the QR code is provided
in the OCR result table. Currently, the result line length is limited to 255 characters,
which might result in certain content elements being truncated.
Note: The last three fields in the list are dedicated fields in case of IES. In case
of ICC or BCC, they are modeled in VIM, based on the complete QR code
content, but are not provided as dedicated OCR result fields.
The new fields are not shown in the Validation client. The content is passed further
into the VIM process start.
12.9.1.2 VIM support of QR Bills

The OCR result fields are mapped into VIM invoice header fields in the following
way:
OCR field VIM field

IBAN / QR IBAN IBAN
QR Bill reference ESRRE
QR Bill reference type QR_REF_TYP
QR unstructured message QR_UNSTR_INFO
QR structured additional data QR_STRUC_INFO
The IBAN provided in the QR code is mapped into the same field in VIM that
normally stores IBAN found elsewhere on the invoice.
During the transitional period, both old and new standards may be used. OpenText
recommends that you configure all fields, for both standards, to be displayed in VIM
screens, with older standard fields open for input. After the transition is finished, for
most of the application users, all fields can be set to read-only mode. Administrators
or superusers might need to have it input-enabled to correct, if the need arises.
Finally, you can configure older standard fields like the ESR reference string (ISR-
Number in English and ESR-Nummer in German) to be hidden.

With VIM 7.5 SP10 / VIM 16.3.4, the IBAN and QR Bill reference extracted from the
QR code are passed into respective SAP document fields regardless of their content.
With VIM 7.5 SP11 / VIM 16.3.5, VIM distinguishes the following cases:
• QR IBAN and QR Bill reference of QRR format are provided: QR IBAN and QR
Bill reference are passed into the dedicated SAP document fields.
• Generic IBAN and QR Bill reference of SCOR format are provided: IBAN is used
as standard bank data field, QR Bill reference is passed into the payment
reference field (KIDNO).
• Generic IBAN and no QR Bill reference provided: IBAN is used as standard bank
data field.
After the release of VIM 7.5 SP11 / VIM 16.3.5, several bugs related to QR Bill
processing have been fixed. The support of the new fields QR Unstructured
message and QR structured additional data has been implemented in VIM 7.6
and VIM 20.4. These changes can also be implemented with manual correction
instructions. For more information, see “Implementing the QR Bill support in VIM”
on page 227.
VIM offers a business rule to check the data related to QR Bills. The new process
type number in the standard configuration is 438 Invalid QR Bill data, checked by
the function module /OPT/VIM_DETERMINE_PROC_438. This is enabled in the
characteristic specific process types for Switzerland only.
Note on Liechtenstein
VIM does not provide standard configuration for Liechtenstein but, if needed,
the same function module can be used for Liechtenstein QR Bill invoices.
12.9.1.3 Support of IDOCs with QR Bills

VIM supports incoming invoice IDOCs with both Inbound Configuration processing
and older VIM 7.5 IDOC handler module /OPT/DP_INBOUND_IDOC_PROC. The
mappings for fields QR Unstructured message and QR structured additional
data are currently not standardized. They can be implemented by extending the
provided mapping. See the SAP Note 2913397 for a mapping example, and verify
the IDOC content you receive from your business partners.
IDOC support is included into VIM 7.6 / VIM 20.4, but can also be implemented
with a manual correction instruction. For more information, see “Implementing the
QR Bill support in VIM” on page 227.

12.9. Switzerland
12.9.1.4 Implementing the QR Bill support in VIM

All features of QR Bill support in VIM are based on corresponding SAP Support
Packages or SAP notes. For more details, see the collective SAP note 2928683.
The minimum supported VIM release and Support Package levels are: VIM 7.5 SP10
or VIM 16.3.4.
OCR products
• ICC or BCC support all fields with 16.7 and later versions.
• IES (IC4SAP): 16.7. Use latest patches (release July 2020) for the bill information
fields.
VIM 7.5 SP11 / VIM 16.3.5 improves the handling in terms of distinguishing the
scenarios with QR IBAN and QRR reference versus standard IBAN with SCOR or no
special reference. You can implement those support packages, or you can request a
CI for the same changes from OpenText referencing the internal ticket VIMI-24508.
Processing the fields QR Unstructured message and QR structured additional

data is included into VIM 7.6 / VIM 20.4. You can also request a CI for the same
changes referencing the internal ticket VIMI-25674.
Note: Correction instruction VIMI-25674 includes important bug fixes.
Processing of IDOCs is included into VIM 7.6 / VIM 20.4. You can also request a CI
for the same changes referencing the internal ticket VIMI-25780.
12.9.1.5 Known issues

The issues listed in the following are known as of June 2020.
VIMI-25846
Currently the new way of processing parked invoices during VIM 16.3 DP
workflow does not support changing QR Bill specific data from the indexing
screen.
VIMI-25781
Liechtenstein is not supported in the context of QR Bills. For more information,
see Note on Liechtenstein on page 226.

12.10 Thailand
Although VIM is not localized for Thailand, OpenText recognizes the needs of
customers to comply with legal requirements and supply vendor branch code when
posting documents with Thai company codes. It is not intended to provide a
comprehensive implementation around vendor branch codes or other Thailand
specifics.
VIM 16.3.1 (and VIM 7.5 SP7) introduce branch code support into the following VIM
areas:
• DP indexing screen. You can enable the branch code field depending on the
country. Search help is supported too. For Thai company codes, the default
branch code from vendor master is assigned on change of vendor number or PO
number.
• Background posting of Non PO invoices with standard BDC ID 34.
• Background posting of Non PO invoices with standard BDC ID 42.
• Background posting of PO invoices with standard BDC ID 6.
For online posting, for example with BDC IDs 1 (PO) or 40 (NPO), or for background
posting with BDC ID 41, a simple change of the BDC ID definitions is required. For
more information, see “Adjusting online posting BDC ID definitions” on page 232.
Note: This change is not delivered with standard VIM.
VIM does not validate a manually entered branch code in the DP indexing screen.
SAP provides such validation at the time of posting. Alternatively, you can
implement validation as a customer specific DP business rule. VIM users are advised
to use search help (F4) to enter values.
As a prerequisite, the SAP Note 2147598 must be implemented in your system.

Contact SAP support with component XX-CSC-TH-AC if it is not visible for you on
the SAP support site.
This section provides an example minimum configuration to introduce the branch

code field into the DP process.

12.10. Thailand
12.10.1 Enabling branch code in the DP indexing screen

In this step, you create new customizing for Thailand or adjust the eventually
existing one.
Note: The example configuration described here and in the next section is not
delivered as standard VIM configuration because VIM is not localized for
Thailand. That information is provided for your reference to help
implementing the support for branch code.
To enable branch code in the DP indexing screen:
1. Run the /OPT/SPRO transaction and navigate to OpenText Vendor Invoice

Document Type Configuration > Maintain Document Types.
2. For each of the existing DP document types, create the following entry in the
sub-node Index Header Configuration:
Field name
Enter TH_BCODE.
Field Stat
Status. Enter Hide.
3. Navigate to OpenText Vendor Invoice Management Invoice Solution >

Document Processing Configuration > General Configuration > Translations/
Labels for Index Screen Fields.
4. Select Translation/Labels for Header Fields in the dialog box that is displayed.
Create new entries for the field TH_BCODE for languages required by your
implementation. The following screenshot shows an example for English:
5. Navigate to OpenText Vendor Invoice Management Invoice Solution >

Characteristic Specific Document Type Configuration.
6. For all characteristic values shown on the initial screen, apart from the
characteristic value * (asterisk) and the eventually existing TH, create the
following entry in the sub-node Index Header Configuration:

Current Role
<empty>
Field Name
Enter THAILAND.
Applicable Inv Type
Applicable invoice type: Enter All Invoices.
Field Status
Enter Hide.
7. On the main screen of the same customizing node, create a new entry for
characteristic TH, unless you already have it. See the following screenshot for
example values:
8. In the Index Header Configuration sub-node, create the new entries for the
characteristic TH. If you already have entries for TH, only add the two new lines
with the field name THAILAND and TH_BCODE:

12.10. Thailand
9. In the Characteristic specific process types node, add the following new entry:
Note: At least one entry in the characteristic specific process types is

required for screen logic to work correctly. You may use other process
types as required by your project. In particular, you can require that the
branch code will be entered in all Thailand invoices explicitly. For this,
create a custom process type based on the field check and enable it for
Thailand through invoice characteristics, as the following screenshots
show.
Process type (process options assignment is not shown):

IMG path: OpenText Vendor Invoice Management Invoice Solution >
Document Processing Configuration > Process Configuration > Maintain
Process Types
Process type determination sequence and steps:


Maintain Document Types
Characteristic specific process type:

Characteristic Specific Document Type Configuration
12.10.2 Adjusting online posting BDC ID definitions

You might want to use online posting with VIM (example BDC IDs: 1, 40) or
background posting with BDC ID 41. In this case, the branch code needs to be
transferred into the screens of SAP transactions FB60 or MIRO. To achieve this, each
of the used BDCs must be extended to pass the value of the field TH_BCODE from the
DP document into the SAP parameter ID_J_1TPBUPL.
To adjust online posting BDC ID definitions:
1. Run the OPT/SPRO transaction and navigate to OpenText Vendor Invoice

Process Configuration > Maintain BDC Procedures.
2. For each of the used BDC definitions, select it in the main screen, double-click
on the Parameters subnode and then click New Entries.

12.10. Thailand
3. Add the following entry:
Note: For this function to work, the SAP note 2376945 or a corresponding
SAP support package must be implemented in your systems.

Chapter 13
Processing leasing invoices
International Financial Reporting Standard (IFRS) 16 provides guidance on

accounting for leases. IFRS 16 is effective for most companies that report under IFRS
since January 1st 2019. The SAP solution for lease contract management is based on
the SAP Flexible Real Estate module (SAP RE-FX), which is integrated with SAP FI,
CO, and AA.
VIM enables you to process leasing invoices beginning with VIM 7.5 SP9 / VIM
16.3.3. The support of leasing invoices is implemented in VIM in several phases.
Currently OpenText provides basic support for leasing invoice processing. The
features that are provided now include the following:
• New DP indexing screen fields for contract data

• New dedicated DP document type (REC_S4 / REC_75) along with necessary
settings
• DP document type determination based on the field CLASSIFIER that can be sent
by OCR
• Logic module for determination of contract number based on external contract
number sent by vendor (G_HEAD_021)
• Business rule and screen logic to validate the contract number and contract
validity (process type 474)
• DP flow control including process options and a new role: Contract Manager
• The new BDC definition 2202 supports basic dialog posting with FB60. The
contract number is being passed into the document header.
With this way of posting, no real estate document is generated and no cash flow
status update is done.
• It is possible to use auto coding based on existing VIM logic. For example,
leasing invoice lines can be posted to specific clearing accounts as required by the
implementation.

Chapter 14
Translating VIM
This section describes the various aspects of translating VIM into a new language.
You find the full details of the specific SAP tools used, for example the SE63
transaction, in the SAP Help.
The information in this section is based on the SAP ECC 6.0 version. The procedure
may differ slightly in different versions of SAP S/4HANA. The translation aspects of
the Approval Portal are described in “Approval Portal translation” on page 289.
You do not have to translate VIM into a new language completely. SAP provides
tools to support a supplementary language or second language for texts that are not
translated. This is described in “Supplementary language” on page 295.
14.1 Roles and responsibilities

The translation project typically involves the following roles. This section describes
the responsibilities of each of these roles. An individual can play more than one role.
SAP Basis Admin
• Set up the system.

• Install all required languages.
• Import SAP proposal pool for VIM if available.
• Install VIM with the latest support packages (SPs).
SAP developer
• Set up the translation environment. This means, create the global work list.
• Enter the translation strings for workflow tasks, GOS texts, standard texts, and
IMG if the translator does not have authorizations for the respective transactions.
• Create transports.
• Provide transport requests to translator for table entries.
Translator
• Perform translation in work list.

• Perform translation of workflow tasks, GOS texts, and standard texts if they have
the authorization. If they have no authorization, provide translation strings in a
spreadsheet to the SAP developer.

Chapter 14 Translating VIM
14.2 Prerequisites
Before starting the translation project, the following basic prerequisites must be met:
• All required languages are installed.

• VIM is installed with latest support packages.
• All BC sets are activated.
• Latest transports are moved if there are any.
• Actual proposal pool is imported.
14.3 Setting up the environment

This chapter describes the various activities that you have to perform to set up the
environment for translations.
In an SAP S/4HANA system, there are the following ways of translating texts:
• You can translate ABAP Dictionary based texts directly by clicking Goto >
Translation from the menu on the screen in question.
• You can call up objects for translation directly in the SE63 transaction. To do this,
you must know the object type and the technical name of the object.
• You can translate objects via global work lists. Detailed knowledge of individual
objects is not required.
The following steps are run using the LXE_MASTER transaction.
14.3.1 Setting up target languages

In this step, you define all required languages as target languages for translation in
the SAP S/4HANA system.
To set up target languages:
1. To open the Translation Administration screen, run the LXE_MASTER

transaction.

14.3. Setting up the environment
2. On the Languages tab, click Translation Languages.

3. In the Translation Languages dialog box, click Add Languages, and select the
required translation languages.
4. Enter a priority for the language.
5. Specify a server for the language.

14.3.2 Adding target languages to a client

In this step, you choose a client for the translation project and add all languages to
this client.
To add target languages to a client:
1. On the Translation Administration screen, on the Languages tab,

click Languages per Client.
2. In the Client Selection dialog box, select the client that you want to define.
3. In the Clients dialog box, enter the target languages for translation in the
system.
4. If you want to specify the client as the translation client for all target languages
that are defined in the system, click Insert All Languages.

14.3.3 Maintaining the translation graph

In a translation graph, you define the source language for each target language and
for each language in which you develop.
To maintain a translation graph:
1. On the Translation Administration screen, on the Languages tab, click Graphs.
2. If you want to create a new graph, click Create New Graph in the Select Graph
dialog box.
3. In the Graphs dialog box, enter a name for the new translation graph.
4. Enter target language, original language and source language for all target
languages.

14.3.4 Defining object types for translation

Every translation object in an SAP system has an object type. Data elements,
messages, hierarchy node texts, and search helps are all examples of short text object
types.
In the translation environment, each object type is assigned to an object group. An

object group consists of object types that logically belong together because they have
a similar translation priority. For example, the short text object types listed above are
all assigned to object group A5 User Interface Texts because they appear on user
interfaces and therefore have a very high translation priority.
Object types and object groups enable you to define the scope of translation for each
target language. If you activate an object type for a target language, objects of this
object type are included in the work lists and statistics for this target language when
you create and then evaluate an object list to generate work lists and statistics.
To define object types for translation:
1. On the Translation Administration screen, on the Languages tab, click Object

Types.
2. Select the target language for which you want to maintain the object types.
3. In the Object Types dialog box, enter individual object types for translation.
The Search Help button shows all available object types.

Note: The list slightly differs in different SAP S/4HANA versions.
4. In the Object Type Selection (Object Groups) dialog box, expand the object
group and select the object types which are required for your translation work,
see “Object types for translation” on page 244. They are mostly grouped in the
object groups A5, A6 and B5.
Note: If there is no need to restrict the object types for each language, you
can enter the full list.
Table 14-1: Object types for translation
Object Object type Description

group
A5 ACGR Roles
A5 CA1 Interface Texts (FUGR)
A5 CA2 Interface Texts (FUGS)


group
A5 CA3 Interface Texts (FUGX)
A5 CA4 Interface Texts (PROG)
A5 CA5 Interface Texts (TRAN)
A5 DDLS CDS Views
A5 DT Dialog Texts
A5 DTEL Data Elements
A5 MESS Messages
A5 RPT1 Text Elements (FUGR)
A5 RPT2 Text Elements (FUGS)
A5 RPT3 Text Elements (FUGX)
A5 RPT4 Text Elements (PROG)
A5 RPT8 Text Elements (CLAS)
A5 SCT1 Screen Control (FUGR)
A5 SCT2 Screen Control (FUGS)
A5 SCT3 Screen Control (FUGX)
A5 SCT4 Screen Control (PROG)
A5 SHI3 Hierarchy Node Texts
A5 SHI5 Extensions of a Hierarchy
A5 SHLP Search Helps
A5 SOTR OTR Short Texts
A5 SRT1 Screen Painter Texts (FUGR)
A5 SRT2 Screen Painter Texts (FUGS)
A5 SRT3 Screen Painter Texts (FUGX)
A5 SRT4 Screen Painter Texts (PROG)
A5 SRT8 Screen Painter Texts (CLAS)
A5 TRAN Transactions
A5 VALU Fixed Values for Domains
A5 VARI Report Variants (System)
A6 TADC Tables (Customizing - Maintenance by Customers Only)
A6 TADG Tables (Customizing - No SAP UPD, Only INS)
B5 SSF SAP Smart Form


group
C6 DE Data Elements (not mandatory for VIM, because number of
message is big)
C6 NA Messages (not mandatory for VIM, because number of
message is big)
G5 DOMA Domains
The selected/entered object types are displayed in the Object Types dialog box,
together with the user who defined these settings and the date on which they
were last changed.
5. To activate the automatic distribution of SAP Pool proposal, enter 60 or 90 in

the Dist. New column.
6. Repeat this procedure for all other target languages defined in your system.
Note: You can assign the relevant object types in different steps in a flexible
way, not mandatorily in this step. For example, you can assign all object types
here to all relevant languages. In a later step, for example in “Creating the
object lists” on page 255, or in “Creating an evaluation run” on page 267, you
can restrict the list of object types which need to be collected in the object list or
work list.
14.3.5 Creating a translator profile

In this step, you assign a profile to every translator and coordinator created in the
system. Each user can have just one profile per target language. You cannot create
translators until translator profiles have been defined in the system. Each profile can
include one or more authorizations.
1. On the Translation Administration screen, on the Translators tab, click

Translator Profiles.
2. In the Translator Profile dialog box, click Create New Profile.

The Profiles dialog box contains a list of all authorization objects that are
available in the system for the translation environment.
The following authorizations are recommended for the profile of the translator:

3. In the Profiles dialog box, in the Profile field, enter a two-character ID and a
description of your profile.
4. Specify values for the authorization objects that you require for the new profile.
If you do not specify a value for an authorization object, the profile does not
grant any of the permissions that are controlled by this authorization object.
14.3.6 Maintaining translators

In this step, you assign the translators to each language.
To maintain translators:
1. On the Translation Administration screen, on the Translators tab, click

Maintain Translators.
2. On the Target Language selection screen, select the target language for which
you want to create the translator.
3. In the Translator field, enter the user ID. In the Profl. field, enter the profile.
Optionally, you can maintain Team and Translation Group.
4. Repeat the procedure for all languages.

14.3.7 Assigning collections to a translation graph

Collections are nothing but packages. In this step, you choose appropriate packages
to make relevant objects available for translation.
To assign collections to a translation graph:
1. On the Translation Administration screen, on the Languages tab, click

Collections to Graphs.
2. In the Select Graph dialog box, select the graph for which you want to assign
collections.
3. Enter all collections that correspond to translation objects.
4. Choose the recommended packages and/or any other OpenText collections. For
more information, see “OpenText collections for translation objects”

on page 249. Collections marked with optional are collections for customizing
and not relevant for translation if only the user interface is considered.
Table 14-2: OpenText collections for translation objects
Collection Version Description

/OPT/COA_UPLD VIM 7.5 To upload the COA details from file
/OPT/CP VIM 7.5 Open Text Cross Product Components
/OPT/IAP VIM 7.5
Opentext: Liability report for Parked
/OPT/VAN VIM 7.5
Invoice
/OPT/VIM VIM 7.5 Open Text VIM Development
/OPT/VIM_3S VIM 7.5 Supplier Self Service Component
/OPT/VIM_ADD_COST VIM 7.5 Additional Cost Handling
/OPT/VIM_AFS VIM 7.5 Open Text VIM Approval Flow Settings
/OPT/
VIM Analytics Data Collection
VIM_ANALYTICS_COLLECTIO VIM 7.5
Infrastructure
N (Optional)
/OPT/VIM_APPL1 VIM 7.5 VIM Application Extensions
/OPT/VIM_ARB VIM 16.3 ARIBA Suite Adapter Integration
/OPT/VIM_ARB4 VIM 16.3 ARIBA Suite Adapter Integration S4
/OPT/VIM_ARB_CFG (Optional) VIM 7.5 ARIBA Suite Adapter Integration
/OPT/VIM_ARCH (Optional) VIM 7.5 VIM Archiving Objects
/OPT/VIM_BL VIM 7.5 VIM Baseline Transactions
/OPT/VIM_BPF VIM 7.5 Best Practice Processing - Framework
/OPT/VIM_BW_ERP (Optional) VIM 7.5 Open Text VIM BW
/OPT/VIM_CA_DEV VIM 7.5 Package for Canada Development
/OPT/VIM_CMP VIM 7.5 Business Rule Framework
/OPT/VIM_DBP VIM 7.5 DashBoard Plugin
/OPT/VIM_EDOC VIM 7.5 E Document
/OPT/VIM_EDOC_SL03 VIM 7.5 E Document (SL03)
/OPT/VIM_FX_VA2_SRV VIM 16.3 OpenText Simple VAN Services Package
/OPT/VIM_FQST VIM 7.5 Package for withholding tax
/OPT/VIM_GATEWAY
VIM 7.5 VIM Gateway Component
(Optional)
/OPT/VIM_ICC (Obsolete in VIM Development Class for ICC specific
VIM 7.5
16.3) objects


ICC related objects still in use with
/OPT/VIM_ICC_BC VIM 16.3
BC_INBOUND
/OPT/VIM_ICC_TOOLS
VIM 7.5 ICC Interface - Tools for Problem Analysis
(Optional)
/OPT/VIM_IDH (Obsolete in VIM Open Text VIM Inbound Document
VIM 7.5
16.3) Handler
/OPT/VIM_IDX VIM 7.5 Package for new Indexing Screen
OpenText VIM Invoice Exception
/OPT/VIM_IE (Optional) VIM 7.5
Development
/OPT/VIM_IEWIZ (Optional) VIM 7.5 Open Text VIM IE Wizards
/OPT/KPI VIM 7.5 OpenText VIM KPI Dashboard
/OPT/VIM_LBA VIM 7.5 Level Based Approvals
/OPT/VIM_LEASING VIM 7.5 OpenText VIM, Leasing invoice support
/OPT/VIM_LIC_REP VIM 7.5 VIM and ICC licence reporting
Development Class for Line Item
/OPT/VIM_LINE_DER VIM 7.5
Derivation
/OPT/VIM_LOC (Optional) VIM 7.5 VIM Localization Issues
/OPT/VIM_LOGGING (Optional) VIM 7.5 Open Text VIM Logging - Infrastructure
/OPT/VIM_LOGGING_EXC Open Text VIM Logging - Exception
VIM 7.5
(Optional) Details
/OPT/VIM_NFE VIM 7.5 NFE treatment (Nota Fiscal Electronica)
/OPT/VIM_NOTIF VIM 7.5 VIM Notifications
/OPT/VIM_OAP VIM 7.5 Approval Portal RFCs - Components
/OPT/VIM_PMC VIM 7.5 Open Text VIM Workplace
Open Text VIM Workplace - Smart
/OPT/VIM_PMC_BS VIM 7.5
Selection
Open Text VIM Workplace - Plug-In
/OPT/VIM_PMC_PLUGIN VIM 7.5
Utilities
/OPT/VIM_PMC_SCAN VIM 7.5 OpenText VIM Workplace - Scan function
/OPT/VIM_POEX VIM 7.5 PO exception handling
/OPT/VIM_REPORTS VIM 7.5 VIM Reports
/OPT/VIM_RPT VIM 7.5 VIM Analytics
/OPT/VIM_SCE VIM 7.5 Open Text VIM Single Click Entry
/OPT/VIM_SCOD (Optional) VIM 7.5 VIM smart Coding
/OPT/VIM_SFW (Optional) VIM 7.5 OpenText VIM Switch Framework


Open Text - VIM SRM Related
/OPT/VIM_SRM VIM 7.5
Development
/OPT/VIM_UPDATE (optional) VIM 7.5 Open Text VIM Update API
/OPT/VIM_VA2 VIM 7.5 Objects for new VIM Analytics Report
/OPT/VIM_VD7 (Optional) VIM 7.5 Version dependent objects VIM 7.0 / 7.5
/OPT/VIM_XECM VIM 7.5 OpenText VIM: extended ECM Integration
/OPT/VIM_SSF_ERP (Obsolete) VIM 7.5
/OPT/VIM_UPG (Optional) VIM 7.5
/OPT/VIM_YEAR_END VIM 7.5
/ORS/000007 VIM 7.5 Parked Invoice Approval
/ORS/000007_2 VIM 7.5 Baseline 2 -
/ORS/000007_4 VIM 7.5 IAP - Version 9.2: Validation function ..
/ORS/000007_5 VIM 7.5 IAP - IE Monitor Report Plug In
/ORS/000007_6 VIM 7.5 IAP - Version 9.3: Invoice Processed by me
Opentext: Parked Invoice Approval
/ORS/000007_7 VIM 7.5
diagnostic
/ORS/000007_8 VIM 7.5 OPENTEXT: - Mobile Invoice Approval
/ORS/000007_ENH1 VIM 7.5 OpenText VIM Approval Process
/ORS/IAP (Obsolete) VIM - New Invoice Approval Process
RapidFlow Financials - IE Baseline
/PTGWFI/0000000002 VIM 7.5
Version
Block Invoice Resolution Development
/PTGWFI/BIR VIM 7.5
Cla
/PTGWFI/COA VIM 7.5 Chart of Authority Development Class
Cross Product Element Development
/PTGWFI/CP VIM 7.5
Class
/PTGWFI/IEA VIM 7.5 IE Enhancements: Archiving Supports and
/PTGWFI/IEM VIM 7.5 Optura IE monitor Dev Class
/PTGWFI/LIX VIM 7.5 Invoice Exception with logistic Invoice
/PTGWFI/ORS_002 VIM 7.5 Objects reused in ORS
/PTGWFI/PIR VIM 7.5 Parked Invoice Resolution Development
/PTGWFI/SMI (Optional) VIM 7.5 Suspend Mode Invoice Workflow Process
Invoice deletion/cancellation and re-
/PTGWFI/VIM_001 VIM 7.5
creation

If Business Center (BC) is deployed together with VIM, add the following BC VIM
solution-specific collections:
From VIM version / Business

Collection Description
Center version
/OTX/PF00 BC Cross Comp VIM 7.5 SP4 / Business Center 16
/OTX/PF01 BC Inbound VIM 7.5 SP4 / Business Center 16
/OTX/PF02 BC Process VIM 7.5 SP4 / Business Center 16
/OTX/PF03 BC Workplace VIM 7.5 SP4 / Business Center 16
/OTX/PF04 BC Process Conf VIM 7.5 SP4 / Business Center 16
/OTX/PF62 BC Fiori Configuration Business Center 16
/OTX/PS03 BC Solution - VIM Foundation VIM 7.5 SP4 / Business Center 16
/OTX/PS08 Business Center VIM - Basic VIM 7.5 SP8 / Business Center 16.3.2
/OTX/PS30 VIM Basic VIM 7.5 SP4 / Business Center 16
Business Center VIM - Coding UI
/OTX/PS301 VIM 7.5 SP9 / Business Center 16.3.3
Handler
/OTX/PS31 VIM Fiori Integration VIM 7.5 SP4 / Business Center 16
/OTX/PS32 VIM Simple Coding VIM 7.5 SP4 / Business Center 16
/OTX/PS33 VIM OData service VIM 7.5 SP4 / Business Center 16
/OTX/PS3303 Fiori Apps and Workplace VIM 7.5 SP9 / Business Center 16.3.3
VIM 7.5 SP6 / Business Center 16
/OTX/PS35 VIM Manage PO Exceptions
Update 2
/OTX/PS37 VIM Advanced Coding VIM 7.5 SP9 / Business Center 16.3.3
Business Center VIM - OData VIM 7.5 SP6 / Business Center 16
/OTX/PS80
Services Update 2
Business Center VIM - Modules / VIM 7.5 SP6 / Business Center 16
/OTX/PS81
Rules Update 2
Business Center VIM - Fiori UI VIM 7.5 SP6 / Business Center 16
/OTX/PS82
Handler Update 2
Business Center VIM - Coding/Apps
/OTX/PS83 VIM 7.5 SP9 / Business Center 16.3.3
UI Handler
/OTX/PS302 VIM: Coding Proposals VIM 7.6/20.4
VIM Vendor Invoices Report Fiori
/OTX/PS311 VIM 7.6/20.4
app
Classic mode: Integrate smart
/OTX/PS39 VIM 7.6/20.4
coding for Non PO invoice

14.3.8 Assigning collections to translators

In this step, you assign the collections to all translators.
To assign collections to translators:
1. On the Translation Administration screen, on the Translators tab, click Assign

Collections.
2. In the Collections dialog box, enter the graph name and click the corresponding
Select button. The number of collections selected is displayed in the Result
field.
Click .
3. Click Select next to Graph to select the graph.
4. Click Select next to Translators to select all translators.
5. Click Save.

6. In the Choose Translators dialog box, click Choose next to Targ. Langs.
7. In the Choose Target Language dialog box, click each language or click Choose
Target Language to choose required languages. Then click .
8. In the Choose Translators dialog box, save your settings.
9. In the Assignment of Collections dialog box, click Assign for Number of

languages involved, Number of collections involved and Number of
translators involved.

14.3.9 Updating the translation hierarchy

This function copies the current application hierarchy to the translation hierarchy in
the translation environment. This action is optional in SAP S/4HANA versions prior
to EHP5.
To update the translation hierarchy:
1. On the Environment menu, click Create Package-Domain Assignment.
2. Schedule the job.

You can monitor the job’s progress in the SM37 transaction.
3. Wait until the job is completed before continuing with any further task.
14.3.10 Creating the object lists

You can create object lists for classic VIM, for the KPI package, and for VIM Fiori
apps.
14.3.10.1 Object list for classic VIM

You can create an object list in the following ways:
• For the entire system

• For specific collections
• For transport requests from a specific time interval (ABAP development only)
• For a piece list (ABAP development only)
• For transport objects (recommended to save translation effort)
The following steps describe creating object lists for specific collections. For creating
object lists for other options, see the SAP help.
To create an object list for specific collections:
1. On the Translation Administration screen, on the Evaluation tab, click Object

Lists.

2. In the Object Lists dialog box, click to create a new object list.
3. In the Description dialog box, enter the description for the object list and save.

4. In the Parameters dialog box, select the Renew Domain Assignment check box.
5. In the Global area, click No Entries next to Object Types.

In the Object Type Selection (Groups) dialog box, select the required object
types. For the list of object types, see “Defining object types for translation”
on page 243.
6. In the Global area, click No Entries next to Collections.

In the Collections dialog box click Select next to Graph.
7. In the Select Graph dialog box, select the name of the graph that you have
created in “Maintaining the translation graph” on page 242 and click Execute.
8. Back in the Collections dialog box, save your settings.
9. For VIM 7.0 and higher, you must exclude the objects of KPI from the list of
collections. Perform the following steps:

a. In the Collections dialog box, in the Fine Tune Result area, click List.
b. Deselect the line of project /OPT/VIM_KPI as shown in the screenshot.

c. Confirm to return to the Collections dialog box. Click Continue.
In the Parameters dialog box, in the Global area, the number of object types
selected (see “Defining object types for translation” on page 243) and collections
selected shows up in the respective fields.
10. In the Parameters dialog box, save your settings.

11. In the Object Lists dialog box, select the new object list and click Activate.
12. In the next screen, click the Immediately button to activate the object list
immediately, or schedule the activating job for a later time.
Click .
13. In the next two screens, select the Output Device and the Background Server.
You can choose the default values.
14. Wait until the job is completed before moving to the step of creating the
evaluation run (see “Creating an evaluation run” on page 267). You can
monitor the background job using the SM37 transaction.
Object lists based on transports or piece lists
To create an object list based on transports, enter the transports with asterisks
in the next two columns. Or enter the piece list with asterisks in the next two
columns.

You can create the piece list using the SE01 transaction. Include all transports
of objects that are to be translated into the piece list.
If you have a separate translation system, contact OpenText Customer Support

to get the transport request that contains all objects to be translated.
14.3.10.2 Object list for KPI package

The KPI (Key Performance Indicator) component contains thousands of objects.
Most of them are not relevant for translation. Make sure that you really deploy this
component in production before translating it. For the KPI component, you must
create a separate object list.
The object list contains a list of OTR concepts and some customization tables.
Concepts that must be translated are listed in “KPI package object list” on page 260:
Table 14-3: KPI package object list
Alias Concept English

/OPT/VIM_KPI/ E1256765598886F1B1970050561
All
DROPDOWN_TEXT_ALL 89E13
/OPT/VIM_KPI/
E10C48DEC82C3FF1859A0050
TRAY_EXC_SUMMARY_HEA All Exception Classes
56893F2C
DER
/OPT/VIM_KPI/
E10C4A7C975250F1859A00505
CHART_EXC_SUM_NO_TIM All Exception Classes
6893F2C
E_HEADER
/OPT/VIM_KPI/
E10A11290CF3EBF1916200505
TRAY_VOL_SUMMARY_HE All Invoices per Channel
6189E13
ADER
/OPT/VIM_KPI/
E127D0E2018046F1B197005056
COPYRIGHT_INFORMATIO All rights reserved.
189E13
N
/OPT/VIM_KPI/
E10ED6B869FA58F1859A00505
CATEGORY_AMOUNT_CLA Amount Classes
6893F2C
SSES
/OPT/VIM_KPI/ E127E5D45E6564F1B197005056
Apply Filter
FILTER_SUBMIT_BUTTON 189E13
/OPT/VIM_KPI/
E10C5D3CFFFD00F1859A0050 Approval Time
CHART_TIME_SUM_APPR_T
56893F2C Distribution
IME_HEADER
/OPT/VIM_KPI/
E10A1D3C63E0A1F1916200505
FILTER_CHANNEL_HEADE Channel
6189E13
R


/OPT/VIM_KPI/
E10A1D5B05AA4FF191620050
FILTER_CHANNEL_HEADE Channel ID
56189E13
R_TOOLTIP
/OPT/VIM_KPI/
E10A1CEC907F77F1916200505
FILTER_CC_GROUP_HEADE Company Code Group
6189E13
R_TOOLTIP
/OPT/VIM_KPI/
E10A1CB6A617D1F1916200505
FILTER_CC_GROUP_HEADE Company Code Group
6189E13
R
/OPT/VIM_KPI/
E127D0E2018046F1B197005056 Copyright © 1995 - 2012
COPYRIGHT_INFORMATIO
189E13 by OpenText Corporation.
N
/OPT/VIM_KPI/
E10C6734D97156F1859A00505
CHART_EXC_PONPO_NO_TI Critical Exception Class
6893F2C
ME_HEADER
Depending on user rights,
/OPT/VIM_KPI/
E121E1FA07518EF1B19700505 not all company code
MESSAGE_TEXT_INFO_AUT
6189E13 groups might be available
HORIZATION
for selection.
/OPT/VIM_KPI/
E1113E18A8B377F1859A00505
CHART_TIME_PONPO_APP Delayed Approval
6893F2C
R_TIME_HEADER
/OPT/VIM_KPI/
E1113EC4C76713F1859A00505
CHART_TIME_VCL_APPR_TI Delayed Approval
6893F2C
ME_HEADER
/OPT/VIM_KPI/
E1113EE7088CDBF1859A00505
CHART_TIME_ACL_APPR_TI Delayed Approval
6893F2C
ME_HEADER
/OPT/VIM_KPI/
E1113EA224808FF1859A00505
CHART_TIME_VCL_PROC_T Delayed Processing
6893F2C
IME_HEADER
/OPT/VIM_KPI/
E1113D9EFD4C97F1859A0050
CHART_TIME_PONPO_PRO Delayed Processing
56893F2C
C_TIME_HEADER
/OPT/VIM_KPI/
E1113E624A50AFF1859A00505
CHART_TIME_ACL_PROC_T Delayed Processing
6893F2C
IME_HEADER
/OPT/VIM_KPI/
E10B13127BEF02F1859A00505
SETTINGS_CATEGORY_LAB Display Category
6893F2C
EL
/OPT/VIM_KPI/ E127E5F9F5375CF1B197005056
Display Filter
FILTER_HEADER 189E13


/OPT/VIM_KPI/
E10C4A3520E0E9F1859A00505
CHART_EXC_SUM_EFR_TIM Exception Free Rate
6893F2C
E_HEADER
/OPT/VIM_KPI/
E10C6AF89CE221F1859A00505 Exception Free Rate per
CHART_EXC_ACL_EFR_TIM
6893F2C Amount Class
E_HEADER
/OPT/VIM_KPI/
E10C677AB1062BF1859A00505 Exception Free Rate per
CHART_EXC_PONPO_EFR_T
6893F2C PO/Non-PO Invoices
IME_HEADER
/OPT/VIM_KPI/
E10C6B8A6F4655F1859A00505 Exception Free Rate per
CHART_EXC_VCL_EFR_TIM
6893F2C Vendor Group
E_HEADER
/OPT/VIM_KPI/ E10A1E4187ED48F1916200505
Exceptions
TAB_KPI_EXC_HEADER 6189E13
/OPT/VIM_KPI/ E11F26ABBC00DFF1BCB80050
Export to Excel
LINK_DOWNLOAD_TEXT 56189E13
/OPT/VIM_KPI/
E10A1C7D38D3BDF191620050
FILTER_TIME_RANGE_FRO From
56189E13
M
/OPT/VIM_KPI/ E1141FE3C70F2AF1859A00505
Help
LINK_HELP_TEXT 6893F2C
/OPT/VIM_KPI/
E11F5A49835A75F1BCB800505
MESSAGE_HEADER_CHECK Incorrect Date Selection
6189E13
_FILTER_FAILURE
/OPT/VIM_KPI/ E11F266905A4C7F1BCB800505
Information
LINK_INFO_TEXT 6189E13
/OPT/VIM_KPI/
E10C3BAB8BF9EEF1859A0050 Invoice Amounts per
CHART_VOL_ACL_TA_TIME
56893F2C Amount Class
_HEADER
/OPT/VIM_KPI/
E10A124C45F781F19162005056 Invoice Amounts per
CHART_VOL_SUM_TA_TIM
189E13 Channel
E_HEADER
/OPT/VIM_KPI/
E10C3B30949061F1859A005056 Invoice Amounts per
CHART_VOL_VCL_TA_TIME
893F2C Vendor Groups
_HEADER
/OPT/VIM_KPI/
E10C3AB8365C63F1859A00505 Invoices per Amount
CHART_VOL_ACL_NO_TIM
6893F2C Class
E_HEADER
/OPT/VIM_KPI/
E10A12282A3DEBF1916200505
CHART_VOL_SUM_NO_TIM Invoices per Channel
6189E13
E_HEADER


/OPT/VIM_KPI/
E10C3B03A47FDAF1859A0050 Invoices per Vendor
CHART_VOL_VCL_NO_TIM
56893F2C Groups
E_HEADER
/OPT/VIM_KPI/
E10C6ABF87BDAFF1859A0050 Invoices with Critical
CHART_EXC_ACL_NO_TIME
56893F2C Exceptions
_HEADER
/OPT/VIM_KPI/
E10C6B64D6023AF1859A00505 Invoices with Critical
CHART_EXC_VCL_NO_TIME
6893F2C Exceptions
_HEADER
/OPT/VIM_KPI/ E11B45786C5538F19464005056
No.
CHART_VOL_NO_TIME_Y 189E13
/OPT/VIM_KPI/ E140411515162EF1B197005056
No. of Occurrences
CHART_EXC_NO_TIME_Y 189E13
/OPT/VIM_KPI/
E10A1FB6782B88F19162005056
CHART_LABEL_SERIES_NPO Non-PO Invoices
189E13
_INVOICES
/OPT/VIM_KPI/ E11B45786C5538F19464005056
of Invoices
CHART_VOL_NO_TIME_Y 189E13
/OPT/VIM_KPI/ E1201D6FFAA41FF1BCB80050
Percentage
CHART_LABEL_PROC_Y 56189E13
/OPT/VIM_KPI/
E11F5949EC77BBF1BCB800505
MESSAGE_TEXT_CHECK_FI Please select a valid date.
6189E13
LTER_FAILURE
/OPT/VIM_KPI/
E10A1F7529D4C5F1916200505
CHART_LABEL_SERIES_PO_I PO Invoices
6189E13
NVOICES
/OPT/VIM_KPI/
E10A12DFA18525F1916200505 PO/Non-PO Invoice
CHART_VOL_PONPO_TA_TI
6189E13 Amounts
ME_HEADER
/OPT/VIM_KPI/
E10A1290265B91F19162005056
CHART_VOL_PONPO_NO_T PO/Non-PO Invoices
189E13
IME_HEADER
/OPT/VIM_KPI/
E10ED71BA3BE59F1859A0050
CATEGORY_PONPO_INVOI PO/Non-PO Invoices
56893F2C
CES
/OPT/VIM_KPI/ E10A1E65789535F19162005056 Processing and Approval
TAB_KPI_TIME_HEADER 189E13 Time
/OPT/VIM_KPI/
E10B15E8B9AEE7F1859A00505 Processing and Approval
TRAY_TIME_SUMMARY_HE
6893F2C Time for All Invoices
ADER
/OPT/VIM_KPI/
E10C5CF46DD170F1859A0050 Processing Time
CHART_TIME_SUM_PROC_T
56893F2C Distribution
IME_HEADER


/OPT/VIM_KPI/ E114E82B9F68BBF1859A00505
SAP VIM KPI Dashboard
PRODUCT_HEADER 6893F2C
/OPT/VIM_KPI/
E11F5949EC77BBF1BCB800505 The start date you selected
MESSAGE_TEXT_CHECK_FI
6189E13 occurs after the end date.
LTER_FAILURE
/OPT/VIM_KPI/
E10A1C4A8E863DF1916200505
FILTER_TIME_RANGE_HEA Processing End
6189E13
DER
/OPT/VIM_KPI/
E10A1D8EE5EB8DF191620050
FILTER_TIME_RANGE_HEA Processing End
56189E13
DER_TOOLTIP
/OPT/VIM_KPI/ E10A1C9483D416F1916200505
To
FILTER_TIME_RANGE_TO 6189E13
/OPT/VIM_KPI/
E119D4F65FDC5FF1946400505
CHART_LABEL_SERIES_UN Unclassified Invoices
6189E13
CL_INVOICES
/OPT/VIM_KPI/
E10ED6EC300183F1859A00505
CATEGORY_VENDOR_CLAS Vendor Groups
6893F2C
SES
/OPT/VIM_KPI/ E10A1E0FDC95FDF191620050
Volume and Amounts
TAB_KPI_VOL_HEADER 56189E13
/OPT/VIM_KPI/ E11B462E3920F8F19464005056
Year
CHART_TIME_X 189E13
Concerning customizing tables, include the whole content of the following tables in
the object list of the KPI component:
Customizing tables
• /OPT/KAGR_C_AMNT
• /OPT/KAGR_C_CCGT
• /OPT/KAGR_C_DOWT
• /OPT/KAGR_C_EXCT
• /OPT/KAGR_C_TMGT
• /OPT/KAGR_C_VNDT
One way to create the object list is to create a transport that includes all relevant
concepts and table entries. Perform the following steps:
To create an object list for the KPI package:
1. Include all concepts listed in “KPI package object list” on page 260 to a
transport.

To include a concept into a transport, do the following:
a. Call the SOTR_EDIT transaction.

b. Enter alias /OPT/VIM_KPI*.
c. Enter some concept, for example E10ED6B869FA58F1859A005056893F2C, in
the Concept field. Click Display.
d. In the next screen, click the Transport button. Include the concept to a new
transport or insert it to an existing transport.
e. Do the same for all concepts listed in “KPI package object list” on page 260.
2. Include the content (all entries of tables) of all tables listed in Customizing
tables on page 264 into the same transport.
3. To create the object list specific for KPI, follow the steps described in “Creating
the object lists” on page 255. In Step 5 on page 257, in the Global area, click No
Entries next to Transports.
4. In the Transports/Piece List dialog box, enter the created transports.

Save your settings.
5. Activate the new object list as described in Step 11 on page 259.
You can use the new object list created specific for KPI along with the object list for
the whole VIM product (excluding KPI) for creating an evaluation run.
14.3.10.3 Object list for VIM Fiori apps

VIM Fiori apps like Approve Invoices, Approve Invoices (bulk mode), My
Approved Invoices, Resolve Invoice Exceptions, Confirm Quantity and Price, Enter
Cost Assignment Simple, and Enter Cost Assignment Advanced have been
delivered together with classic VIM.
To create an object list for VIM Fiori apps, follow the same steps as in “Object list for
classic VIM” on page 255. In Step 6 on page 257, select the following collections:
Collection Description From VIM version / Business

Center version
/OTX/PF00 Business Center Cross Comp VIM 7.5 SP4 / Business Center 16
/OTX/PF01 Business Center Inbound VIM 7.5 SP4 / Business Center 16
/OTX/PF02 Business Center Process VIM 7.5 SP4 / Business Center 16
/OTX/PF03 Business Center Workplace VIM 7.5 SP4 / Business Center 16
/OTX/PF04 Business Center Process Conf VIM 7.5 SP4 / Business Center 16
/OTX/PF62 Business Center Fiori Business Center 16
Configuration
/OTX/PS03 Business Center Solution - VIM VIM 7.5 SP4 / Business Center 16
Foundation

Collection Description From VIM version / Business

Center version
/OTX/PS08 Business Center VIM - Basic VIM 7.5 SP8 / Business Center
16.3.2
/OTX/PS30 VIM Basic VIM 7.5 SP4 / Business Center 16
/OTX/PS301 Business Center VIM - Coding UI VIM 7.5 SP9 / Business Center
Handler 16.3.3
/OTX/PS31 VIM Fiori Integration VIM 7.5 SP4 / Business Center 16
/OTX/PS32 VIM Simple Coding VIM 7.5 SP4 / Business Center 16
/OTX/PS33 VIM OData service VIM 7.5 SP4 / Business Center 16
/OTX/PS3303 Fiori Apps and Workplace VIM 7.5 SP9 / Business Center
16.3.3
/OTX/PS35 VIM Manage PO Exceptions VIM 7.5 SP6 / Business Center 16
Update 2
/OTX/PS37 VIM Advanced Coding VIM 7.5 SP9 / Business Center
16.3.3
/OTX/PS80 Business Center VIM - OData VIM 7.5 SP6 / Business Center 16
Services Update 2
/OTX/PS81 Business Center VIM - Modules / VIM 7.5 SP6 / Business Center 16
Rules Update 2
/OTX/PS82 Business Center VIM - Fiori UI VIM 7.5 SP6 / Business Center 16
Handler Update 2
/OTX/PS83 Business Center VIM - Coding/ VIM 7.5 SP9 / Business Center
Apps UI Handler 16.3.3
/OTX/PS302 VIM: Coding Proposals VIM 7.6/20.4
VIM Vendor Invoices Report Fiori
/OTX/PS311 VIM 7.6/20.4
app
Classic mode: Integrate smart
/OTX/PS39 VIM 7.6/20.4
coding for Non PO invoice
As object types, take all object types listed in “Defining object types for translation”
on page 243 and any other required object types for your own needs.

14.3.11 Creating an evaluation run

Evaluations provide global worklists and statistics for all target languages defined in
the system, and for all of the objects contained in the object list (or object lists) used
for the evaluation.
If several object lists are available for your product, you have the choice to create
either one global evaluation run including all object lists or several evaluation runs,
each for one object list.
You can also create an evaluation run for all supported languages, or one evaluation
run for each language.
To define parameters for an evaluation run:
1. On the Translation Administration screen, on the Evaluations tab, click

Evaluations.
In the Evaluations dialog box, you see a list of all existing evaluations with the
following parameters:
• Run number
• Job status. Possible values:
R - Released
M - Main Run

X - Generation Complete
D - Deleted
A - Canceled
E - Error
• Description of the evaluation

• The last agent who changed the evaluation
• The last changed date
• The agent who created the evaluation
• The creation date
• Job Name
• Job ID
2. Click Create.
3. Enter a description of the evaluation in the Description field.
4. Save your description.
5. Enter the number of the global work lists that you want to create or update.
6. If you want translations to be distributed automatically during the evaluation

run, select the Distribution check box.
7. If you want initial statistics and/or current statistics to be generated, select the
Initial Statistics and/or Statistics check boxes.
8. If you want to delete the existing global work list, select the Deletion check box.
9. If you want to update the domain assignment of the evaluated objects, select the
Renew Domain Assignment check box.
10. If you do not want the translation status of objects to be calculated, select the No
Status Calculation check box.
11. In the Object Selection area, click No Entries next to Object Lists.
12. In the Object Lists dialog box, select the object list(s) to be included in the
evaluation run.
You can create separate evaluation runs for each object list created in “Creating
the object lists” on page 255. In this case, select only the relevant object list.
Alternatively, you can create an global evaluation run for all object lists. In this
case, select all created object lists.
13. Click Execute. In the Parameters dialog box, the number of object lists that
you selected is displayed next to the Object Lists field.

Continue with “To define parameters for an evaluation run using the
Parameters dialog box:“ on page 269
To define parameters for an evaluation run using the Parameters dialog box:
1. In the Parameters dialog box, in the Object Selection area, click No Entries next
to Object Types.
2. In the Object Type Selection (Groups) dialog box, select the object types to be
evaluated.
If you want to evaluate all object types, double-click the Object Type Selection
node. If you only want to evaluate specific object groups, double-click the object
groups to be evaluated.
The object types selected at this point do not override the object types defined
for translation into a particular target language.
Example: If you select object groups S1 to S7 for the evaluation run, but have only
defined object groups S1 to S4 for translation into French, the global work list for French
will only evaluate object groups S1 to S4.

3. Click Execute.
In the Parameters dialog box, the number of object types you selected is
displayed next to the Object Types field.
4. In the Object Selection area, click No Entries next to Graphs.
5. In the Select Graph dialog box, select the translation graph or graphs to be
included in the evaluation.
Save your selection.
In the Parameters dialog box, the number of translation graphs you selected is
displayed next to the Graphs field.
6. In the Object Selection area, click No Entries next to Target Languages.
7. In the Target Language dialog box, select the target languages to be included in
the evaluation run. If you want to select all target languages, double-click the
Target Language node.
8. Save your selection.

In the Parameters dialog box, the number of target languages you selected is
displayed next to the Target Languages field.

In the Evaluations dialog box, the evaluation run has activation status P.
10. Continue with “To run the evaluation using background jobs:“ on page 271

To run the evaluation using background jobs:
1. In the Evaluations dialog box, click Activate.

The evaluation run can have one of the following activation statuses:
R
Evaluation is released.
X
Evaluation has finished.
E
An error has occurred.
M
Evaluation is running.
2. Release the background job with the SM37 transaction.
3. Check for a job whose job name starts with EVALUATION_. Release this job.
After completion of this main evaluation job, check for any scheduled
evaluation jobs for each language. Release all those jobs and wait until
completion of all jobs.
4. After completion of jobs, check the status on the Translation Administration

screen, in the Evaluations tab.
Click Current Run.

The status should be X for all languages.
14.4 Translation
This section describes the actual translation steps. Perform them after all previous
steps are completed. For more information, see the previous sections in “Translating
VIM“ on page 237.
14.4.1 Global work list

You translate the global work list using the SE63 transaction.
To translate the global work list:
1. Run the SE63 transaction.

2. On the menu, click Utilities > Settings to set the source and target languages.
Important
You must perform this when you run SE63 for the first time.

14.4. Translation
4. On the menu, click Worklist > Standard to load the objects for translation of the
global work list in a target language.
5. Enter the Worklist Number. Make sure the source and target languages are
correct. If not, enter correct languages.

Select the Reset Worklist / Reservation check box if the same user is doing
translation in multiple languages.
Click to continue.
6. On the Get Worklist screen, Worklist Pool tab, enter a number (for example
1000) in the Number per Object Type field.
Select the New and Modified check boxes.
Optionally you can select the Translated check box if you want to see all
translated text in your work list.
Click Load Objects.

14.4. Translation
7. In the Worklist: Object List ..., you see numbers with red, yellow and green
background color. See the following list for their meaning:
Red color
Means the number of untranslated objects (strings).
Yellow color
Means translated, but not added to the SAP proposal pool.
Green color
Means translated and confirmed.
Both new and modified strings must be added to the SAP proposal pool.
8. Where you see numbers with red or yellow background color, click the plus
sign + (folder icon) to open the node. Continue until a line without a folder icon
is shown.

9. Double click the object name.

The translation editor is loaded with all text strings for that object type.
10. Enter a new translation into the field (next line from the source text) or modify
the existing string if it is not correct.
When an object has been already translated and is available in the SAP proposal
pool (SAP Pool), you see the translation below the editable line. Double-click
the translation. It is inserted into the field.
If the complete translation text does not fit into the field, use abbreviated text.
11. After entering/correcting all strings, save your settings.

14.4. Translation
The tool icon in the field with yellow or red background indicates that the
translation is not in the SAP proposal pool and should be reviewed.
To enter the translation into the SAP proposal pool, double-click the tool icon.
12. In the Display/Edit Proposals screen, click Standard under the application
domain, for example FI - Financial Accounting.
13. In the Select status dialog box, double-click Standard Quality Status.
Click .
Now the translation is in the SAP proposal pool. The object ID is shown in
green background color.
14. For a few objects, SAP might not be able to load all strings in an object into the
translation editor. In this case, SAP shows a dialog box with a list of string
groupings. SAP combines sets of strings into different groups. See the following
example screenshot:
15. Double-click a line to load the strings related to that group into the translation
editor.
Repeat the process for all groups in the dialog box one by one.

14.4.1.1 Translating dialog text

In the Worklist (see Step 7 on page 275), dialog texts are grouped in the folder <A5>
User Interface Texts -> <DT> Dialog Texts.
To translate dialog text:
1. To translate DT, double-click the text.
2. Click the Full screen editor icon (highlighted in the screenshot).
3. Replace the original text (in EN) by the translated text.
4. Save the translated text.
5. Click .
6. To save the activate version, click Activate .
To translate a single DT outside of the worklist:
1. Call the SE63 transaction.
2. Enter DT in the command line.
3. Enter the text into the text field.
4. Perform the steps as described in “To translate dialog text:“ on page 278

14.4. Translation
14.4.2 VIM IMG (/OPT/SPRO transaction)

In this step, you translate the VIM IMG (/OPT/SPRO transaction). This is optional
because this user interface is only used by system configurators.
To translate the VIM IMG:
1. Run the /n/SIMGH transaction.
2. In the Edit IMG Structure screen, press F4 in the IMG structure field.
3. In the Find Structure dialog box, enter /opt/* in the Package field.
Click .
4. In the Explanatory text dialog box, double-click Central Reporting.
5. In the Edit IMG Structure screen, click Display .

6. In the Display IMG screen, click Expand all .
7. Click a node and, on the Utilities menu, click Translation.
8. In the Translation dialog box, select EN as Source Language and the translation
language as Target Language. Click .
9. Enter the translation strings and save. Add the translated string to the SAP
proposal pool.
Click .
10. Repeat Step 7 to Step 9 for all nodes.
11. After translating all nodes, click .
12. Repeat Step 2 to Step 11 for all entries displayed in the Explanatory text dialog
box.

14.4. Translation
14.4.3 VIM workflow tasks

VIM contains some workflow tasks. In this step, you translate these tasks. To
translate the workflow task text, you use the WI Text Update Utility. Translate all
VIM workflow tasks. The following list shows all VIM workflow tasks:
TS00275253
Approve Invoice
TS00275260
Non-PO Invoice Dashboard
TS00275262
PO Parked Invoice Dashboard
TS00275265
PO Invoice Dashboard (Line Level) RO, HU
TS00275267
PO Invoice Dashboard (Header WF)
TS00275278
DP Document Dashboard
TS00275283
Reference requested
To translate VIM workflow tasks:
1. Run the /n/PTGWFI/M_LANG transaction.
2. On the OpenText Multi Language Workitem Text Maintenance Utility screen,

enter the task ID and press ENTER.
3. Click next to the language to modify existing text.
4. To enter text for a new language, select the language from the Language list.

5. Copy the EN text and paste it into the Text field. Replace the EN text with the
target language text.
Note: Do not change the text between & and &.
6. Enter the target language text in the Task Text field.

7. Click Update to save the text. The system prompts for a transport request. Enter
the transport request.
To translate the description of the task:

1. Run the SE63 transaction. On the Translation menu, point to ABAP Objects
and click Transport Object.
2. In the field Transport entry of object, enter the following: R3TR PDTS <task
number>; for the task TS00275265, enter task number 275265.
3. On the next screen, expand the node <WFLW> Workflow Texts, and double-
click on the entry shown below.
4. On the next screen, click the Copy icon to copy the English text. In the
Editor, replace the English text with the translation.
5. Save and activate the translation.
14.4.4 VIM Global Object Services text

In this step, you translate the Global Object Services (GOS) customization that is
used in VIM. You translate VIM specific GOS entries using the SM30 transaction.
To translate GOS text:

1. Run transaction SM30.
2. In the Table/View field, enter SGOSATTR and click Maintain.
3. If an Information dialog box opens, click to close it.

14.4. Translation
4. In the SGOS: Attribute of Generic Services view, find the records for WF_ZOPT/
VIM and ZOPT_SERVC.
5. Select both records and, on the menu, click Goto > Translation.
6. In the Choose languages dialog box, select the language.

Click .
7. Enter the text in the target language in the Description and Quick info fields.
Click .
8. Save your settings. Enter a transport request when prompted to do so.
14.4.5 VIM standard texts

VIM uses some standard texts for various aspects including sending emails and so
on. You do not directly translate standard texts but you create them using the SO10
transaction like new text. Create standard texts for the following VIM texts in all
required languages:
• /OPT/VIM_DP_SRM_PRICE_HEADER
• /OPT/VIM_DP_SRM_QTY_FOOTER
• /OPT/VIM_DP_SRM_QTY_HEADER
• /OPT/VIM_DP_SRM_QTY_URL_HEAD
• /OPT/VIM_DP_HEADER_SRM_QTY
To create VIM standard texts:
1. Run the SO10 transaction.

2. On the Standard Text: Request screen, enter the Text Name, ST in Text ID, and
EN in Language.
Click Display.
3. Copy the EN text to Notepad or to a Word document. This is the text that needs
to be translated in the new language.
4. Click .
5. Enter the targeted language in Language, and click Create.
6. Enter the translated text in the same format as the EN text and save.
14.5 Creating language packages or language

transports
You can pack translations either in a language package or in transport requests. To
import transport requests, you can use the STML transaction.

14.5. Creating language packages or language transports
14.5.1 Creating language packages

To pack translations in a language package, use the SMLT_EX transaction. For more
information, see the SAP documentation.
14.5.2 Creating language transports

Create transports for translations that are done using global work list, VIM IMG,
and VIM standard text.
To create transports for global work list and VIM IMG:
1. Run the SLXT transaction.
2. On the menu, click Program > Execute in Background. Enter information for
the following fields.
• Target Language

• Description: Any meaningful description

• Target System
• Processing Date: Date range from the day the translator started the work to
the end of the translation work
• Object Processor: User ID of the translator
3. If the transport is created for specific object types, enter the Object Type. Some
object types can be excluded from the transport.
Example 14-1: Exclude object types

If the table entries should go into a BC set instead of a regular transport,
exclude object types TADC and TADG from the transport.
4. Schedule the job.
To create transports for standard texts:
1. Run the SE38 transaction.
2. In Program, enter RSTXTRAN and click .

14.5. Creating language packages or language transports
3. Enter the transport request task in the Name of correction field.

Enter all standard texts in the Text key – name field.
Enter the target language in the Text key - language field.
Click .
4. Press ENTER.
5. On the Provisional List of Texts to be Transferred screen, press ENTER.
6. On the Final List of Texts for Transfer to Correction screen, click Trsfr texts to
corr.
7. In the Transfer texts to correction dialog box, click Yes.

A message like the following is displayed:

14.6 Importing languages and activating translation

14.6.1 Importing language packages with the SMLT
transaction
See the SAP help for information how to import a language package into a system.
You can import language packages using the SMLT transaction.
SAP recommends that you import the language package first in client 000 to keep
this client up-to-date. Then use the integrated tool to perform the following steps:
To copy all translations from client 000 to the target client:
1. Sign in to the target client.
2. Run the SMLT transaction.
3. Select the target language.
4. On the Language menu, click Special Actions > Client Maintenance.
The integrated tool ensures that only new translations are copied. Supplementary
texts are replaced, but custom translation is not overwritten. For more information,
see SAP Note 43853 and SAP Note 1156507.
Notes
• With the client copy, only missing translation is copied from client 000.
Existing translations are not replaced by the new or changed translations.
• There is another option to insert missing translations or replace existing

translations by calling the RSREFILL report, with the following options:
Insert missing translation and Replace existing translation.

14.7. Approval Portal translation
14.6.2 Importing the transport request with the STMS

transaction
You can import the Transport Request of the translation into a system using the
standard SAP STMS transaction.
14.6.3 Activating imported translations

After doing translation or importing translation, perform the following steps:
To refresh runtime translation:
1. Run the RSLANG20 program with language XX.
2. Then run the following transactions:
• /$CUA
• /$DYN
14.6.4 Troubleshooting
After importing all required language packages, Fiori Task Apps might still be not
displayed in the login language. In this case, check the following:
• The language of the browser must be the login language.

• The field language in the Logon & Security tab must be empty for the RFC
connection (transaction SM59) from the Fiori frontend system to the SAP backend
system.
14.7 Approval Portal translation

Changing language resources and adding additional languages in the Approval
Portal requires some configuration, which is described in this section.
14.7.1 Changing language resources

All the texts on the end user screens are changeable for all languages. If there is a
need to change the text to suit your needs, perform the following steps:
To change language resources:
1. Navigate to the <Approval_Portal_installdir>/invoiceCfg and open up

the properties file that you want to edit, for example: Lang_DE.properties
2. Find the text that you want to change.
3. Change the text and save it.

When changing the text in an Editor without localization tool, use a Java
command to convert non-ASCII characters to Unicode representative format
(\u<XXXX>).
The Java command for converting is native2ascii.
Syntax: native2ascii [ inputfile ] [ outputfile ] -encoding encoding_name
For encoding-name, see http://docs.oracle.com/javase/8/docs/technotes/guides/
intl/encoding.doc.html.
Example: Converted German (Lang_DE.properties):

nonpo.invoice.hdr.due.date=F\u00e4lligkeitsdatum for the German word
“Fälligkeitsdatum”.
Java compiler and other Java tools can only process files which contain Latin-1
and/or Unicode-encoded characters (\u<XXXX> notation).
Example command: Java native2ascii -encoding UTF-8 "ori_utf-8-Lang_
DE.properties" Lang_DE.properties
Tip: You can also use any editor that can save as “Unicode Enabled”, for
example https://marketplace.eclipse.org/content/properties-editor.
4. Reinitialize the application, see Section 7.8.1.5 “Administration” in OpenText

Vendor Invoice Management for SAP Solutions - Administration Guide (VIM-AGD).
If you need additional help, contact OpenText Customer Support.
14.7.2 Configuring additional languages

The Approval Portal supports the following predefined languages:
• Czech (CZ)
• German (DE)
• English (EN)
• Spanish (ES)
• French (FR)
• Hungarian (HU)
• Italian (IT)
• Japanese (JA)
• Dutch (NL)
• Polish (PL)
• Portuguese (PT)
• Romanian (RO)
• Russian (RU)

• Slowakian (SK)
Note: The Slowakian translation does not include KPI Dashboard and
Central Reporting.
• Turkish (TR)
• Chinese (ZH)
This section describes the configuration to add another language than the
predefined. Therefore, you have to perform the following actions:
• Modify the Lang_Support.properties file

• Add a new Lang_<XX>.properties file
• Modify CSS styles
• Modify JavaScript for the Calendar popup
• Add the new language to the constant LANGUAGE
• Restart the Approval Portal application
To modify the Lang_Support.properties file:
1. Navigate to the installation directory, for example \usr\sap\<instance name>

\SYS\global\opentext\invoiceCfg.
2. Open the Lang_Support.properties file.
3. Add a key-value entry of the new language.
Example: If you want to add Swedish language, add the entry V=SV.
Note: This entry is a SAP language key pair. Check the SAP help for a list
of language key pairs.
4. Save and close the Lang_Support.properties file.
To add a new Lang_<XX>.properties file
1. Navigate to the installation directory.

2. Copy the existing Lang_EN.properties file and rename it to

Lang_<XX>.properties, where <XX> is the two-letter language code.
Example: For Swedish, the new file is named Lang_SV.properties.
3. Store the new file in the installation directory.
4. Open the new Lang_<XX>.properties file and translate the English strings into
the other language.
Convert non-ASCII characters to Unicode representative format, see Step 3
on page 289 in “Changing language resources” on page 289.
5. Save and close the Lang_<XX>.properties file.
For Approval Portal 7.5 and higher, there is no need to have a separate CSS
stylesheet for every language, like it was the case in prior versions.
To modify CSS styles:
1. Navigate to the application deployment folder, for example \usr\sap

\<instance name>\<JC>\j2ee\cluster\server0\apps\com.opentext.vim.
portal\VimPortalWeb\servlet_jsp\vimportal\root\styles; where <JC> is
the system number.
For NetWeaver 7.3 and 7.4 Portal, the folder is the following: \usr\sap
\<instance name>\J<System number>\j2ee\cluster\apps\opentext.com\
IM_APPROVAL_PORTAL7_0\servlet_jsp\vimportal\root\styles.
2. To modify any styles, perform the changes in the global CSS file.
• If the Approval Portal is deployed in SAP NetWeaver Application Server

Java, modify StyleOT.css .
• If the Approval Portal is deployed in SAP NetWeaver Portal, modify
StyleOTNWP.css.
Note: These changes will reflect in all languages.
3. Save your changes.
You must include calendar popup strings in the new language to the
localization.js JavaScript file.
To modify JavaScript for the Calendar popup:
1. Download the ExtJS 4.2 package from Sencha (http://www.sencha.com/

products/extjs) and extract the archive to a local folder.
2. Navigate to the folder locale and open the specific file ext-lang-<xx>.js,
where <xx> is the two-letter language code.
3. Copy the coding parts for the override objects Ext.Date, Ext.picker.Date and
Ext.picker.Month (if existing).

4. Navigate to the application deployment folder, for example \usr\sap

\<instance name>\<JC>\j2ee\cluster\server0\apps\com.opentext.vim.
portal\VimPortalWeb\servlet_jsp\vimportal\root\script; where <JC> is
the system number.
For NetWeaver 7.3 and 7.4 Portal, the folder is the following: \usr\sap
\<instance name>\J<System number>\j2ee\cluster\apps\opentext.com\
IM_APPROVAL_PORTAL7_0\servlet_jsp\vimportal\root\script
5. Open the localization.js file.
6. Insert an else if clause for the new language and paste the specific coding
from the ExtJS locale file.
Note: If the locale file is not existing for the new language, copy the
default coding parts for English language and translate the text into the
new language.
7. For Swedish, as an example, copy the coding for Ext.Date and Ext.picker.
Date from file ext-lang-sv_SE.js into the new else if clause checking the
parameter langId==’SV’.
See Example 14-2, “Adapting the localization.js file for Swedish” for details.
Example 14-2: Adapting the localization.js file for Swedish
else if(langId == 'SV') {

if (Ext.Date) {
Ext.Date.monthNames = ["januari", "februari", "mars", "april",
"maj",
"juni", "juli", "augusti", "september", "oktober", "november",
"december"];
Ext.Date.dayNames = ["söndag", "måndag", "tisdag", "onsdag",
"torsdag", "fredag", "lördag"];
}
Ext.define("Ext.locale.sv_SE.picker.Date", {
override: "Ext.picker.Date",
todayText: "Idag",
minText: "Detta datum inträffar före det tidigast tillåtna",
maxText: "Detta datum inträffar efter det senast tillåtna",
disabledDaysText: "",
disabledDatesText: "",
nextText: 'Nästa månad (Ctrl + högerpil)',
prevText: 'Föregående månad (Ctrl + vänsterpil)',
monthYearText: 'Välj en månad (Ctrl + uppåtpil/neråtpil för att
ändra årtal)',
todayTip: "{0} (mellanslag)",
format: "Y-m-d",
startDay: 1
});
}
…
8. Save and close the localization.js file.

To add the new language to the constant LANGUAGE:
1. Run the SM30 transaction for table /PTGWFI/Z_CONST.
2. In Product Code IAP, in the Constant LANGUAGE, add the new language to the
Constant Value as a comma-separated single character.
Note: If you do not add the new language here, it will not appear at the
user's preferences.
3. Save your changes.
To restart the Approval Portal application (NetWeaver 6.0 or 7.0):
For a description for NetWeaver 7.3 and 7.4, see “To restart the Approval Portal
application (NetWeaver 7.3 and 7.4):“ on page 295.
To include the new language into the application, you must stop and start the
application from Visual Admin.
1. In Visual Admin, navigate to Instance > Server > Services > Deploy.
2. Expand servlet_jsp.
3. Select the Approval Portal application.
4. Click Stop Application at the right of the window.
5. When the application is stopped, select it again and click Start Application.
6. Click OK to confirm.

14.8. Supplementary language
Important
To make the language change effective, the end user must clear the
browser cache.
To restart the Approval Portal application (NetWeaver 7.3 and 7.4):
1. Log in to SAP NetWeaver Administration.
2. Navigate to Operations > Systems, and then click Start & Stop.
3. Click the Java Applications tab and mark the Approval Portal application.
4. Click Restart to restart the application.
Important
To make the language change effective, the end user must clear the
browser cache.
14.8 Supplementary language

VIM is developed in English. Its user interface and - to a lower extent - the
administration interface are translated into many languages. If you want to work in
languages that are not supported by VIM, use the tools provided for this case, as
described in this section.
If you use these tools properly, you can obtain a state of your screens where only
two languages are used, the sign-in language and English. If you do not use the
tools, you get screens with texts in the sign-in language, English, and German, as
well as empty texts and question marks as shown in the following example.

Example 14-3: Non-VIM language (Swedish) without language

supplementation and default secondary language
14.8.1 SAP secondary language

First of all, set the secondary language of your SAP system to English. The
secondary language is used by SAP to supplement ABAP text elements, screen text,
and GUI status when the text is not available in the sign-in language. SAP systems
have German as default for secondary language.
The secondary language is controlled by the profile parameter zcsa/second_

language in the instance profile. You can change it using the RZ10 transaction. After
the change, restart the SAP system.
14.8.2 SAP supplementation language

A second step is to supplement language dependent texts in tables. Language
supplementation is useful for any language in which you want to perform
customizing activities (except for English and German).
To perform language supplementation:
1. Run the SMLT transaction.

14.8. Supplementary language
2. Perform the language supplementation for client-dependent tables as well as for

cross-client tables.
3. Repeat the language supplementation after each installation of a new VIM
Support Package. New texts might have been introduced.
14.8.3 VIM Z constant LANGUAGE for Invoice Approval

The third step is to maintain the values in the VIM Z constant LANGUAGE (product
code IAP). This constant controls the set of languages that are used to look for
approval comments in addition to the sign-in language.
SAP GUI Approval uses the Z constant IAP LANGUAGE. Specify all languages that are
used as sign-in language for approvers in this variable.

Example: A user writes an approval comment while signed in in Swedish. The comment is
stored in a text file marked as Swedish. If someone else is signed in in another language, they
are only able to read the comment when the language Swedish is specified in the constant.
14.8.4 VIM web approval (Approval Portal)

The Approval Portal uses SAP texts as well as texts stored in a language specific
resource file. The procedure to adapt it to additional languages is described in
“Configuring additional languages” on page 290.
14.9 Translating VIM Fiori apps

Starting with version VIM 7.5 SP3 (VIM 7.0 SP7), VIM provides some VIM Fiori apps
built on Business Center framework:
• VIM Approve Invoices Fiori app (Approve Invoices app) introduced in VIM 7.5
SP3 (VIM 7.0 SP7)
• VIM Approve Invoices (bulk mode) Fiori app (Approve Invoices (bulk mode)
app) introduced in VIM 7.5 SP8
• VIM Enter Cost Assignment Simple Fiori app (Enter Cost Assignment Simple
app) introduced in VIM 7.5 SP4 (VIM 7.0 SP8)
• VIM Enter Cost Assignment Advanced Fiori app (Enter Cost Assignment
Advanced app) introduced in VIM 7.5 SP9
• VIM Resolve Invoice Exceptions Fiori app (Resolve Invoice Exceptions app)
introduced in VIM 7.5 SP4 (VIM 7.0 SP8)
• VIM Confirm Quantity and Price Fiori app (Confirm Quantity and Price app)
introduced in VIM 7.5 SP6 (VIM 7.0 SP10)
• VIM My Approved Invoices Fiori app (My Approved Invoices app) introduced
in VIM 7.5 SP7
• VIM Vendor Invoices Report Fiori app (Vendor Invoices Report app) introduced
in VIM 7.6 (VIM 20.4)
To translate VIM Fiori apps, consider the following components:
Note: Depending on the version deployed on the system, the corresponding

BSP application is considered. For example, if version 2 is deployed, then the
BSP /OTBCWUI/PF07_BC_UI_02 is considered. If version 3 is deployed, then the
BSP /OTBCWUI/PF07_BC_UI_03 is considered. In the following, the description
is applied for version 2.
• On the Fiori frontend system, create a property file for the given language in
package /OTBCWUI/PF07, BSP applications /OTBCWUI/PF07_BC_UI_02_T, page
fragment i18n.
Also create a property file for the given language in package /OTBCWUI/PS30 for
the following BSP applications:

14.9. Translating VIM Fiori apps
– BSP applications /OTBCWUI/PS30_VIM_UI, page fragment i18n.

– BSP applications /OTBCWUI/PS30_VIM_UI_02, page fragment i18n.
• Translate all texts in the SAP backend system. This is described in different
sections of “Setting up the environment” on page 238, especially in the following:
– “Maintaining the translation graph” on page 242

– “Assigning collections to translators” on page 253
– “Object list for VIM Fiori apps” on page 265
If you want to sign in in a language that is not supported or partly supported, you
can use the supplementary functionality described in “Supplementary language”
on page 295. Perform the following steps:
To work with a supplementary language:
1. On the Fiori frontend system, copy the property file i18n.properties.
2. Change the name to i18n_<xx>.properties, where xx is the code of the

language.
3. Add the new file to package /OTBCWUI/PF07, BSP applications /OTBCWUI/PF07_

BC_UI_02_T, page fragment i18n.
4. Add the new file to package /OTBCWUI/PS30, to the following BSP applications:
• BSP applications /OTBCWUI/PS30_VIM_UI, page fragment i18n.

• BSP applications /OTBCWUI/PS30_VIM_UI_02, page fragment i18n.
5. Perform the language supplementation on the SAP backend system as

described in “SAP supplementation language” on page 296.

Chapter 15
VIM Confirm Quantity and Price Fiori app: use
cases
To handle simple PO based invoices with the issues missing goods receipt or price
mismatch, you can use the VIM Confirm Quantity and Price Fiori app (Confirm
Quantity and Price app). Typical use cases are purchases of low volume that might
bypass delivery processing. In such cases, the goods may have already reached the
original requisitioner, who can easily confirm the goods receipt (GR).
A simple invoice is available in the Confirm Quantity and Price app if the following
prerequisites are met:
• Based on exactly 1 purchase order.

• Maximum 10 line items.
• Maximum 10 PO line items.
• Only goods / no service involved.
• Exactly one requisitioner involved.
• Quantity and/or price discrepancy (no other).
• Customizing was carried out. For more information, see Section 12.3
“Configuring the Confirm Quantity and Price app” in OpenText Vendor Invoice
• For blocked invoices: all line level work items are assigned to the same agent.
A background GR posting attempt is carried out after an invoice was submitted in

the Confirm Quantity and Price app if the following prerequisites are met:
• PO is GR based.
• A quantity discrepancy exists.
• The delivery value that was selected is configured for a GR.
• Sufficient data is available from PO and from screen.

Chapter 15 VIM Confirm Quantity and Price Fiori app: use cases
15.1 Use case 1: Invoice with missing GR:

requisitioner confirms GR - no specialist
required
This is an ideal use case with few people involved and with high automation.
1. An invoice arrives.
2. It is matched to a GR based purchase order.
3. Because the GR is missing completely, the document stops in the Manual Check
Needed / Missing Data for Indexing Line exception.
Accounts Payable
• enters the missing line item data manually as no proposal is available without
existing GR.
• bypasses the Manual Check Needed exception
• selects option Apply Rules.
The document has a quantity discrepancy in the line item. Assuming that the
company code is configured to send the document to the Confirm Quantity and
Price app automatically, the document is sent to the requisitioner’s Confirm
Quantity and Price app inbox (Fiori).
Requisitioner (Fiori)
• enters delivery number and date in the header data.

• selects a delivery dropdown value indicating that the goods were received.
• submits the document.
Assuming that quantity as invoiced is selected and that this selection is

configured for background GR, the following steps are carried out without manual
interaction.
Background processing
1. posts GR
2. checks for exceptions
3. posts invoice

15.2. Use case 2: Invoice with price discrepancy - specialist required for PO change
15.2 Use case 2: Invoice with price discrepancy -

specialist required for PO change
This is a complex use case with several people involved.
1. An invoice arrives.
2. It is matched to a purchase order (no GR required).
3. The invoice price is much higher than the purchase order price.
4. Because the tolerance limit is exceeded, the document stops in the Quantity/
Price Mismatch exception.
5. This exception is covered by the Confirm Quantity and Price app.
Requisitioner (Fiori)
• selects a price dropdown value indicating that the price is reasonable.

• enters a comment that price needs to be adjusted in PO.
• submits the document.
The document continues to Accounts Payable. Price issues usually need to be solved
by the purchasing organization.
Accounts Payable
• selects the process option Refer to Buyer.
Buyer (= Specialist)
• reads comments added by requisitioner.

• selects process option Change PO.
• changes PO price and saves.
Background processing
• posts invoice.
Note: If exceptions occur after the Quantity/Price Confirmation Required

step, for example Approval Required, the document does not automatically
continue. The Buyer needs to refer it to Accounts Payable. After the Apply
Rules option is selected, the document continues to the next exception.

Chapter 16
Posted invoice reversal with a new DP workflow
start
VIM 16.3.2 (and VIM 7.5 SP8) introduces a new utility that allows selecting an
invoice posted from VIM, cancel it, and start a new DP workflow with a document
containing the same data. DP process log, approval log and entered comments are
copied and linked to the new DP document. This allows restarting a process,
keeping the history easily available for reference.
To implement this functionality, a tool is designed to cancel the PO/NPO invoice

and copy the original DP invoice data to a new DP workflow.:
Technical object details
Transaction code
/OPT/INV_CANCL_RECRT
Program name
/OPT/INVOICE_CANCEL_DP_CREATE
Authorization check in reporting
• Authority object J_6N1M_BUK, which has activity, logical system and company
code.
• Activity checked currently in the report is 02- Change.
To process the report:
1. Run the /OPT/INV_CANCL_RECRT transaction.

Chapter 16 Posted invoice reversal with a new DP workflow start
2. Enter selection criteria:
• Company Code and Reversal Reason (PO/NPO) are mandatory fields.

• If you want to cancel/reverse posting for PO invoices, enter the Reversal
Reason for PO invoices. The user can enter the posting date as well.
Similarly for cancelling NPO invoices, enter the Reversal Reason for NPO
invoices and the user can enter the posting date as well.
• Retain original Doc. Type for the New Document check box:
Select this check box to retain the existing DP document type for the newly
created DP document.
Clear this check box to let the system open a dialog box where the user can
enter the new DP document type value for the newly created DP document.
Note: While entering/selecting a new DP document type in the dialog

box, and if the cancelled document is PO, select a PO DP document
type only. You can further convert a PO DP document type into an
NPO DP document type, using the process option Change document
type in the DP indexing screen. The same applies for NPO document
types.
3. To run the report, click .

In the initial ALV report output, the Cancel and Recreate DP button is available
for users in the ALV toolbar.

When the user selects a particular document and clicks the Cancel and Recreate
DP button, the system will cancel the existing SAP invoice and a new DP
document is recreated, which is shown in the secondary ALV grid.
The secondary ALV grid contains the following fields: Old Docid, New Docid,
Status, and Status Message:
• Status indicates Success or Failure.

• Status Message gives detail information about the DP document.
Note: Users can use the Download option in the ALV toolbar for
downloading the results of secondary ALV list data in an Excel sheet and
save it to the desktop for reference.
Functionality limitations
• For the newly created DP document (PO invoices), DP log entries are shown and
blocked action log entries are not shown in the process history tab of VIM
Analytics.
• For the newly created DP document (NPO invoices), DP log entries are shown
and posted action log entries are not shown in the process history tab of VIM
Analytics.
• For the newly created DP document (PO/NPO invoices), DP Approval action
entries are shown in the Approval History tab of VIM Analytics and Posted
approval action entries are not shown.

Chapter 17
SAP S/4HANA embedded analytics
For customers with an SAP S/4HANA backend system, OpenText introduces a set of
ABAP Core Data Services (CDS) views built on top of the analytics database.
OpenText delivers CDS queries and corresponding OData queries, which can be
used by the end user to derive analytics data.
CDS queries can be used not only by SAP S/4HANA tools like Query Browser but
also by other SAP reporting tools, which are designed for BW queries, like SAP
Lumira Designer or SAP Analysis Office.
An OData that is created from an analytical query with the annotation @Odata.
publish = true is called OData query. It is known as a gateway service based
analytical query.
An Odata query can be used by reporting tools that require Odata as data service.
These are for example tools delivered in SAP Business Analytic frameworks, which
are delivered as SAP S/4HANA content like Smart Business KPI and Smart Business
APF.
This chapter provides detailed information of available Queries and OData. It also
provides instruction how to create Analytics Reports using the delivered ODatas.
17.1 Invoice Life Cycle analytics

CDS Query and OData are provided for creating an Invoice Life Cycle analytics
report.
17.1.1 CDS views

CDS queries and Odata queries are delivered to create analytics reports for VIM
Invoice Life Cycle. The queries are described in this section. OData queries are
created automatically based on the counterpart CDS queries. Therefore they deliver
the same data. For more information how OData queries can be used to create Fiori
analytics reports using Fiori Elements, see “Analytics reports” on page 313.
CDS Query / OData query Description Status Released

VIM Invoice Life Cycle
/OPT/VAS4_ILC_QUERY Active VIM 20.4
Query
VIM Invoice Life Cycle
VAS4_ILC_QUERY_CDS Active VIM 20.4
OData

Chapter 17 SAP S/4HANA embedded analytics
17.1.1.1 Using /OPT/VAS4_ILC_QUERY

/OPT/VAS4_ILC_QUERY provides the statistics of all activities done for each VIM
process. The information is available as History in VIM Analytics. An SAP GUI
report which provides the same data is the VIM ILC report.
Note: Data provided by the query is a mixture of data from header table (/
OPT/VIM_1HEAD) and from Invoice Life Cycle table (/OPT/VT_ILC_SRC). It is the
end user’s task to decide which fields should be included in which views. For
more information, see “Recommended views in the VIM ILC report”
on page 316.
The introduction of the From Date as input parameter allows users to select
documents that are created in a previous time frame. For performance reasons,
OpenText recommends restraining the use of this parameter to avoid loading of
irrelevant data when running the report.
Table 17-1: Input parameters
Parameter Description Data Type Default

value
P_ExchangeRateType Defines the type of the String M
exchange rate that is used for
currency conversion in the
report.
P_DisplayCurrency Displays the currency of the String USD
report.
P_FromDate Earliest date for processes that Date Custom
are considered. Date
The CDS query contains a list of characteristics which allows to group and/or filter.
The characterisitics provide the following data:
• Process Data
For example: Logical System, Document ID, Document Type, Document Status,
Channel ID
• Process Timing Data
For example: Started Date, Start Time, Started in year/month/quarter, Started in
year, End Date, End Time.
• Log specific Data
For example:
– For logs in DP Process: Process Type, Process Status, Current Agent, Current
Role, Option ID, Work item ID, Work item Status, Log Type
– For logs in Approval workflow: Current Approver, Approval Action, Referral
Indicator, Sender Approval, Referee

17.1. Invoice Life Cycle analytics
– For logs in Block workflow: Block Reason, Block Option ID, Block Option
Type
– Common log data for all kinds of workflows, like Work item ID, Work item
Status, Activity Start Date, Activity Start Time, Activity End Date, Activity
End Time
– Technical data: Log Count (number of logs) and Line number, Log number in
sequence
• Invoice Header Business Data
For example: Fiscal Year, Company Code, Vendor, Credit Memo, Accounting
Document, Purchasing Document, Reference Number, Invoice Type
Table 17-2: Status and indicators
Dimension Column Description

SAPDOCCREATED SAP document creation status:
X:
SAP document created
#:
SAP document not created
PROCESSFINISHED Indicator if process is finished
X:
Process finished
#:
Process not finished
DIALOGIND Dialog flag
X:
The activity/log in dialog
#:
The activity/log not in dialog
REFERRALIND Referral Indicator
X:
The activity/log is a referral process.
#:
The activity/log is not a referral process.
Table 17-3: Key figures: Process counts and timings
Key figures Column Description

DOCCOUNTER Total number of documents
GROSSAMOUNTINDOCCURRENCY Total Gross Amount in Document Currency
GROSSAMOUNTINDSPCURRENCY Total Gross Amount in Display Currency
AVGDURATIONSECONDS Average Cycle Time in Seconds

Key figures Column Description

AVGDURATIONMINUTES Average Cycle Time in Minutes
AVGDURATIONHOURS Average Cycle Time in Hours
AVGDURATIONDAYS Average Cycle Time in Days
AVGPROCESSINGTIME_S Average Processing Time in Seconds
AVGPROCESSINGTIME_M Average Processing Time in Minutes
Notes
• The cycle time is calculated in the following way: For completed processes, it
is end time - start time. For documents in process, it is current time - start
time.
• Processing time for a document is the sum of all processing time of all
activities done for the document. Activities or work items in process are not
considered.
17.1.2 Authorization for CDS views

You need the framework authorization objects. For more information, see Section 8.4
“Authorization objects” in OpenText Vendor Invoice Management for SAP Solutions -
Additionally maintain the following field for semantic navigation:
Authorization Object:
J_6NPF_NAV - OpenText Business Center for SAP Solutions - Work center
Field:
J_6NPF_PLA = PF31_SEM_NAV
The following authorizations are additionally required to access data using the CDS
views framework:
Authorization Object Description Fields

J_6NIM_BUK OpenText VIM authorization /OPT/BUKRS
checks - company code The authorized Company
Code
LOGSYS
The authorized logical
system
ACTVT
'03' Display

17.1.3 Analytics reports

You can create different kinds of reports using the delivered CDS query and OData.
For more information on how to use OData to create an Analytical List Page (ALP)
report, see Section 11.1.2 “Generating reports in Web IDE” in OpenText Vendor
Invoice Management for SAP Solutions - Configuration Guide for Foundation (BOCP-
CGD).
This section gives the details of Analytical List Pages which can be created for VIM
documents.
Analytical List Page (ALP) report for VIM Invoice Life Cycle
You can create the report using OData VAS4_ILC_QUERY_CDS which serves as a
service to deliver data available in the 2 tables /OPT/VIM_1HEAD and /OPT/VIM_ILC_
SRC. The OData is created automatically from the CDS Query /OPT/VAS4_ILC_
QUERY. Therefore it delivers the same set of data. See “CDS views” on page 309 for
all statistics that can be delivered by the query /OPT/VAS4_ILC_QUERY and by the
corresponding OData.
The created report has the following features:
Input parameters:
Exchange Rate Type:

Exchange rate type that is used for currency conversion
Display Currency:
The amount KPI in a specific currency.
From Date:
Selects a subset of documents instead of the whole set of data. This helps to
improve the performance of the report
Available Virtual filters:
Virtual filters allow to filter quickly and intuitively.
• Number of Documents by Channel
• Number of Documents by Finished indicator

• Number of Documents by Started at Year
• Number of Documents by SAP Doc Created
• Number of Documents by Invoice Type NPO/PO

Table 17-4: Technical details of VIM Invoice Life Cycle Analytics:
Objects Details
BC Analytical Framework not relevant
Core Data Services (CDS)
view
CDS view input P_ExchangeRateType
parameters M (default value)
P_DisplayCurrency
USD (default value)
P_FromDate
01.01.2018 (default value)
Fiori Elements Template Analytical List Page (ALP)

OData Service VAS4_ILC_QUERY_CDS
Metadata extension /OPT/ VAS4_ILC_QUERY
Access control The access control is implemented in the underlying CDS cube.
The following authorization objects are applied:
• Company Code/Logical System
J_6NIM_BUK, /opt/bukrs, logsys, ACTVT = '03'
Template customization • OData Collection:
xOPTxVAS4_ILC_QUERYResults
• ODATA Navigation:
<Leave empty>
• Qualifier (content area):
Default
• Table Type:
Analytical
• Allow Multi Select (Table):
Not active (recommended)
• Auto Hide:
Active (recommended)
• Other fields:
Keep the default configuration.

Objects Details
Semantic navigation The following semantic objects are annotated in the CDS view.
• Supplier (delivered by SAP)
• SupplierInvoice (delivered by SAP)
• PurchaseOrder (delivered by SAP)
• OTBCVIM_DOCID: For navigation to VIM Task App
Parameters for target mapping of the semantic object

OTBCVIM_DOCID:
Caution
The parameters are case sensitive.
wobjType
PS311_VIM_VANREP (default value)
workplaceId
PF31_SEM_NAV (default value)
nodeId
PS311_PRC_VIM_VANREP (default value)
resolveParamsAtBackend
true (default value)
appMode
OBJ (default value)
systemAlias
<enter the system alias for the target backend system (as defined
in /IWFND/MAINT_SERVICE)> (default value)
OTBCVIM_DOCID
plkey (target name)
Note: Do not fill the fields Value or Mandatory.
Only use Name and Default Value or Target Name to

set these parameters.

Objects Details
Virtual filters Five virtual filters are available.
CollectionPath: xOPTxVAS4_ILC_QUERYResults
Property and its PresentationVariantQualifier:

• ChannelID:
FilterDocumentsPerChannel
• StartCalendarYear:
FilterDocumentsPerYear
• ProcessFinished:
FilterDocumentsPerFinished
• SAPDocCreated:
FilterDocsPerSAPDocCreated
• InvoiceType:
FilterDocumentsPerPOnPO
Local annotation.xml VIM_ILC_ALP_Annotations.xml
file name
Recommended views in the VIM ILC report
The ILC report delivers both data on header level and on history/log level for
different processes. Therefore it makes sense to display data according to different
categories by using different variants (views) for the table. Each view contains
columns that are relevant for the category only.
This section describes some recommended views.
Table 17-5: Overview view
Fields Kind Additional Details

Channel Dimension Inbound Channel
Start in Year Dimension Calendar Year
Company Code Dimension
Number of Documents Measure
Total Amount in Doc Currency Measure
Total Amount in Disp Currency Measure
Avg. Cycle Time in seconds, minutes, hours, days Measure
Avg. Processing Time in seconds, minutes Measure

Table 17-6: Document view: List of all documents
Fields Kind Additional Details

Semantic navigation
Document ID Dimension
available
Channel Dimension
Company Code Dimension
Semantic navigation
Vendor/Vendor Name Dimension
available
Reference Dimension
Started On Dimension
Started At Dimension
Ended On Dimension
Ended At Dimension
DP Document Type Dimension
Document Status Dimension
Invoice Type Dimension
Semantic navigation
Purchasing Document Dimension
available
Semantic navigation
Accounting Document Dimension
available
Total Amount in Doc Currency Measure
Total Amount in Disp Currency Measure
Avg. Cycle Time in seconds, minutes, hours, days Measure
Avg. Processing Time in seconds, minutes Measure
Note: To navigate to the correct factsheet of Purchasing Document or

Accounting Document, the fields like Company Code and Fiscal Year are
required in the view.
History view – A list of all logs of a subset of documents.
In this view you can see all logs of all documents, or a log of a certain process. You
can use the filter LogType for selecting logs of a certain process.
DP : Logs in DP Process (bus_objtype = '/OPT/V1001')
AP : Logs in Approval Process
BL : Logs in Blocked Processing (bus_objtype = '/OPT/LIV' or '/OPT/B2081')
PK : Logs in Parked Processing (bus_objtype = '/OPT/FIPP')

WI : Log of a work item in process (not finished document)
Table 17-7: History view
Fields Log Type Additional Details

Document ID All Log Type
Line Number All Log Type Log Line Number
Process Option ID Log in DP Process
Process Type Log in DP Process
Process Status Log in DP Process
Current Role All Log Type
Current Agent All Log Type
Activity Start Date All Log Type
Activity Start Time All Log Type
Activity End Date All Log Type
Activity End Time All Log Type
Park Reason Log in Parked Processing
Approval Action Log in Approval Process
Approver Log in Approval Process
Sender Approval Log in Approval Process
Referee Log in Approval Process
Block Option ID Log in Blocked Processing
Block Option Type Log in Blocked Processing
Block Reason Log in Blocked Processing
For each log type you can create a view, for example Approval Process View, Parked
Processing or Blocked Processing View. Combine the filter LogType and the view to
get all information related to that log type.

17.1.4 Integrating VIM ILC reports into the SAP Standard

Overview Page
A helpful use case is to integrate VIM ILC reports into SAP Standard Overview Page
as a set of Quick links. It allows the end-user to quickly go to the VIM ILC report
without quitting the page.
Preparation
• Assign the role to the administrator: SAP_UI_FLEX_KEY_USER

• Assign the role to the administrator: Business Role for SAP Standard Overview
Page, for example SAP_BR_AP_MANAGER is required for Accounts Payable
Overview.
• Create the Fiori tile for the custom Fiori App.
To integrate VIM ILC reports into the SAP Standard Overview Page:
1. Login to Fiori Launchpad as the Administrator.
2. Open the Fiori App Accounts Payable Overview
3. Go to User > Adapt UI
4. Right-click the Quick Links card, and then, on the context menu, click Edit .
5. In the next window, click the + button to add a new link:

a. Enter the Link Title and the Link Subtitle.

b. Add the icon that will be displayed next to the link.
c. Enter Link to:. In this step, you can do this in 2 ways:
• The first way calls the Fiori App without parameters:

Click Application, and use the Search help button in URL to select the
custom Fiori App for that you want to create a link.
• The second way calls the Fiori App with default parameters, for
example P_FromDate, P_DisplayCurrency and P_ExchangeRateType:
Click URL, and then enter the URL of the custom Fiori Apps in the
following format:
<Custom server>:<Port>/sap/bc/ui5_ui5/ui2/ushell/shells/
abap/FioriLaunchpad.html#ZVIMANA-display_ILC?P_
DisplayCurrency=USD&P_ExchangeRateType=M&P_FromDate=
2018-01-01
d. Click Save.
Now the Quick Links card contains the new link.
6. Click Save As in the menu.

7. In the Save as New Variant dialog box, enter Title and Description for the
variant. For one Fiori App, you can create a number of variants. Therefore
OpenText recommends choosing a good description. Click Save.
8. In the Information dialog box, click Copy ID and Close.

The ID of the UI Adaptation, which is copied in this step, will be needed for the
next steps.
9. As an administrator with sufficient right, go to the Fiori Launchpad admin

page, and then open your catalog.
10. Create a new Target Mapping with your Semantic Object and Action. Paste the
ID copied in Step 8 on page 321 into the ID field.
11. Create a static tile with the Semantic Object and Action created in Step 10
on page 321. The title entered here is displayed in the Fiori Launchpad.
12. Sign in as the end user, and then add the newly created tile to the Fiori
Launchpad Home of the end user. The tile is available in the Launchpad.
13. Call the Overview page with variant. The Quick Links card contains the new
link. Click the link to call the custom Fiori App.

Chapter 18
Smart coding
Smart coding, a component for coding Non PO invoices, enables you to streamline
the process by helping the user to correctly allocate the cost objects using a
recommender step with best predictions or by fully automating the coding in the
background, based on a minimum confidence level.
Prior to smart coding, users needed to manually assign the cost objects to Non PO
invoices. This activity frequently required time-consuming research, for example by
inspection of old invoices posted to the same vendor, asking a colleague, or, worst-
case, guessing by doing an extensive search in the help menu of the field.
Smart coding is a scenario suited for machine learning: An algorithm determines,

which invoice fields allow the best predictions. Based on this model, it delivers
different alternatives and their confidence level. If the confidence exceeds the
configurable minimum threshold, the step is fully automated. In all other cases, the
algorithm presents the alternatives to the user in a dialog box.
For configuration aspects of smart coding, see Section 19 “Smart Coding -

Integration into Classic VIM” in OpenText Vendor Invoice Management for SAP
Solutions - Configuration Guide for Invoice Solution (VIM-CGD)
The following Z constants are relevant for smart coding:
SMART_CODE_MODEL
For more information, see Section 19.1.1 “Smart coding cost line items
enrichment in background” in OpenText Vendor Invoice Management for SAP
SMART_CODE_LM_PROCID
For more information, see Section 19.2 “Skipping the coder level in smart coding
line automation” in OpenText Vendor Invoice Management for SAP Solutions -
For more information about the smart coding logic module, see Section 19.1.1
“Smart coding cost line items enrichment in background” in OpenText Vendor Invoice
Management for SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD)
and Section 31.6 “Enrich smart coding cost line items” in OpenText Vendor Invoice
Management for SAP Solutions - Reference Guide for Invoice Solution (VIM-RGD).

Chapter 18 Smart coding
18.1 Training the models

The following training models are available:
• “Training: Basic/static model” on page 324

• “Training: PAL model” on page 325
• “Training: save preprocessed data” on page 328
• “Training: load preprocessed data” on page 329
18.1.1 Training: Basic/static model

Based on the combination of company code and supplier, the static model analyses
the historical data and automatically proposes a combination of GL account and cost
object (Cost Center, WBS), based on the confidence level calculation.
Prerequisites Prepare data for training the model:
• Post 4 NPO invoices.

• All lines for all invoices must have the same vendor, line item amounts, tax
codes, and GL Accounts. The cost objects, in this case cost center, are different.
To train the basic model:
1. Run the /OTX/PS302_TRAIN_DEL transaction. To clear all learning data, select all
check boxes: Delete Basic Model, Delete Coding Table, and Delete Feature
Table.
2. To train the model, run the /OTX/PS302_TRAIN_COD transaction, and then set
the following parameters:
• In the Data Selection area, click Use Ledger Data.

• Select the 4 prepared invoices.
• In the Model area, click Train Basic Model.
• Select the Test Mode check box.
Note: For a description of the other parameters in the Data Selection and
Model areas, see Section 18.1.1 “Train coding statistics: /OTX/
PS302_TRAIN_COD” in OpenText Vendor Invoice Management for SAP

18.1. Training the models
3. Click to run the training.
4. Run the /OTX/PS302_TRAIN_COD transaction without selecting the test mode.

Set the following parameters:

• In the Model area, click Train Basic Model.
• Clear the Test Mode check box.
6. To display the results, run the /OTX/PS302_TRAIN_DIS transaction.
3 different coding lines are displayed for the chosen Vendor. The Frequency
column shows the number of times the cost center is repeated for a given set of
invoices given in the input column.
• Cost Center 17101101 shows 4 occurrences.

18.1.2 Training: PAL model

To train the PAL model, the system proposes GL accounts, cost centers, and WBS
elements, based on various input data using a machine learning based classification
algorithm, so-called decision trees.
The following table shows the input data. The actual selected data depends on the
chosen selection variant. If values are missing in the underlying database tables, the
fields will be handled as empty.
Field Ledger Data VIM Data

Company code ACDOCA-BUKRS /OPT/VIM_1HEAD-BUKRS
Invoicing Party ACDOCA-LIFNR /OPT/VIM_1HEAD-LIFNR
Requester N/A /OPT/VIM_1HEAD-REQUISITIONER

Field Ledger Data VIM Data

Expense Type N/A /OPT/VIM_1HEAD-EXPENSE_TYPE
Invoice Day ACDOCA-BLDAT /OPT/VIM_1HEAD-BLDAT
Invoice Month ACDOCA-BLDAT /OPT/VIM_1HEAD-BLDAT
Tax Rate N/A /OPT/VIM_1ITEM-TAX_RATE
Amount (external ACDOCA-TSL /OPT/VIM_1HEAD-WRBTR
format)
The minimum requirement for this model is an installation of VIM4SAP 20.4 on an

SAP S/4HANA 1610 system with at least HANA 2.0 SPS 3 and installed PAL library.
Before PAL model training, you must first run the Basic model.
To train the PAL model:
1. Run the Basic model training with and without Test Mode, see Step 2
on page 324 and Step 4 on page 325.
2. To run the PAL training, run the /OTX/PS302_TRAIN_COD transaction, and then
set the following parameters:
• In the Model area, click Train PAL Decision Tree Model.
• Select the Test Mode check box.
4. Run the /OTX/PS302_TRAIN_COD transaction, and then set the following

parameters:
• In the Model area, click Train PAL Decision Tree Model.
Smart coding proposal in the DP document

The Smartcoding items Proposal screen shows the following:

Note: If you run the PAL based training directly without running the basic
model training before, an error message with the following text is displayed:
OpenText: Train Coding Statistics
<X> entries processed in 0 seconds.
Please train Basic Model first.
In VIM Central Workplace, the current version of the PAL model is displayed as in
the following screenshot.

18.1.3 Training: save preprocessed data

The selection and preprocessing steps are run and saved to a table, either on the
local system or on a remote training system. If you use the remote scenario, you
must enter an RFC destination to this system.
Prerequisites
• Set up an RFC connection to a system with Smart Coding installed. A PAL

enabled system is mandatory.
To save preprocessed data:
1. Delete the training data in both source and remote systems.

Run the /OTX/PS302_TRAIN_DEL transaction for the local logical system (source
system).
To clear all learning data, select all check boxes: Delete Basic Model, Delete
Coding Table, and Delete Feature Table.
To delete the entries for the remote system, run the /OTX/PS302_TRAIN_DEL
transaction in the remote system.
To clear all learning data, select all check boxes: Delete Basic Model, Delete
Coding Table, and Delete Feature Table.
2. Click to delete the training data.
Note: This deletes entries for the source system in both source and target
systems.
3. Save Preprocessed Data only option: local scenario
Run the /OTX/PS302_TRAIN_COD transaction with the following parameters:
Data Selection area

Click Use Ledger Data or Use VIM Data.
Model area
• Click Save Preprocessed Data only.

• Clear the Clear existing data check box.
• Empty the Trainings System field.

Entries are available in the following tables in the source system:
• /OTX/PS302_T_CHS
• /OTX/PS302_T_FTR

5. Save Preprocessed Data only option: remote scenario

Run the /OTX/PS302_TRAIN_COD transaction with the following parameters:
Data Selection area

Click Use Ledger Data or Use VIM Data.
Model area
• Click Save Preprocessed Data only.

• Clear the Clear existing data check box.
• In the Trainings System field, enter the remote system.

Entries are available in the following tables in the remote system:
• /OTX/PS302_T_CHS
• /OTX/PS302_T_FTR
18.1.4 Training: load preprocessed data

Prerequisites
• Static training has been done with the Save Preprocessed Data only option on
both local system and remote system.
• After the training, data is available in table OTX/PS302_T_FTR on the local system
(LOGSYS = source system) and on the remote system.
To load preprocessed data:
1. Run the /OTX/PS302_TRAIN_COD transaction on the source system with the

Data Selection area
• Click Load Preprocessed Data.

• Empty the Source System field.
Model area
• Click Train Basic Model.


3. Remote scenario
On the source system, run the /OTX/PS302_TRAIN_COD transaction with the
Data Selection area
• Click Load Preprocessed Data.

• In the Source System field, enter the remote system name.
Model area
• Click Train Basic Model.

18.2 Smart coding button in the DP indexing screen

With VIM for SAP 20.4 and VIM for SAP 7.6, a new button Smtcoding is introduced
under the smart coding column in the line items tab of the indexing screen. Clicking
the button displays the Smartcoding items Proposal screen. This smart coding
proposal is based on the combination of Cost Object and GL account. For more
information, see “Smart coding proposal in the DP document” on page 326.

18.3. Testing a DP document with smart coding proposal
18.3 Testing a DP document with smart coding

proposal
Create a DP document through any channel. Access the DP document in the current
agent's indexing screen. In the indexing screen, click the smart coding button. For
more information, see “Smart coding button in the DP indexing screen” on page 330.
The Smartcoding items Proposal screen proposes Cost Center and GL Account,
based on training.
18.4 Confidence level calculation

The confidence level is calculated on a combination of GL account and cost object
that is repeated in a number of invoices.
Note: The confidence level is not calculated on the number of invoice line
items but on the number of times that a combination of GL account and cost
object (in this case cost center) is repeated in the invoices.
In the example in this chapter, 4 invoices were created with the following cost
centers. The following list shows the repetition rate and the confidence level:
• Cost center 17101101 | repeated in all 4 invoices | so confidence level is 100%
• Cost center 17101201 | repeated in 3 invoices | so confidence level is 75%
• Cost center 17101801 | repeated in 2 invoices | so confidence level is 50%

Chapter 19
Processing SAP Transportation Management
invoices
SAP Transportation Management (SAP TM) supports all activities related to the
physical transportation of goods from one location to another.
Typical examples of processes performed with SAP TM include:
• Create freight bookings

• Plan the transportation and select carriers
• Calculate the transportation charges for both the ordering party and the supplier
side
Starting with SAP 20.4, you can process invoices with reference to SAP TM
documents:
• Freight order
• Freight settlement
• Bill of lading
• Air waybill
Note: There are different solutions that SAP offers as Transportation

Management:
• Standalone SAP TM 9.x that is running separately from SAP ECC or SAP S/
4HANA and is normally integrated with ERP systems through PI interface.
• SAP S/4HANA Transportation Management that can be used in embedded
(running on the same system with ERP functions) or in standalone scenarios.
This is available starting with SAP S/4HANA 1709. For more information,
see SAP Note 2514203.
VIM Invoice Solution supports SAP S/4HANA Transportation Management in

the embedded deployment scenario only. Standalone SAP TM 9.x is not
supported.

Chapter 19 Processing SAP Transportation Management invoices
19.1 Configuring the document type

You can configure a new document by copying the standard one, PO_S4. For the
new document type, you can use all relevant business rules from PO_S4 as they are,
or copy them to a new one.
Note: In this release, no new document type is delivered.
19.1.1 Document type determination

For document type determination, a standard function module /OPT/VIM_DETERM_
TM_DOCTYPE is delivered. It can be configured as shown in the following.
Note: OpenText recommends that you add the determination step in a way
that it is located before any steps determining Non PO invoices.
For more information, see Section 15.1.3 “Document type determination and
characteristic customizing” in OpenText Vendor Invoice Management for SAP Solutions
- Configuration Guide for Invoice Solution (VIM-CGD).
19.1.2 Configuring the header

To configure the header:

Maintain Document Types > Index Header Configuration.

19.1. Configuring the document type
2. Add fields using the following parameters:
Field Name
Enter ABWN_ID and ABWN_LIST.
Field Stat
Select Input from the list.
3. Repeat the same configuration for the following fields:
• SFIR_ID
• FSN_LIST
• TOR_ID
• TOR_LIST
• WBN_ID
• WBN_LIST
4. Configure the following field to be input enabled:
• EBELN
19.1.3 Configuring the index item

To configure the index item:

Maintain Document Types > Index Item Configuration.
2. Add an entry for AWBN_ID, using the following parameters:
Field Name
Enter AWBN_ID.
Field Stat
Select Input from the list.
PO Tabstrip Control
Select PO Reference Tab Only from the list.

3. Repeat the same configuration for the following fields:
• SFIR_ID
• TOR_ID
• WBN_ID
19.1.4 New fields in the DP indexing screen

Basic Data - In the DP indexing screen, a new frame TM Specific Data is available when the
Header fields in the document type are configured in the index screen header configuration
described in “Configuring the header” on page 334.
OpenText recommends that you always use one of the following fields when
processing the invoice:
• Freight Order
• Freight Settlement
• House Bill of Lading
• Air Waybill
Line Items tab Fields in the Line Items tab of the indexing screen are displayed if configured in the
Index Item configuration, as described in “Configuring the index item” on page 335.

19.1.5 Proposal list and proposal tab

When the fields are configured in the Basic Data tab, the proposal tab in Line Items
shows the following in the proposal list to run the proposal based on relevant TM
orders:
• Freight Order
• Freight Settlement
• House Bill of Lading
• Air Waybill
When you run proposal using the Propose Lines button, the relevant data will be
populated in the proposal line tab, as shown in the following screenshot:
Note: For a Freight Order originated from an Air Waybill, all the data are
populated, as shown in the following screenshot. If the Freight Order is
standalone and not originated by an Air Waybill or a House Bill of Lading,
only Freight Order and Freight Settlement details are shown.

19.1.6 Logic module processing

You can configure the new document type in similar lines to the PO document type.
All existing relevant Process IDs can be mapped to the new document type.
The existing logic module class /OPT/CL_D_LM_DETERM_PO_MAP is enhanced to

support TM references. Data processed from the inbound process (IES/ICC) is
transferred to VIM, based on the following lists:
• Freight Order list

• Freight Settlement list
• House Bill of Lading list
• Air Waybill list
Note: No new logic modules are delivered for TM at present.
19.1.7 Posting
The existing background posting BDC 2200 has been extended to support TM
references.
For online posting, the standard BDC 1 has been extended to support TM references.
Currently, this is limited to only one reference document. If you use several
references, it is possible to manually copy the list from the indexing screen, and add
the list later in the proposal selection of the MIRO screen.
Process options No process options are delivered in standard.
19.1.8 Process type Check for Transport Order PO

You can activate the process type 437 Check for Transport Order PO, which is
triggered when the invoice has a PO relevant to TM. This process type was delivered
in earlier VIM releases to prevent wrong posting of TM invoices, before VIM 20.4.
When the data was verified, the user could choose to bypass the rule to post the
invoice.
OpenText recommends that you review the usage of this process type if the new
functions of TM invoice processing will be used.

19.1.9 OCR input of TM invoices

The OpenText OCR solution, Intelligent Capture for SAP® Solutions 20.4, supports
OCR based input of TM invoices. All TM reference fields are learning based, which
means that the OCR engine must be trained to recognize the fields by performing
validation for the first invoices of the same layout.
In the validation client, the following header level list fields and item level single
value fields are supported:
Field Field ID to be used in validation settings

Freight Order HDR_FREIGHT_ORDER
Freight Settlement HDR_FREIGHT_SETTLEMENT
WayBill HDR_WAYBILL
Air WayBill HDR_AIRWAYBILL
Freight Order ITM_FREIGHT_ORDER
Freight Settlement ITM_FREIGHT_SETTLEMENT
Freight Settlement Item ITM_FREIGHT_SETTLEMENT_ITEM
WayBill ITM_WAYBILL
Air WayBill ITM_AIRWAYBILL
19.1.10 Inbound configuration

Inbound mapping from IES to VIM is delivered as shown in this section. The
configuration is maintained at the following location:
Run the /n/OPT/SPRO transaction and navigate to OpenText Vendor Invoice

Management Invoice Solution > Document Processing Configuration > General
Configuration > Incoming Document Processing > IC4SAP (IES) Data Mapping.

Corresponding field mappings have been added into VIM mapping GENERAL.

19.1.11 Limitations
• IDoc is not supported.
• Blocked invoice workflow is not supported.
• Multiple combination of data (like 2 standalone freight order plus airway bill) is
not supported. At given point of time, any one type TM order can be posted.
• Online posting is possible only for one TM reference. Example: If an invoice is
having two different freight orders, only the first freight order can be posted.
Additional references must be added manually in the called MIRO screen.

Part 2
Classic VIM - technical scenarios
Part 2 Classic VIM - technical scenarios
Technical scenarios refer to customizing standard VIM functions, from the point of
view of a special requirement or an overview of the complete system. An example
for a special requirement are business requirements of Central Reporting. An
example for an overview is the end-to-end description how to add new fields in ICC
and VIM.
For detailed descriptions of customizing settings, technical scenarios may provide

links to the standard documentation.

Chapter 20
Adding new fields in ICC and VIM
Adding a new field is a common requirement when customizing OpenText Invoice

Capture Center (ICC) and VIM. This chapter collects information where and how
you can add fields throughout the complete application, from custom fields in ICC
to additional selection fields in VIM Analytics.
20.1 ICC
You can extend ICC by adding custom fields that will be exported to VIM
automatically. See Section 3.6 “Adding custom fields to an invoice application” in
CGD).
To process the custom fields, you must extend VIM accordingly:
• ICC uses an external field name, for example InvoiceNumber. Map this name to
the VIM document field name, for example XBLNR. See “Maintaining Mapping
IDs” on page 51.
• If you are adding a field in the item table, you have to add the target field name
to the index item configuration of the document type. If you do not perform this
action, the field value will be cleared when the DP workflow starts.
Overwriting In ICC, you can add custom fields, as described in Section 3.6 “Adding custom fields
standard fields to an invoice application” in OpenText Business Center Capture for SAP Solutions -
Customization Guide (CPBC-CGD). You can use the value of a custom field to
overwrite an ICC standard field. For more information, see Section 3.7 “Using rule-
based custom methods for standard fields” in OpenText Business Center Capture for
SAP Solutions - Customization Guide (CPBC-CGD). In this scenario, no further
customizing is needed on VIM side.
Additional costs In ICC, the extraction of additional costs and discounts is switched off by default.
fields However, you can activate the extraction to new fields, for example a Discount field.
For more information, see Section 3.4.6.3 “Specifying extraction of additional costs
and discounts” in OpenText Business Center Capture for SAP Solutions - Customization
Guide (CPBC-CGD).
To process these fields on VIM side, some configuration is necessary; for more
information, see Section 9.15 “Maintaining additional cost handling” in OpenText
(VIM-CGD).
ICC field For a comprehensive description of ICC fields, see Section 5 “Field references for
reference Invoice Solution (Invoice Capture Center)” in OpenText Business Center Capture for
SAP Solutions - Customization Guide (CPBC-CGD). This section describes recognition

Chapter 20 Adding new fields in ICC and VIM
and processing details for the ICC fields, as well as the meaning of the
corresponding fields in the VIM process.
20.2 Standard VIM tables

You can enhance the standard VIM tables, for example, add custom fields, using
SAP Append Structures. For more information, see the SAP Help.
This applies to the following VIM tables:
/OPT/VIM_1HEAD
Customer specific header fields table
/OPT/VIM_1ITEM
Customer specific line item fields table
When making appends, use user defined field names ZZxxx as recommended by
SAP. If you use SAP field names, there may be difficulties with updates and even
wrong behavior.
The safest way of adding new fields is adding an append structure at the end of the
table. However, you cannot use this method if you want to see the field in the
indexing screen. A different way is described in Section 9.18.1 “Extending document
data” in OpenText Vendor Invoice Management for SAP Solutions - Configuration Guide
for Invoice Solution (VIM-CGD). The structures mentioned there are includes in /OPT/
VIM_1HEAD but as they are not at the end of the table, difficulties can arise if there is
coding which does not consider such extensions in the middle of a table.
Note: The maximum length of an enhancement field is 255 characters.
Custom fields If you do not want to modify the standard, you can use dedicated fields in the /OPT/
VIM_1HEAD and /OPT/VIM_1ITEM tables. These fields are named CUSTOM_FIELD<X>,
for example CUSTOM_FIELD4.
The custom fields provided in tables /OPT/VIM_1HEAD and /OPT/VIM_1ITEM have

different data types. You can reuse the custom fields to process any information that
is process and business relevant within the whole process of indexing and approval.
You can also use the custom fields to transfer necessary information within the SAP
posting and parking transactions.

20.3. VIM Invoice Workplace
20.3 VIM Invoice Workplace

You can implement the following extensions to the VIM Invoice Workplace:
• “Adding custom selection screens to the VIM Invoice Workplace classic selection
pane” on page 347
• “Adding custom smart selections to the VIM Invoice Workplace smart selection
pane” on page 353
• “Adding custom output list fields to the VIM Invoice Workplace output list”
on page 355
• “Exit function module templates for VIM Invoice Workplace extensions”
on page 356
Note: Implementing VIM Invoice Workplace extensions has the following

accessibility limitations:
• When navigating on the My Pending and My Completed tab using the

arrow keys, the focus of the pointer remains on the tab and does not jump to
the 1st input field, as expected.
• When executing a work item, and returning to VIM Invoice Workplace, the
focus of the pointer jumps to the 1st input field of the selection screen, not to
the next work item in the grid, as expected.
20.3.1 Adding custom selection screens to the VIM Invoice

Workplace classic selection pane
The VIM Invoice Workplace classic selection pane allows you to add custom
selection screens. Perform the following steps:
• “Creating a custom function group” on page 348

• “Defining custom selection subscreens” on page 348
• “Creating custom selection subscreen synchronization functions” on page 351
• “Enhancing the standard data selection” on page 352
• “Adjusting the VIM Invoice Workplace customizing profiles” on page 353

20.3.1.1 Creating a custom function group

In your corresponding Z or partner namespace, you must create a custom function
group without any objects.
This function group acts as a “dummy” function group. Its only purpose is to allow
easy maintenance of selection texts for any custom select options or parameters
without modifying the VIM standard product components.
After you have created the new function group, add the following coding to its top
include.
Note: This action accesses some important global data declarations used by the
VIM Invoice Workplace selection pane.
INCLUDE /opt/vim_pmc_ui_compdata.
INCLUDE /opt/vim_pmc_ui_seldata.
INCLUDE /opt/lvim_pmc_ui_compsel.
20.3.1.2 Defining custom selection subscreens

In this step, you define custom selection subscreens, which appear in the VIM
Invoice Workplace classic selection pane.
Navigate to the top include of your function group and define the custom selection
subscreens between the two include statements:
Important
The location between the two include statements is technically important.
INCLUDE /opt/vim_pmc_ui_compdata.
INCLUDE /opt/vim_pmc_ui_seldata.
***** add your custom selection screen coding here*****
INCLUDE /opt/lvim_pmc_ui_compsel.
Note: You can define the custom selection subscreens in the same way as all
standard-delivered screen definitions already available in the include /opt/
lvim_pmc_ui_compsel. However, to avoid future conflicts that may be caused
by service packs, all custom selection subscreens must be defined using a 9*
screen number range. If new selection fields are not available in the structure /
OPT/CPMC_SELECTION_FIELDS_ST, you can add them by an append structure.
In general, you can use all other structures or tables as data reference by
adding them to the top include using a TABLES statement.
Arranging the horizontal classic selection pane

The VIM Invoice Workplace horizontal classic selection pane offers the following
frame screens to which you can add custom selection subscreens.

Frame screen 1001

This frame screen offers three predefined areas (left, middle, and right) for fixed
positioning of custom selection subscreens or fields.
Frame screen 1003
Empty horizontal screen which allows completely free positioning of custom
selection subscreens or fields.
Figure 20-1: Horizontal classic selection pane frame screens
If you want to use, for example, the selection pane frame screen 1003 instead of 1001,
run the /n/OPT/SPRO transaction and navigate to Cross Component Configuration
> VIM Invoice Workplace >Maintain Customizing Profiles > General Profile
Settings. For more information, see Section 16.3.2 “Maintaining general profile
settings” in OpenText Vendor Invoice Management for SAP Solutions - Configuration

Arranging the vertical classic selection pane

The VIM Invoice Workplace vertical classic selection pane offers the following frame
screen.
Frame Screen 1002

Empty vertical screen which allows completely free positioning of custom
selection subscreens or fields.
Figure 20-2: Vertical classic selection pane frame screen

Prefix naming convention

To ensure automatic data synchronization between the different subscreen
arrangements, any custom select option or parameter must follow a special prefix
naming convention depending on the selection tab and the selection pane
arrangement.
Prefixes for horizontal classic selection pane selection options
Inbox Tab
H1*
Pending Tab
H2*
Completed Tab
H3*
Prefixes for vertical classic selection pane selection options
Inbox Tab
V1*
Pending Tab
V2*
Completed Tab
V3*
20.3.1.3 Creating custom selection subscreen synchronization functions

The prefix naming convention for selection options (see “Prefix naming convention”
on page 351) ensures an automatic synchronization between horizontally and
vertically arranged selection panes. It also ensures an automatic reset of selection
fields and automatic locking of activated selection options.
To activate the automatisms for custom selection screens:
1. Copy the following function modules to your own function group within the Z*
or partner namespace.
• /OPT/C_PMC_SEL_OPTIONS_SYNC
• /OPT/C_PMC_SEL_OPTIONS_RESET
• /OPT/C_PMC_SEL_PANE_LOCK_GET
2. Maintain the function modules in the corresponding customizing profile(s).

20.3.1.4 Enhancing the standard data selection

All data selections are performed by the function module /OPT/C_PMC_DATA_GET_
PROC_RFC, which also automatically receives the entered values of custom selection
fields.
The function module provides multiple enhancement points to add custom logic
without the need to copy the whole function module.
To enhance the technical database selection by the custom selection fields:
1. Define local selection ranges for your custom selection fields.

*
===========================================================================
===========
* add custom selection ranges using this enhancement point
ENHANCEMENT-POINT /opt/ep_vim_pmc_get_proc_data SPOTS /opt/
es_vim_pmc_get_proc_fm STATIC .
*
===========================================================================
===========
2. Add custom authority checks.

*
===========================================================================
===========
* add custom authority checks using this enhancement point
ENHANCEMENT-POINT /opt/ep_vim_pmc_get_proc_auth SPOTS /opt/
es_vim_pmc_get_proc_fm.
*
===========================================================================
===========
3. Map custom selection fields to the local selection ranges.

*
===========================================================================
===========
* map custom selection field criteria using this enhancement point
ENHANCEMENT-POINT /opt/ep_vim_pmc_get_proc_map SPOTS /opt/
*
===========================================================================
===========
4. Enhance the database selections for all selection tabs (Inbox, Pending, and
Completed) with your custom selection ranges.
Inbox
ENHANCEMENT-SECTION /opt/ec_vim_pmc_get_proc_inbx SPOTS /opt/
Pending
ENHANCEMENT-SECTION /opt/ec_vim_pmc_get_proc_pend SPOTS /opt/

Completed
ENHANCEMENT-SECTION/opt/ec_vim_pmc_get_proc_compl SPOTS /opt/
5. Optional Enrich the output data if required.

*
===========================================================================
===========
* enrich selected process data using this enhancement point
ENHANCEMENT-POINT /opt/ep_vim_pmc_get_proc_enrch SPOTS /opt/
*
===========================================================================
===========
20.3.1.5 Adjusting the VIM Invoice Workplace customizing profiles

You must finally activate your custom selection subscreens. Therefore, you adjust
the general settings of all corresponding VIM Invoice Workplace customizing
profiles.
To adjust customizing profiles:
1. Run the /n/OPT/SPRO transaction and navigate to Cross Component

Configuration > VIM Invoice Workplace > Maintain Customizing Profiles >
General Profile Settings.
2. Enter your custom selection subscreens in the corresponding horizontal or

vertical selection-tab subscreen fields.
20.3.2 Adding custom smart selections to the VIM Invoice

Workplace smart selection pane
The VIM Invoice Workplace smart selection pane allows you adding custom smart
selection criteria and dependent restrictions.
Perform the following configuration steps:
1. Creating a custom smart selection class implementation

2. Defining a custom smart selection in the VIM Invoice Workplace customizing
3. Running the check result evaluation program

20.3.2.1 Creating a custom smart selection class implementation

Every smart selection is based on a class implementation that contains the selection
criteria and restriction check logic.
To create a custom smart selection class implementation:
1. Create a custom ABAP class with superclass /OPT/CL_C_PMC_BS.
2. Redefine the method CHECK_BS_GROUP and add your custom selection criteria
and restriction check logic.
3. Redefine the method CUSTOM_SUB_GROUPS_GET if the dependent restrictions

cannot be defined using the standard smart selection definition customizing
and therefore need to be defined in a different way.
Note: When creating custom logic for the selection criteria and restriction
check within the redefined method CHECK_BS_GROUP, keep the following in
mind: Each check run can only result in exactly one combination of selection
criteria and depending restriction at the same time. If a selection criteria/
restriction combination is valid, return this combination. If no combination is
valid, simply do not return any combination. If a selection criteria has no
depending restrictions, only the selection criteria has to be returned if it is
valid.
20.3.2.2 Defining a custom smart selection in the VIM Invoice Workplace

customizing
You must define every custom smart selection in the corresponding VIM Invoice
Workplace customizing.
To define a custom smart selection:

Management Invoice Solution > Cross Component Configuration > VIM
Invoice Workplace > Define Smart Selections.
2. Configure a suitable custom smart selection and assign your custom class
implementation, which contains the selection criteria and restriction check logic.
3. Configure the selection pane assignments accordingly.
Note: You can use the constant value field on selection restriction level to set
any constant values that are used during the check logic execution. The
constant values may be object to change from time to time (for example,
settings depending on number of days). Therefore they may be difficult to
handle if they are hardcoded in the custom class implementation logic.

20.3.2.3 Running the check result evaluation program

After defining new custom smart selections, you must run the check result
evaluation program /OPT/CR_PMC_BS_CHECK. Run it once for the newly defined
selection criteria to get the initial result registrations. If the initial check run is not
performed, the smart selection will not return any hits in the VIM Invoice Workplace
for older processes that have been started before the initial check run.
20.3.3 Adding custom output list fields to the VIM Invoice

Workplace output list
Apart from custom selection screens, the VIM Invoice Workplace also allows adding
custom output fields to the standard output list. To add custom output fields, you
must perform the following actions.
Appending custom fields to the standard output structure

You must append any custom output fields to the standard VIM Invoice Workplace
output structure /OPT/CPMC_OUTPUT_PROCESS_ST. For this purpose, use a custom
append structure.
Maintaining output field list settings

After you have appended the custom fields to the output structure, you must
maintain the output field list settings depending on the selection tab (Inbox,
Pending, and Completed). For more information, see Section 16.3.3 “Maintaining
output list field settings” in OpenText Vendor Invoice Management for SAP Solutions -
(Optional) Enhancing the output list data

Your custom selection fields might not be populated directly by the database select
and they might need further logic to be filled. In this case, you can use the following
enhancement point of function /OPT/C_PMC_DATA_GET_PROC_RFC to fill the
necessary information:
*
===============================================================================
===========
* enrich selected process data using this enhancement point
ENHANCEMENT-POINT /opt/ep_vim_pmc_get_proc_enrch SPOTS /opt/
*
===============================================================================
===========

20.3.4 Exit function module templates for VIM Invoice

Workplace extensions
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
Invoice Workplace.
Exit function templates - overview
/OPT/C_PMC_EXIT_TEMPL_BUTTON
Purpose
Allows to skip the creation of an action button during runtime.
Customizing table usage
/OPT/CT_PMC_BTN-BTN_EXIT
Source code call
Class method:
/OPT/CL_C_PMC_UI_ALV=>EXT_TOOLBAR_BUTTONS_GET
/OPT/C_PMC_EXIT_TEMPL_ICON
Purpose
Allows to influence the icon properties during runtime.
/OPT/CT_PMC_OUT-OUTPUT_ICON_EXIT
Source code call
Class method:
/OPT/CL_C_PMC_UI_ALV->ICONS_SET
/OPT/C_PMC_EXIT_TEMPL_FLD_STAT
Purpose
Allows to influence the properties of an output list field during runtime.
/OPT/CT_PMC_OUT-OUTPUT_STAT_EXIT
Source code call
Class method:
/OPT/CL_C_PMC_UI_ALV->FIELDCATALOG_SET
/OPT/C_PMC_EXIT_TEMPL_PRE_ACT
Purpose
Runs before the action logic of a button or icon action is executed. In case of
multiple backend, 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/CT_PMC_OUT-OUTPUT_PREACT_FM
/OPT/CT_PMC_BTN-BTN_ACT_PRE_FM
Source code call

Local system level function module:
/OPT/C_PMC_ACTION_EXECUTE_RFC
Backend system level class method:
/OPT/CL_C_PMC_ACT_CONTROLLER->DISPATCH_ACTION_EXECUTE
/OPT/C_PMC_EXIT_TEMPL_ACT_EXE
Purpose
Executes the action logic of a button or an icon action.

/OPT/CT_PMC_BTN-BTN_ACT_EXE_FM
/OPT/CT_PMC_OUT-OUTPUT_ACTION_FM
Source code call

Class method:
/OPT/CL_C_PMC_ACT_HANDLER->ACT_CUSTOM_EXECUTE
/OPT/C_PMC_EXIT_TEMPL_PROC_RFC
Purpose
Executes the data selection directly on each involved backend system.

/OPT/CT_PMC_CUST-DATA_SEL_FM_RFC
Source code call

Class method:
/OPT/CL_C_PMC_DATA_SOURCE->DATA_SELECTION_PROCESS
/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.

/OPT/CT_PMC_CUST-DATA_SET_DISC_FM
Source code call

Function module:
/OPT/C_PMC_DATA_GET_PROC_RFC

20.4 VIM indexing screen

You can customize existing index fields of the indexing screen (DP Dashboard). The
procedure differs for header fields and line item fields. For more information, see
Section 9.1.5 “Configuring the index header” in OpenText Vendor Invoice Management
for SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD) and Section
9.1.6 “Configuring the index item fields” in OpenText Vendor Invoice Management for
If the existing index fields are not sufficient and custom fields are necessary, you can
define customer specific programs and subscreens, both for header and line item
fields, and assign them to DP document types. See the description for Header
Program/Header Subscreen and Item Program/Item Subscreen in Section 9.1.1
“Creating a new DP document type” in OpenText Vendor Invoice Management for SAP
Solutions - Configuration Guide for Invoice Solution (VIM-CGD). The procedure differs
for header fields and line item fields.
To create custom header or line item fields:
1. Create an Append Structure to the following standard structures:
• /OPT/VIM_1RDOC_DATA for customer specific header fields.

• /OPT/VIM_1RITEM_DATA for customer specific line item fields.
Alternatively, reuse one of the existing custom fields (see “Custom fields”
on page 346).
2. Copy function module /OPT/C_IDX_SYNC_APPLICATION into your custom
function group.
3. Copy function module /OPT/C_IDX_SYNC_LABELS into your custom function
group.
4. Copy the wanted subscreen from program /OPT/SAPLVIM_IDX_UI (screen
1100-1500) into your custom function group.
5. Append the following existing includes from the function group /OPT/VIM_
IDX_UI into your custom function group:
INCLUDE /OPT/LVIM_IDX_UIDAT.
INCLUDE /OPT/LVIM_IDX_UIO01.
INCLUDE /OPT/LVIM_IDX_UII01.
INCLUDE /OPT/LVIM_IDX_UIF01.
INCLUDE /OPT/LVIM_IDX_UIF02.
6. Maintain function modules and the copied screens for the relevant document
types in the Document Type Configuration in the /OPT/SPRO transaction.
7. Manually add the new index fields to the program/Header Subscreen or
program/Item Subscreen.
Make sure to put FLD in the second group box. Otherwise, the new index fields
are not automatically set to read-only in Display mode. See the following
screenshot.

20.4. VIM indexing screen
8. Add the new fields into the field lists of your document types in the document
type configuration in the /OPT/SPRO transaction. Set their attributes as needed.
9. Adjust the corresponding BDCs and/or process options to work with the new
fields.
For more information, see Section 9.8.1 “Using the BDC ID infrastructure” in
OpenText Vendor Invoice Management for SAP Solutions - Configuration Guide for
Invoice Solution (VIM-CGD)
Dynamic You can maintain dynamic columns that appear in the user’s inbox during work
columns item processing. See Section 9.12.5 “Maintaining dynamic columns” in OpenText
(VIM-CGD).

20.5 Notifications program

You can add fields (columns) to the emails that are sent within the Notifications
program. In the Mail Configuration screen, create new entries. See Section 36.3.2
“Configuring the notification email body” in OpenText Vendor Invoice Management for
20.6 Invoice Approval

Header fields You can add header fields to the approval screen, in SAP GUI as well as in the
OpenText Approval Portal. These fields will be available in the section showing the
header data information. See Section 11.4.11 “Configuring fields for Invoice
Approval” in OpenText Vendor Invoice Management for SAP Solutions - Configuration
Line item You can add customer specific fields in the line item section of the coding screen in
section the approval process. This applies to OpenText Approval Portal (Approval Portal)
and to SAP GUI Approval. The purpose is to activate additional coding fields for
parked NPO / DP NPO documents in the approval process.
Users process the approval or coding step in the approval screen in SAP GUI or in
the Approval Portal. Both the approval screen in SAP GUI and in the Approval
Portal provide a limited amount of fixed line item fields in the baseline delivery. In
the customizing, you can adjust these fields using the VIM Invoice Configuration (/
OPT/SPRO transaction).
The fields are limited and described with the structure /ORS/INVOICE_ACCT_DATA.
The following sections describe how you can add coding fields within the approval
processing.
20.6.1 Changing an existing field and adding a new field

This section describes how you can reuse a custom field to provide an “own” coding
field.
To customize the coding screen, you must configure fields for the invoice detail page
and define the coding fields. To do this, use the following customizing:

Management Invoice Solution > Invoice Approval Configuration > User
Experience > Invoice Detail Configuration > Maintain Invoice Detail Fields.

Management Invoice Solution > Invoice Approval Configuration > Financial
Processing > Coding Configuration > Maintain Coding Fields Mapping.
In the customizing, the following ways are available to change an existing field or
add a new field:

20.6. Invoice Approval
• Choose an existing unused field, which you want to reuse with different
information.
• Add a new field to the structures /ORS/INVOICE_ACCT_DATA and /OPT/A_
INVOICE_ACCT_ST.
• Create a new append in the structures /ORS/INVOICE_ACCT_DATA and /OPT/A_

INVOICE_ACCT_ST with your customer specific fields.
See also Section 11.4.11.1 “Configuring fields for the invoice detail page” in OpenText
(VIM-CGD).
20.6.2 Using additional fields in the COA for level based

approval
You can build the line based approval logic on custom fields that are made available
in the invoice line items, as described in “Changing an existing field and adding a
new field” on page 360. The fields must be already present, with the same field
names, in the line item structures of the invoice. Take the structure /OPT/A_
INVOICE_ACCT_ST for reference.
To enable new fields for COA logic:
1. Add new fields into the structures /OPT/A_COA_FIELDS_ST and /OPT/BL_

4RCOA_DATA using append structures. The field names used in both structures
must match.
2. Add the new fields into the COA field list in the view /OPT/BL_T401V as line
item fields.
3. Configure a mapping between the invoice fields and the COA fields in VIM
customizing for Invoice Details Fields and in the Coding fields mapping for
the respective AFS IDs. See the following paths to the customizing.
• Run the /n/OPT/SPRO transaction and navigate to OpenText Vendor

Invoice Management Invoice Solution > Invoice Approval Configuration>
User Experience> Invoice Detail Configuration> Maintain Invoice Detail
Fields.
• Run the /n/OPT/SPRO transaction and navigate to OpenText Vendor
Invoice Management Invoice Solution > Invoice Approval Configuration>
Financial Processing> Coding Configuration> Maintain Coding Fields
Mapping.

20.6.3 Changing the invoice class

VIM 7.0 introduced level based approval. The custom invoice class is now
configured in the approval flow settings (AFS); see Section 11.4.4 “Configuring
approval flow settings” in OpenText Vendor Invoice Management for SAP Solutions -
20.6.4 Changing BDC IDs

DP related The document might be related to a DP process and the field that is required by your
document process might not be provided in the standard document header and item
structures. In this case, you must create an append structure with the new field, as
described in “VIM indexing screen” on page 358.
To pass the field to the SAP accounting document, you must adjust the
corresponding BDC ID definitions. You may need to create your own posting
function or change the definition of batch input.
20.6.5 Creating custom search help

You can create a search help for the new field. The search help can be used on the
Approval Portal. For details, see Section 11.4.12 “Configuring search help for web
and SAP GUI approval screen fields” in OpenText Vendor Invoice Management for SAP
20.7 VIM Analytics

• As soon as you select a report variant that is hiding selection fields, the button
is displayed. Click it to also show the hidden fields. For more information, see
Section 3.2 “Using the selection screen” in OpenText Vendor Invoice Management
for SAP Solutions - Reference Guide for Invoice Solution (VIM-RGD).
• You can add additional custom fields to be considered at the selection of
invoices. For more information, see Section 14.5.1 “Adding custom fields in the
selection screen” in OpenText Vendor Invoice Management for SAP Solutions -
20.8 New VIM Analytics ABAP CDS views

This section demonstrates how to make changes to the ABAP CDS views provided
in VIM 7.5 for the new VIM Analytics (VAN) report, optimized for SAP® HANA.
The description focuses on how to add new fields to the ABAP CDS views.

20.8. New VIM Analytics ABAP CDS views
20.8.1 ABAP CDS Views for VAN

The following list shows the ABAP CDS views that you need to enhance or
customize:
/OPT/VVA2_COMI
Common input fields (selection screen) for invoices in DP workflow, NPO
workflow, and PO workflow
/OPT/VVA2_COMO
Common output fields for invoices in DP workflow, NPO workflow, and PO
workflow
/OPT/VVA2_DPI
Input/selection fields exclusive to invoices that are in process in DP workflow
/OPT/VVA2_DPO
Output fields exclusive to invoices that are in process in DP workflow
/OPT/VVA2_NPOI
Input/selection fields exclusive to NPO invoices
/OPT/VVA2_NPOO
Output fields exclusive to NPO invoices
/OPT/VVA2_POI
Input/selection fields exclusive to PO invoices
/OPT/VVA2_POO
Output fields exclusive to PO invoices
The COMI and COMO views (called COM views in the following) perform an initial
selection for fields that are common for all VIM invoice types (DP, PO, and NPO).
These views then pass on the data to the individual DP, PO, and NPO views, which
are then called by the ABAP classes in SAP GUI to process the VAN report. To add
new fields to the selection screen or to the output screen, the COM views are first
updated with the new fields that you want to select or output. Then each of the
remaining views is updated as needed, making reference to the COM view fields.
Examples are given in the following.

20.8.2 Enhancing CDS views

To add new fields to the ABAP CDS views:
1. In Eclipse, create a new ABAP project. This project will point to the SAP
environment which you will work on.
Note: Each time you open the project workspace for the first time after
opening Eclipse, you are asked for your ID and password for the selected
project (SAP system). Until you close Eclipse, you can then open or close
the project without re-entering sign in information.
2. In the project, open the System Library to find both your custom objects
package and the standard OpenText package containing the ABAP CDS views
listed in “ABAP CDS Views for VAN” on page 363. For easier access, add these
to your Favorite Packages. The package containing the ABAP CDS Views to be
modified is /OPT/VIM_CDS. ABAP CDS views are listed under Core Data
Services > Data Definitions.

3. In your own package, create eight new ABAP CDS views, one for each of the
listed baseline ABAP CDS Views.
a. Right-click your package, then click New > Other ABAP Repository
Object.
b. In the New ABAP Repository Object dialog box, enter DDL in the filter field
to get the single result DDL Source.
c. Create new CDS views only in a local or customer package. Enter a name
and a description for your object, then select a transport.

d. In the New DDL Source window, choose a pre-existing template. For this
overall scenario, choose the Extend View template.
4. For each of the eight baseline ABAP CDS views, replace the @AbapCatalog.
sqlViewAppendName: with the name of your choice.
This name is used in SAP GUI to render the CDS Append View in a format
similar to an ABAP table view or structure.
Also, replace the EndUserText.label with the text description of your choice,
and add the corresponding baseline view name next to the EXTEND VIEW
statement for the view that you are enhancing.
5. Enter the additional field(s) that you want to either use as a selection (for input
views) or as report output (for output views) in between the curly brackets
provided by the template. For enhancing the COM views, give the field an alias.
This alias will be used in the VIM configuration to perform the mapping
between ABAP CDS fields and system fields. Take care to also use the table
aliases predefined in the view.
Note: One limitation of ABAP CDS enhancement views is that you cannot
select from additional tables that are not defined in the existing standard
views. In this case, you need to create new custom views.
6. After extending the COM views, extend the DP, PO, and NPO views to add the
aliased fields from the COM views.
This completes the steps in ABAP CDS.

Because you are using the standard views, no additional implicit enhancements
are required on the SAP GUI ABAP side to replace the view names with the
names of the extension views.
After you complete these steps, plus all the various steps described in Section 14
“VIM Analytics” in OpenText Vendor Invoice Management for SAP Solutions -

Configuration Guide for Invoice Solution (VIM-CGD), the extensions to VAN should
work.

Chapter 21
Using the metadata interface of the Inbound
Configuration
21.1 Overview
The metadata interface of the Inbound Configuration is used to populate values
from VIM to the ICC extraction or to the ICC validation. All values for fields in the /
OTX/PF01_T_1REG table can be transported.
The following conditions apply:
• The field value must not be empty.
For more information about ICC, see OpenText Business Center Capture for SAP
21.2 Functional description

The interface is called when the Inbound Configuration selects a document to be
extracted or validated. It works the following way:
1. All fields in /OTX/PF01_T_1REG are considered.

2. An entry is generated at the metadata interface for every mapping entry found.
The interface entries will have the external field name of the mapping entry as
field name and the field value as value.
3. ICC turns these entries into annotations in the datapool.
21.3 Example
Example 21-1, “Metadata interface” shows the annotation section in the datapool of
the ICC application. Most of the annotations are generated by the metadata
interface.
Example 21-1: Metadata interface

<?xml version="1.0" encoding="utf-8"?>
<DOKuStar.Data baseType="documentType" state="Ok" confidence="0" version="4.0">
<annotations>
<annotation key="SAPLink.DocumentId">000000000127</annotation>
<annotation key="SAPLink.RetryNr">1</annotation>
<annotation key="SAPLink.DocumentType">
</annotation>
<annotation key="SAPLink.DocumentUri">http://hunabku.opentext.net:8080/archive?
get&pVersion=0045&contRep=Y4&docId=0050568716C71ED5BDFBC8878AF92F5F</
annotation>
<annotation key="SAPLink.InputUri">

Chapter 21 Using the metadata interface of the Inbound Configuration
</annotation>
<annotation key="SAPLink.OutputUri">http://hunabku.opentext.net:8080/archive?
create&pVersion=0045&contRep=Y4&docId=0050568716C71ED5BDFBD79EA9738F5F&co
mpId=data&docProt=crud</annotation>
<annotation key="ARCHIV_ID">Y4</annotation>
<annotation key="ARCHIV_ID_XML">Y4</annotation>
<annotation key="ARC_DOC_ID">0050568716C71ED5BDFBC8878AF92F5F</annotation>
<annotation key="ARC_DOC_ID_XML">0050568716C71ED5BDFBD79EA9738F5F</annotation>
<annotation key="AR_OBJECT">ZICC_US_P</annotation>
<annotation key="CHANNEL_ID">ICC</annotation>
<annotation key="CLASSIFY">PS03_VIM_INVC</annotation>
<annotation key="EXT_RETRY">1</annotation>
<annotation key="HANDLE_ID">CAPTURE</annotation>
<annotation key="LAST_MODU_ID">EXTR_REG</annotation>
<annotation key="MANDT">800</annotation>
<annotation key="NOTE">ZICC_US_P PDF</annotation>
<annotation key="REGID">000000000127</annotation>
<annotation key="STATUS">072</annotation>
<annotation key="TSP_CHANGE">20160401075201</annotation>
<annotation key="TSP_REGISTER">20160401074951</annotation>
<annotation key="Sitemap">\\ICC-DEMO-02\DOKuStarDispatchData\config\RdaProject
\JobClass6_Steps\Recognition\JobClass6_Recognition.sitemap</annotation>
<annotation key="ConnectorGuid">25d431d2-0c60-4733-973e-d6014d80f16f</annotation>
<annotation key="ConnectorName">SAP Extraction Link</annotation>
<annotation key="ConnectorInstanceName">US</annotation>
<annotation key="Filename">SAPLink(Extraction, DocumentId=000000000127,
ActivityRetryNr=1)_0fdfa4b7-f055-4bf4-8ad5-09497b74a995</annotation>
<annotation key="JobClass">JobClass6</annotation>
<annotation key="Cache">C:\Windows\TEMP\DOKuStar Professional\3.0\Cache
\JobClass6_Recognition\c2c70eec-f0ae-4808-82d6-a6893aaa631b</annotation>
<annotation key="Scripting">Indexing</annotation>
</annotations>

Chapter 22
Invoice Approval: A typical flow example
Within a department, you are implementing the coding of Non PO invoices by the
AP team. There are two levels of approval, with separate responsibilities for
different cost centers at the first level. The first approval level is able to approve lines
with the maximum amount of 5,000 Euro. The second approval level can approve up
to 50,000 Euro.
Note: Both amounts are not meant as individual line amounts but as sums of
line item amounts grouped for each approver (“pack amounts” ).
Basic settings You use the following cost centers: 1100 and 1101 for purchasing, and 2200 for
production.
The coding is performed by users CODER1 and CODER2. Both of them are able to
approve the coding for any of the cost centers listed above.
Goods and services are requested by users EMPLOYEE1, EMPLOYEE2, and

EMPLOYEE3.
The first level approvers are APPR_PUR for the purchasing cost centers, and
APPR_PRD for the production cost center.
The second level approvers are APPR_MGR1 and APPR_MGR2.
As an exceptional situation, an invoice with the grouped lines amount higher than
50,000 Euro might be received. To handle this exception, maintain the fallback user
APPR_ADM for the AFS ID to be used.
The coder determination is set to By company code.
For more information about the fallback user and coder determination, see Section
11.4.4 “Configuring approval flow settings” in OpenText Vendor Invoice Management
for SAP Solutions - Configuration Guide for Invoice Solution (VIM-CGD).
COA settings
Configure the following setup in the COA maintenance:
For more information about the settings in the COA, see Section 4.1.4 “Maintaining
Chart of Authority” in OpenText Vendor Invoice Management for SAP Solutions -
User Details tab

Enter all users mentioned above who are participating in the approval process.

Chapter 22 Invoice Approval: A typical flow example
Approval Limit/Level tab

Set up the following levels for the corresponding company code:
• Coder level with the limit 0

• Requester level with the limit 0
• Approval level 1 with the limit 5,000 Euro
• Approval level 2 with the limit 50,000 Euro
Enter the expense type as * - All.

COA Details, Coder/Requester Details tab
For the coder level, enter coders: CODER1 and CODER2, with cost center *.
For the requester level, enter requesters: EMPLOYEE1, EMPLOYEE2, and
EMPLOYEE3, with cost center *.
COA Details, Approver details tab
For approval level 1, enter APPR_PUR with cost center 1100 and 1101, and
APPR_PRD with cost center 2200.
For approval level 2, enter APPR_MGR1 and APPR_MGR2, both with cost
center *.
Note: Internally (and often shown in the documentation), the coder level is
level 0, the requester level is level 1, the first approval level is level 2, and
the second approval level is level 3.
Coder Settings tab
Maintain CODER1 and CODER2 for the company code.
Invoice flow With the setup described above, all invoices are first sent to CODER1 (the first in the
list, sorted alphabetically). The first coder can enter the accounting information or
forward the invoice to CODER2.
After coders have finished entering the accounting data, the invoice is sent to the
respective requester. The requester reviews the invoice and can approve it, thus
passing the invoice to the approvers in the approval level 1.
Note: At this point, if sequential approval flow is used, the invoice is sent to
one of the approvers. If parallel approval flow is used, the invoice is sent to
both approvers simultaneously.
After both first level approvers have approved the invoice, it is sent to APPR_MGR1.
If the total amount on all lines does not exceed 50,000 Euro, APPR_MGR1 can finally
approve the invoice. After this, the invoice typically returns into the DP workflow
and is posted automatically, or reviewed by other departments or processors.
Example 22-1: Example invoice
Header amount is 15,000 Euro (Zero tax rate is used).

Line 1 Cost center 1100, amount 4,000 Euro. This line has to be approved by
APPR_PUR, no final approval at the first approval level.
APPR_PUR, no final approval at the first approval level.
APPR_PRD, no final approval at the first approval level.
Both sums of line item amounts per approver (“pack amounts”) exceed 5,000
Euro. Therefore, the invoice is sent to the second approval level to
APPR_MGR1.

Part 3
Simple Mode VIM - scenarios
Part 3 Simple Mode VIM - scenarios
Important
With VIM 20.4 SPS1, Simple Mode is deprecated. It is not supported for
productive installations. Please use Classic Mode.
Simple Mode provides a new invoice process designed according to SAP S/4HANA
standard and concepts like simplification, principle-of-one, digitalization, cloud-
first, and a new user experience from the start.

Chapter 23
Invoice processing in Simple Mode
While the “Classic Mode” provides different options, the Simple Mode philosophy is
about a uniform best practice approach based on different invoices types:
• Invoices that can be automated by their nature and structure

• Invoices that can be automated with limited manual processing
• Invoices that need manual processing and may use very specific features of
SAP’s invoice app
Simple mode features
• Runs with a minimum of configuration based on predelivered best practices

settings.
• Limited classical customizing: done on development system and transported into
QA and PROD system.
• Use of SAP invoice drafts to store preliminary invoice data, instead of separate
business object and header and line items tables of classic mode.
• Built around SAP’s Fiori app “Manage Supplier Invoices”.
• End-to-end Fiori.
• Cloud OCR extraction and OpenText Capture add-ons.
• Advanced machine learning features to optimize data capture (feedback from
SAP process and SAP posting to data recognition).
• More “smart” and self-adapting features like intelligent coding defaults, dynamic
auto-classification of vendors into black, grey, and white list, and others.
Processing invoices through simple mode
1. Capture of scanned paper invoices and PDF invoices through OCR cloud service
with automated optimization through constant feedback.
2. Background
Initial classification of incoming invoice data to control process and flow. This
happens in background. Separation in invoices going through automation and
invoices that need manual intervention.
3. Automation
Applying automation logic and check of business rules for invoices. This leads to
auto-post if there is no exception.

Chapter 23 Invoice processing in Simple Mode
4. Fiori Validation App

An Accounts Payable user processes invoices that need manual intervention in a
Fiori app:
a. Contains main header and line item fields.
b. Display of scanned/uploaded invoice.
5. Background
Similar to 3 on page 377: Background logic is applied to invoices that have been
manually indexed through the Fiori app and auto-posted if there is no exception.
6. Fiori Process app: Exception handling

AP and other roles get work item tasks to handle invoices that run into
exceptions or need coding and approval. Invoices can be manually posted by
navigating from the VIM Fiori apps to SAP’s Fiori app Manage Supplier
Invoices.
The Fiori Process app provides the option to switch to SAP Fiori app Manage
Supplier Invoices for invoices that need complex input, this means that fields are
not available in VIM and cannot be treated by automation.
7. VIM Enter Cost Assignment Fiori app

The accountant can send invoices for cost assignment. The coder assigns invoice
amounts to different cost objects. The invoice draft is updated accordingly.
8. VIM Approve Invoices Fiori app

The accountant can send invoice drafts for Fiori approval to any user that is
assigned to the approval role.
23.1 Validation
The validation step in the Fiori Validation App is an optional step to enrich the data
delivered by the inbound channels. In the case of OCR input, this step might not be
needed because the Validation Client of the OCR is already used.
Based on the configured exceptions, the validation step is triggered if any of these
exceptions occurs.
You can configure the exceptions in the VIM Foundation Process Configuration (/
OTX/PF00_IMG), profile PS08_BCF_INV, process step VALIDATE for several
characteristics (countries). For more information, see Section 7.1.8 “Maintaining
process steps” in OpenText Vendor Invoice Management for SAP Solutions -
Configuration Guide for Foundation (BOCP-CGD). You can enhance the standard
configuration according to your needs.
The accountant has several options to resolve exceptions, including sending the
invoice process to other users. The following options are available:

23.1. Validation
Send mail
Sends a standard email. The invoice can be attached. The invoice process stays
in the inbox of the accountant.
Inquiry
Sends a question (as process step) to any user. The invoice process is sent to the
selected user. The accountant can see the process in the Outstanding tab.
Submit
The validation process is finished. All remaining exceptions are bypassed. An
invoice draft is created in the background. The invoice is forwarded to the
process step if process exceptions are occurring.
Return to vendor
Sends an email to the supplier. The process is obsoleted afterwards.
Set to obsolete
The workflow is finished in status obsolete.
Capture Validation
The Capture Validation button opens the validation screen in Capture Mode.
Values from the invoice can be captured directly from the invoice image.
Enrich Data
Missing data can be automatically determined based on the configured
enrichments. Currently, the following enrichments are configured as default:
• Determination of Credit/Debit Memo Indicator in the line items based on the

Header Invoice Type
• Determination of the SAP Quanity Unit based on the Quantity Unit captured
from the Image (this means: Pieces --> PCS).
Simulate
The Simulate action calls the Simulation Screen where business exceptions can
be bypassed or activated.
Table 23-1: Validation rules
Key Name Description

HEAD_DUPL Invoice reference This rule is doing a duplicate check based on
and date invoice reference and date on the invoice process
table (/OTX/PS08_T_PLH)
Note: In the exception process, another

duplicate check is done against parked/
posted SAP documents.


MANDATORY Additional This rule checks for fields defined as mandatory
mandatory in the Fiori validation screen customizing.
information
(Transaction /OTX/PF00_IMG > Data Binding >
Workobject Type: PS08_VAL_INV_HD and
perspective ID item: PS08_INVOICE_VALID_
ADV)
HEAD_BLDAT Date of issue This rule checks if the document date is available.
HEAD_XBLNR Unique number This rule checks if the document date is available.
identifying the
invoice
HEAD_MWSKZ VAT rate This rule checks if the tax rates were recognized
correctly.
HEAD_MMWBR VAT amount This rule checks if the tax amounts were
payable recognized correctly.
HEAD_BALAN Balance This rule checks if the sum of recognized tax and
net amounts is matching the gross amount.
HEAD_CMEMO Credit memo This rule checks if a credit memo was recognized.
HEAD_AGE Invoice age This rule checks if the invoice is older than
allowed, based on the company code
customizing. See Section 41.4.2 “Company code
settings” in OpenText Vendor Invoice Management
for SAP Solutions - Configuration Guide for Invoice
Solution (VIM-CGD).
HEAD_NPO Non PO invoice This rule checks if the vendor is marked for
allowed purchase order based invoices only in the vendor
customizing. See Section 41.4.3 “Supplier
settings” in OpenText Vendor Invoice Management
Solution (VIM-CGD). If an invoice without
purchase order was recognized, this rule will be
active.
HEAD_UNPLD Unplanned If unplanned costs are recognized, this rule
delivery costs checks if the vendor is allowed to send invoices
with unplanned costs. This setting is done in the
vendor specific customizing. See Section 41.4.3
“Supplier settings” in OpenText Vendor Invoice
Management for SAP Solutions - Configuration
HEAD_VATIS VAT ID supplier This rule checks the recognized tax number
against the tax numbers in the supplier master
data, OCR fields ExtractionResult-
VendorTaxNumber and
TaxNumberCandidates.

23.2. Exception handling

HEAD_DELDA Date of transaction This rule checks if the delivery date is recognized
or payment in the invoice (OCR field ExtractionResult-
InvoiceDeliveryDate).
ITEM_GOODS Description of This rule checks if items or PO numbers were
goods and services recognized.
invoiced
HEAD_ADDRS Visual check: This rule can be used for statistical sample checks
supplier address to verify the supplier address according to the
invoice profile setting. See Section 41.4.7 “Invoice
profile” in OpenText Vendor Invoice Management
Solution (VIM-CGD).
HEAD_ADDRR Visual check: This rule can be used for statistical sample checks
recipient address to verify the recipient address according to the
invoice profile setting. See Section 41.4.7 “Invoice
profile” in OpenText Vendor Invoice Management
Solution (VIM-CGD).
HEAD_VATBR Visual check: This rule checks if mutliple tax rates were
breakdown of VAT recognized.
amount
23.2 Exception handling

After the invoice draft is created, the business rules defined in the exception
handling are run. The rules need to be resolved, using one of the following ways:
• Changing the invoice draft with the Manage Supplier Invoice app
• Bypassing
The default configuration contains checking for duplicates, approval of invoices

before and after posting, handling of blocked invoices and checks for specific fields
and countries.
You can configure the exceptions in the VIM Foundation Process Configuration (/
OTX/PF00_IMG), profile PS08_BCF_INV, process step DRAFT_CHK1 for several
characteristics (countries). For more information, see Section 7.1.8 “Maintaining
process steps” in OpenText Vendor Invoice Management for SAP Solutions -
Configuration Guide for Foundation (BOCP-CGD). You can enhance the standard
configuration according to your needs.
The accountant has several options to resolve exceptions, including sending the
invoice process to other users. The following options are available:
Go to invoice
Edit the invoice in the Manage Supplier Invoice app.

Go to supplier
Open the vendor fact sheet.
Send mail
Send a standard email. The invoice can be attached. The invoice process stays in
the inbox of the accountant.
Inquiry
Send a question (as process step) to any user. The invoice process is sent to the
Refer
Send to a specific role: Buyer, Requester, or other accountant specialists.
Submit
The process is sent to background processing. If all exceptions are resolved, the
invoice is posted automatically. The invoice will return to the process step if any
exceptions are still not resolved.
Submit for coding

If the assignment to cost objects (cost center and so on) needs to be entered by
another user, send the process to the Enter Cost Assignment step.
Submit for approval

Send the invoice process to an approver.
Return to vendor
Send an email to the supplier. The process is obsoleted afterwards.
Set to obsolete
The workflow is finished in status obsolete.
If all exceptions are resolved or bypassed, the invoice can be posted. This can be
done either manually in the Manage Supplier Invoice app or by background posting
when submitting the process step. After posting, the exceptions are checked again,
for example if approvals are still missing or if the invoice is blocked.
After resolving these after-posting exceptions, the invoice process can be finished by
using the Submit option.
Table 23-2: Exception handling rules
No. Key Name Description

1 HEAD_ENBUK Company code This rule checks if the company code is
activation registered for simple mode processing. See
Section 41.4.2 “Company code settings” in
OpenText Vendor Invoice Management for SAP
Solutions - Configuration Guide for Invoice
Solution (VIM-CGD).

23.2. Exception handling

2 DUP_CHECK Duplicate check A duplicate check based on the standard
SAP duplicate check of Logistics Invoice
Verification (MM-IV_LIV) is run. For more
information, see Section 41.4.9 “Duplicate
check” in OpenText Vendor Invoice
Technical information
In the invoice header table, the field
DUP_STATUS is set to D.
3 HEAD_CURR Local currency of This rule checks for invoices where the
receiver currency differs from the currency of the
company code.
4 HEAD_VATEX VAT specified This rule checks if a proper tax code is
entered.
5 ITEM_POREL Release of purchase This rule checks if all purchase orders are
order released.
6 ITEM_POCUR Currency of This rule checks if the invoice currency is
purchase order matching the currency of the purchase
orders.
7 ITEM_ACKN Acknowledgment This rule checks for missing
of purchase order acknowledgments in the purchase orders.
8 HEAD_VAUD Supplier audit trail Vendor specific checks according to the
invoice profile setting. See Section 41.4.7
“Invoice profile” in OpenText Vendor Invoice
9 HEAD_AMT Invoice amount Amount based checks according to the
invoice profile setting. See Section 41.4.7
“Invoice profile” in OpenText Vendor Invoice


10 HEAD_NPOAP Non PO invoice The invoice needs an approval. If the
approval invoice has line items without reference to a
purchase order, this rule will be active. The
invoice needs to be sent to approval by the
accountant.
After the approval is finished, the rule is

inactive.
This rule cannot be bypassed in the default

configuration. To allow posting before the
approval, the accountant has to set a
payment block in the Manage Supplier
Invoice app. In this case, this rule will be
inactive and allows posting. After posting,
the rule Check for payment block is
active to handle the payment block, for
example by sending to subsequent
approval.
Technical information
In the invoice header table, the field
APPR_STATUS is set to A in case of
approval and to R in case of rejection.
For more information, see Section 41.4.1

“General settings” in OpenText Vendor
Invoice Management for SAP Solutions -
Configuration Guide for Invoice Solution (VIM-
CGD).
11 BLOCKED Check for payment This rule checks for the existence of a
block Logistic Invoice Verification block. If the
rule is active, the accountant has several
options to involve other roles to get a
payment authorization:
• Refer to buyer
• Refer to requester
• Send to approval
• Inquire
After authorization, the process will go

back to the accountant. In the Manage
Supplier Invoice app, the payment block
can be released based on this decision.
The rule can not be bypassed in the default

configuration and will be set to inactive as
soon as the invoice is released.

23.3. Enter cost assignment

12 REVERSED Invoice reversed If a posted invoice is rejected during
approval and was reversed by the
accountant, this rule will be active.
This rule cannot be bypassed in the default

configuration. The workflow can be
finished by running the action Set to
obsolete.
13 HEAD_TAXIN Tax invoice The text Tax Invoice was found on the
(country specific) invoice (OCR field ExtractionResult-
TaxInvoice).
14 HEAD_INV Check invoice (no This rule can be configured to generally
auto-posting; stop the workflow before auto-posting.
country specific)
15 HEAD_ESRPA ESR participant This rule checks if the EST participant
number number found by the OCR is matching the
ESR number of the supplier master (OCR
field ExtractionResult-ESRNumber).
16 HEAD_ESR ESR number valid This rule checks if the ESR number found
by the OCR is valid (OCR field
ExtractionResult-ESRNumber).
23.3 Enter cost assignment

The accountant sends an invoice to the coder to get information about the
distribution of cost objects, like Cost Center or WBS Elements.
This step is available for invoices without purchase order reference.
The coder gets the GL line items from the accountant. They can enter the cost
assignment to the supported cost objects. Lines provided by the accountant cannot
be deleted.
The coder can split existing lines and distribute the amounts to several cost objects.
Split lines can be deleted. In this case, the coder needs to restore the balance of the
original line.
The coder has several options to handle this step:
Go to supplier
Inquiry
Refer
Send to a specific role (for example accountant or other coders).

Confirm
Confirm the entered coding and send the process back to the accountant. The
invoice draft is updated in the background.
• If this update is successful, the invoice process is returned to the accountant

in the Process step.
• If the background update fails, the invoice process is returned to the

accountant in the Enter Cost Assignment step in display mode. The entered
cost assignment needs to be manually updated in the invoice draft using Go
To Invoice.
Reject
The process is set to Rejected and sent back to the accountant for further
processing.
Split coding
Line items provided by the accountant can be split up to several cost objects.
Add attachments
In the document section, the coder can add additional attachments to the invoice
process.
Check coding
Check the entered coding.
Note: The checks will only do some validation of the entered cost objects
as described in Section 41.5.3 “Configuring the Enter Cost Assignment
Simple app” in OpenText Vendor Invoice Management for SAP Solutions -
Configuration Guide for Invoice Solution (VIM-CGD). A full simulation of the
invoice posting is not performed.
Recommend Cost Assignment

On line item level, users can call the Cost Assignment Recommender dialog
box, which shows the Coding Proposals from Smart Coding. If multiple
proposals are selected, the line amounts will be split according to the number of
selected lines.
23.4 Approval
The accountant sends an invoice to approval to get the authorization for posting or
payment of the invoice. There may be several approval steps required. As standard,
a 4-eye based approval is necessary. For more information, see Section 41.4.1
“General settings” in OpenText Vendor Invoice Management for SAP Solutions -
This step is available for invoices without purchase order reference.
The following options are available:

23.4. Approval
Go to supplier
Inquiry
Refer
Send to a specific role, for example accountant or other coders.
Approve
Approve the entered coding.
• If all exceptions are resolved, the invoice is posted in the background and the
workflow is finished.
• If all exceptions are resolved and the invoice was already posted before the
approval, the payment block is removed in the background and the
workflow is finished.
• In case of remaining exceptions, the invoice process is returned to the
accountant in the Process Step.
Reject
The process is set to Rejected and sent back to the accountant for further
processing.

Glossary
AAK
See: SAP Add-On Assembly Kit (AAK)
After Image
Technical option to realize an delta upload from the source systems into the SAP
NetWeaver BW system. A data record loaded as After Image provides the status
of the record after it has been changed, or after data has been added.
Aging Report
Part of the Central Reporting infrastructure. The Aging Report reports about the
aging of documents and work items in the current system.
Application Component Hierarchy

Hierarchy of folders to structure DataSources in SAP NetWeaver BW.
Approval chart of authority (COA)

The Approval chart of authority (COA) determines first approver and next
approver for an invoice by combinations of Company Code (specific or range),
Expense Type (marketing expense, utility), Cost Objects (G/L account, Cost
Center), and HR objects (Position, Job code).
Approval Portal
VIM web interface for approving invoices.
Archive system
Computer system that enables storage, management and retrieval of archived
data and documents
ArchiveLink document types

Document types that need to be customized for ArchiveLink
ArchiveLink
Service integrated in the SAP NetWeaver Application Server ABAP for linking
archived documents and the application documents entered in the SAP ERP
system.
Authorization profiles
The SAP administrator assigns authorizations to the users that determine which
actions a user can perform in the SAP system. These authorizations are stored in
Authorization profiles.

Glossary
Automation Report
Tool that provides data about automated and manual processing steps of VIM
documents
BAdI
See: Business Add-Ins (BAdI)
BAPI®
SAP programming interface: Business Application Programming Interface
Baseline
Set of functionality with pre-defined configuration and the starting point to
implement VIM
BasisCube
See: InfoCube
BDC ID
Business Data Communication ID. The BDC ID is used by the system to process
an SAP transaction to create an SAP Document in user context.
Block
Situation where an invoice has a price or quantity variance that prevents invoice
from posting
BTE
See: Business Transaction Event (BTE)
Business Add-Ins (BAdI)

Business Add-Ins (BAdI) is an SAP enhancement technique based on ABAP
objects. BAdI can be inserted into the SAP system to accommodate user
requirements too specific to be included in the standard delivery.
Business Center Capture (BCC)

OpenText Business Center Capture for SAP Solutions. Component for use in VIM.
Automates the capture of paper invoices by using OCR to extract invoice data.
Business rules
Rules that describe the operations, definitions and constraints that apply to an
organization

Glossary
Business Transaction Event (BTE)

Event used for extending a Non PO invoice functionality to call a custom program
Central Audit Report

Part of the Central Reporting infrastructure. The Central Audit Report is a
slimmed VIM Analytics (VAN). The main difference to VAN is that the Central
Audit Report serves as a single point of access in a multiple backend scenario.
Central Reporting
Reporting infrastructure that provides several reports that enable you to measure
certain properties of VIM documents and their work items, in order to optimize
working with VIM. Central Reporting comprises the following individual reports:
Aging Report, Central Audit Report, Exception Analysis Report, Key Process Analytics
Report, Productivity Report, and Summary Report.
Characteristic
Type of InfoObject in SAP NetWeaver BW that represents descriptions of fields,
such as Vendor ID, Invoice Number, Unit of Measure, and Posting Date.
COA
See: Approval chart of authority (COA)
Coding
Coding allocates an invoice to G/L account and cost object if required.
Dashboard
User interface that organizes and presents information in a way that is easy to
read. Users can also perform actions from the dashboard.
Data Transfer Process (DTP)

Object in SAP NetWeaver BW to transfer data from source objects to target objects
Data View (View)

Dynamic part of a perspective. A set of views is shown in the template at specific
locations at runtime. For each perspective, you can define which view appears at
which location in its template. You can insert each view only once in each
perspective.
DataSource
Set of fields in SAP NetWeaver BW that provide the data for a business unit for
data transfer to the SAP NetWeaver BW system; technically, it contains an extract
structure and an extraction function module.
DataStore Object (DSO)

Storage location for consolidated and cleansed data in SAP NetWeaver BW

Glossary
DocuLink
OpenText™ DocuLink for SAP Solutions enables the archiving, management and
retrieval of SAP CRM or SAP S/4HANA documents from within the SAP
infrastructure.
Document Processing (DP)

VIM component that captures invoice metadata including line items for PO and
performs preconfigured business rules
Document type
Type of document such as PO, Non PO, OCR, Non OCR
DP
See: Document Processing (DP)
DSO
See: DataStore Object (DSO)
DTP
See: Data Transfer Process (DTP)
EDI
See: Electronic Data Interchange (EDI)
Electronic Data Interchange (EDI)

Method for transferring data between different application systems in the form of
messages. SAP applications support EDI with messages sent in an SAP
Intermediate Document (IDoc) format. VIM supports the creation of vendor
invoices through the EDI/IDoc interface.
Event Type Linkage

Error handling method. Event Type Linkage determines what the application
should do in case an error could not be handled.
Exception Analysis Report

Part of the Central Reporting infrastructure. The Exception Analysis Report
reports all work items with exceptions, grouped by exception, company code or
vendor.
Exception
Action that is not part of normal operations or standards

Glossary
FI
See: Financial Accounting (FI)
Financial Accounting (FI)

SAP module for the Finance and Accounting department
Fiori Task App

Light-weight web application following the design principles of SAP Fiori. It
provides an inbox showing the 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.
IAP
See: Invoice Approval (IAP)
IDoc
See: Intermediate Document (IDoc)
IE
See: Invoice Exception (IE)
Inbound Configuration
Connection to various inbound channels, for example scanned paper documents,
fax, email, or IDoc, and the corresponding configuration.
Indexing
Process of entering or storing data into the system
InfoArea
Folder in SAP NetWeaver BW to organize InfoCubes, DataStore Objects, InfoObjects,
and InfoObject Catalogs
InfoCube
Self-contained dataset in SAP NetWeaver BW, for example, of a business-oriented
area; an InfoCube is a quantity of relational tables arranged according to the
enhanced star schema: A large fact table in the middle surrounded by several
dimension tables
InfoObject Catalog
Folder structure in SAP NetWeaver BW to organize InfoObjects

Glossary
InfoObject
Smallest information unit in SAP NetWeaver BW. Key figures and Characteristics
are collectively called InfoObjects.
InfoPackages
Object in SAP NetWeaver BW that specifies when and how to load data from a
given source system to the SAP NetWeaver BW system
InfoProvider
Object in SAP NetWeaver BW for which queries can be created or executed.
InfoProviders are the objects or views that are relevant for reporting.
Intermediate Document (IDoc)

Standard SAP message document format for the EDI interface.
Invoice Approval (IAP)

VIM component that enables users to perform coding, approving and rejecting
invoices
Invoice Capture Center (ICC)

Optional VIM OCR component.
Invoice characteristic
A value specific to each invoice (for example country) that allows flexible
processing in VIM. An invoice characteristic is determined during runtime and
depends on the corresponding index data of the document.
Invoice coder
Person who enters the accounting info on invoices to allocate the cost
Invoice Exception (IE)

VIM component that handles the exceptions that arise after an SAP invoice is
created
Invoice requester
Person who requested goods and services for Non PO invoices
Key Figure
Type of InfoObject in SAP NetWeaver BW that represents numeric values or
quantities, such as Number of Invoices and Gross Invoice Amount.
Key Process Analytics Report

Part of the Central Reporting infrastructure. The Key Process Analytics Report
reports about a variety of key figures regarding the VIM process: It shows the
accumulated amounts of all documents in the DP workflow, in parked state and
in posted state.

Glossary
KPI Dashboard
Tool for managers showing VIM related process data at a glance in graphical
charts.
LIV
See: Logistic invoice (LIV)
Logistic invoice (LIV)

purchase order invoice
Materials Management (MM)

Materials management module of the SAP S/4HANA software package. Materials
management is used for procurement and inventory management.
MM
See: Materials Management (MM)
Mobile Approval Portal

VIM component for approving invoices on mobile devices.
MultiProvider
Object in SAP NetWeaver BW that is based on InfoCube(s), DataStore Object(s),
and/or InfoObject(s). A MultiProvider is used as a layer for the creation of end user
queries; the MultiProvider itself does not contain any data; rather, data resides in
the BasisCubes.
Namespace
Name range reserved by SAP for customer objects and SAP objects to make sure
that objects are not overwritten by SAP objects during the import of corrections or
an upgrade
Non purchase order (Non PO)

Order that is not based on a PO
Non purchase order (Non PO) invoice (PIR)

Invoice based on a Non purchase order (Non PO)
Number range
Array of numbers that can be used for an object in the SAP S/4HANA system
OCR
See: Optical character recognition (OCR)

Glossary
Optical character recognition (OCR)

Mechanical or electronic translation of images of handwritten, typewritten or
printed text (usually captured by a scanner) into machine-editable text
Park
Situation where an invoice is not posted and is waiting for further processing
Parked invoice document

Temporary document that the AP processor can change and post. SAP assigned
document number becomes real number when posted.
Persistent Staging Area (PSA)

Data staging area in SAP NetWeaver BW. It allows to check data in an
intermediate location before the data is sent to its destinations in SAP NetWeaver
BW.
Perspective
Web Services element that defines which item related data is displayed in the
Fiori Task App and where. A perspective defines the content and visual
appearance of items for a specific area of the screen in the Fiori Task App. The
Fiori Task App displays only one perspective at the same time.
PIR
See: Non purchase order (Non PO) invoice (PIR)
PO
See: Purchase order (PO)
Posted invoice document

Invoice that has already been posted in SAP S/4HANA. Only free-form text fields
can be changed. Related documents such as POs or good receipts may be created
or changed to effect the invoice. If the document is not needed, it must be
cancelled ( PO invoice) or reversed ( non-PO invoice).
Price variance
Situation where the price on the invoice is different from the price in the purchase
order
Process Chain
Sequence of processes in SAP NetWeaver BW that are scheduled to wait in the
background for an event; used to automate, visualize and monitor the processes.

Glossary
Process Configuration
Easy and technically simplified configuration of complex business scenario
aspects. Process Configuration covers profile configuration, profile assignment,
and authorizations.
Process Foundation
Flexible framework to configure and run processes. It utilizes generic workflow
definitions, which are processed by the SAP Business Workflow engine.
Process options
Processing options for the user in the dashboard, such as Referral, Authorization,
and Actions
Process type
Process type for a document. The process type determines the initial actor and
various collaboration options available to the various actors during the process
flow.
Productivity Report
Part of the Central Reporting infrastructure. The Productivity Report reports
about the productivity of users/roles and the activities of users/roles.
PSA
See: Persistent Staging Area (PSA)
Purchase order (PO) invoice

Invoice based on a Purchase order (PO)
Purchase order (PO)

SAP module. PO indicates a document sent from a buyer to a seller. The purpose
of the document is to order the delivery of goods or services.
Quantity variance
Situation where the quantity on the invoice is different from the quantity in the
purchase order
Roles
Set of predefined roles for the SAP user
SAP Add-On Assembly Kit (AAK)

Standardized delivery procedure for software
SAP Customer Relationship Management (SAP CRM)

SAP application that provides software for ticket systems, for example in the
Accounts Payable department.

Glossary
SAP NetWeaver Business Warehouse (SAP NetWeaver BW)

SAP application that allows to integrate, transform, and consolidate relevant
business information from productive SAP applications and external data
sources.
SAP Supplier Relationship Management (SAP SRM)

SAP application that automates, simplifies, and accelerates procure-to-pay
processes for goods and services.
Scan operator
Person who scans the invoices into images (may not have a SAP ID)
Summary Report
Part of the Central Reporting infrastructure. The Summary Report provides a
summary of all documents processed through VIM.
Transformation (TRF)
Object in SAP NetWeaver BW to connect source objects to data targets; it allows
to consolidate, cleanse and integrate data
TRF
See: Transformation (TRF)
VAN
See: VIM Analytics (VAN)
Vendor Invoice Management (VIM)

Packaged business solution that solves a business problem – paying correct
amount to vendors on-time and with the lowest cost. VIM delivers not technology
but best-practice business processes. VIM provides values to customers in process
efficiency, visibility and compliance.
VIM Analytics (VAN)

VIM component that gives users a clear data report on their invoices in progress.
VIM Analytics allows to track the documents routed through SAP workflows via
VIM.
VIM Central Workplace

Central tool to process work objects. It provides an inbox with personal and
shared work item lists to the user. It also provides access to different business
objects and status information for all objects in process. The user can switch
between work centers and navigate in a process-dependent tree.

Glossary
VIM Invoice Workplace

Tool for VIM super users, which allows users to display lists of their work items
that meet a selection they have entered before. Users also can display work items
of other users and of their team as a whole.
Web Services
Underlying technical concept of the Fiori Task App interface. You configure the
complete content of the Fiori Task App either by customizing or by implementing
an interface for the Web Services.
Work object type

Processing object in the VIM Central Workplace. It can represent a process object,
a SAP business object, or information from any SAP tables.
Workflow
SAP Business Workflows can be used to define business processes that are not yet
mapped in the SAP S/4HANA system.

OpenText Vendor Invoice Management For SAP Solutions 20.4 SPS1 - Scenario Guide For Invoice Solution English (VIM200401-CCS-En-04)

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

OpenText Vendor Invoice Management For SAP Solutions 20.4 SPS1 - Scenario Guide For Invoice Solution English (VIM200401-CCS-En-04)

Uploaded by

Copyright:

Available Formats

OpenText™ Vendor Invoice Management

for SAP® Solutions

Scenario Guide for Invoice Solution

This guide describes functional and technical scenarios of the

Open Text Corporation

275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1

Copyright © 2021 Open Text. All Rights Reserved.

No Warranties and Limitation of Liability

Part 1 Classic VIM - functional scenarios 13

2 General Data Protection Regulation (GDPR) ........................ 15

3 Processing invoices in VIM .................................................... 21

4 Multiple backend system ........................................................ 37

5 Using the Inbound Configuration with a different

6 Validating invoices in ICC or indexing in VIM? .................... 65

7 Handling line items in ICC or VIM .......................................... 71

VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution iii

7.6 Secure line item number input .......................................................... 78

8 Field references for ICC .......................................................... 81

9 Field references for IES ........................................................ 123

10 Processing electronic invoices ............................................ 131

11 Configuring Public Sector Management ............................. 185

12 Scenarios for special countries ........................................... 189

13 Processing leasing invoices ................................................ 235

14 Translating VIM ...................................................................... 237

iv OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

14.7 Approval Portal translation ............................................................. 289

16 Posted invoice reversal with a new DP workflow start ...... 305

17 SAP S/4HANA embedded analytics ..................................... 309

18 Smart coding .......................................................................... 323

19 Processing SAP Transportation Management invoices .... 333

Part 2 Classic VIM - technical scenarios 343

20 Adding new fields in ICC and VIM ........................................ 345

21 Using the metadata interface of the Inbound

22 Invoice Approval: A typical flow example ........................... 371

Part 3 Simple Mode VIM - scenarios 375

VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution v

23 Invoice processing in Simple Mode ..................................... 377

GLS Glossary 389

vi OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

VIM automates the processing of incoming documents into SAP.

Document-centric business processes like the processing of incoming invoices from

For managers VIM offers a comprehensive suite of operational and analytical

VIM includes the following solutions:

Each solution consists of a best practice implementation for a specific document

VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution 7

The VIM Foundation consists of the following components:

VIM requires an ArchiveLink-compliant SAP-certified content repository for the

8 OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

1.1 Architectural Overview

Figure 1-1: Technical system landscape

VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution 9

1.2 About this document

“Classic VIM - functional scenarios”

Note: From a technical point of view, OpenText™ Invoice Capture Center

For detailed descriptions of customizing settings, technical scenarios may

10 OpenText™ Vendor Invoice Management for SAP® Solutions VIM200401-CCS-EN-04

Release Notes Release Notes describe:

• The software supported by the product

1.2.1 Target audience

• SAP Basis Administrators

The following knowledge is required from the reader:

• in-depth knowledge of SAP S/4HANA system administration

VIM200401-CCS-EN-04 Scenario Guide for Invoice Solution 11