OpenText VIMX FDD

Functional Design
Document (FDD)
For VIM-Express Implementation (VIM 7.5 SP6)
Functional Design Document (FDD)
Contents
1 Purpose of Functional Design Document (FDD)1 with long text that wraps 7
2 SAP VIM Functional Architecture .................................................................. 8
3 VIM-Express Vendor Invoicing Process Description ................................ 10
4 General Decisions Summary........................................................................ 12
5 Document Processing Workflow ................................................................. 12
5.1 Invoice Entry.............................................................................................13
5.2 Document Archiving .................................................................................13
5.3 DP Workflow Interface..............................................................................13
5.4 Invoice Recognition ..................................................................................13
5.5 Pre-processing .........................................................................................15
5.6 Invoice Verification ...................................................................................15
5.6.1 Indexing ......................................................................................... 15
5.6.2 Role resolution .............................................................................. 16
5.6.3 Validate Metadata ......................................................................... 16
5.6.4 Duplicate check ............................................................................. 17
5.6.5 Exception Handling ....................................................................... 17
5.6.6 Posting .......................................................................................... 17
5.7 Blocking Invoice Resolution .....................................................................17
6 Invoice Entry .................................................................................................. 18
6.1 Paper Entry ..............................................................................................18
6.1.1 Archive Document Types .............................................................. 18
6.1.2 OAWD configuration ..................................................................... 18
6.2 File Entry ..................................................................................................19
6.3 E-Mail Entry ..............................................................................................19
7 Invoice Capture Center ................................................................................. 20
7.1 Workflow controlled Invoice Capture Center ............................................21
7.1.1 Archiving ....................................................................................... 21
7.1.2 Extraction ...................................................................................... 21
7.1.3 Validation ...................................................................................... 21
7.2 ART training of adaptive recognition fields...............................................22
7.3 Hot Spot ...................................................................................................22
7.4 ERP users ................................................................................................24
7.5 Infrastructure ............................................................................................24
7.5.1 Sizing ............................................................................................ 24
8 Pre- and Background processing ................................................................ 24
9 VIM-Express Pre-Configured Roles ............................................................. 25
9.1.1 Combined Roles............................................................................ 25
9.1.2 Non PO (FI) Roles......................................................................... 26
9.1.3 PO (MM) Roles ............................................................................. 26
9.2 VIM-Express – Workflow Dashboard Functions ......................................27
9.3 Operational Requirements .......................................................................27
ENTERPRISE INFORMATION MANAGEMENT 2

10 Exception Handling of PO Based Invoices ................................................. 31

10.1 PO Invoice Business rules .......................................................................31
10.2 PO Invoice – Document Processing Dates ..............................................33
10.3 VIM-Express PO Exceptions Processing .................................................34
10.3.1 PO Invalid Meta Data .................................................................... 34
10.3.2 PO Invoice Duplicate Check ......................................................... 36
10.3.3 PO Invoice Exception Handling .................................................... 37
10.3.4 Rescan required ........................................................................... 40
10.3.5 PO Tax Audit required .................................................................. 41
10.3.6 Process PO Credit Memo ............................................................. 42
10.3.7 Process PO Invoice ...................................................................... 43
11 Exception Handling of Non-PO Based Invoices......................................... 44
11.1 Non PO Invoice Business rules ................................................................44
11.2 NPO Invoice – Document Processing Dates ...........................................46
11.3 VIM-Express Non PO Exception Handling ...............................................46
11.3.1 Non PO Invalid Invoice Data ......................................................... 47
11.3.2 Non PO Invoice Duplicate Check .................................................. 48
11.3.3 Non PO Invoice Exception Handling ............................................. 49
11.3.4 Rescan required ............................................................................ 51
11.3.5 Non-PO Approval Require ............................................................ 52
11.3.6 Non PO Tax Audit Required ......................................................... 54
11.3.7 Process non PO Credit memo ...................................................... 55
11.3.8 Approval required .......................................................................... 55
11.3.9 Process non PO Invoice ............................................................... 56
12 Exception Handling of DP Invoices ............................................................. 57
12.1 DP Invoice Business rules .......................................................................57
12.2 DP Invoice – Document Processing Dates ..............................................59
12.3 VIM-Express DP Exception Handling .......................................................59
13 Invoice Approval ........................................................................................... 60
13.1 Invoice Approval Portal ............................................................................62
13.2 SAP FIORI Architecture ...........................................................................62
13.2.1 Invoice Approval via FIORI Launchpad ........................................ 63
13.3 Approval portal architecture with WAS:....................................................65
14 Invoice Posting .............................................................................................. 66
15 Blocked Invoice Resolution ......................................................................... 66
15.1 Price Block handling .................................................................................68
15.2 Quantity block handling ............................................................................69
16 Reports in VIM by OpenText ........................................................................ 70
16.1 VIM Analytics (VAN) .................................................................................70
16.2 VIM reminder Reports ..............................................................................73
16.3 Liability Report ..........................................................................................73
16.4 Central Reporting .....................................................................................74
16.4.1 Aging Report ................................................................................. 75
16.4.2 Exception Analysis Report ............................................................ 75
16.4.3 Key Process Analytics .................................................................. 76

16.4.4 License Report .............................................................................. 77

16.4.5 Productivity Report ........................................................................ 78
17 Authorizations ............................................................................................... 79
18 Imaging Enterprise Scan .............................................................................. 80
18.1 Imaging with Enterprise Scan ..................................................................80
18.2 Key features of Enterprise Scan ..............................................................81
18.2.1 Document separation .................................................................... 82
18.2.2 Page enhancements ..................................................................... 83
18.2.3 Barcode recognition ...................................................................... 84
18.2.4 Document indexing ....................................................................... 85
18.2.5 Scripting ........................................................................................ 85
18.3 Document Pipeline ...................................................................................87
19 Document archiving and viewing architecture .......................................... 87
19.1 Imaging Windows Viewer .........................................................................89
Glossary ................................................................................................................ 91
About OpenText ...............................................................................................93

Figure 1 Service Suite for VIM Implementations ........................................................................................................ 7

Figure 2 VIM Functional Architecture ......................................................................................................................... 8
Figure 3 VIM System Landscape ............................................................................................................................... 9
Figure 4 VIM Express Process Overview ................................................................................................................. 10
Figure 5 IM Document processing overview ............................................................................................................ 13
Figure 6 Pre-Process ................................................................................................................................................ 14
Figure 7 DP Dashboard- Indexing pane ................................................................................................................... 16
Figure 8 Process Overview – Invoice Entry.............................................................................................................. 18
Figure 9 OAWD Paper Entry .................................................................................................................................... 19
Figure 10 Process Overview – Invoice Recognition ................................................................................................. 20
Figure 11 Workflow controlled ICC ........................................................................................................................... 21
Figure 12 Selection Screen for PO Download .......................................................................................................... 23
Figure 13 Selection Screen for Vendor master data download ................................................................................ 24
Figure 14 Process Overview – Pre-Process............................................................................................................. 24
Figure 15 Process Overview – Role Resolution ....................................................................................................... 25
Figure 16 Process Overview – Exception Handling ................................................................................................. 31
Figure 17 Swimlane for PO Invalid Meta Data VIM-Express PO Exceptions Processing ........................................ 35
Figure 18 Swimlane for PO Suspected Duplicate .................................................................................................... 37
Figure 19 Swimlane for PO Invoice Exception Handling .......................................................................................... 38
Figure 20 Swimlane for PO Rescan Required.......................................................................................................... 40
Figure 21 Swimlane for PO Tax Audit Required ...................................................................................................... 41
Figure 22 Swimlane for PO Credit Memo processing .............................................................................................. 42
Figure 23 Swimlane for PO Processing / Posting .................................................................................................... 43
Figure 25 Swimlane for NonPO Invalid Invoice Data ............................................................................................... 47
Figure 26 Swimlane for NonPO Duplicate Check .................................................................................................... 49
Figure 27 Swimlane for NonPO Invoice Exceptions ................................................................................................. 50
Figure 28 Swimlane for NonPO Rescan Required ................................................................................................... 51
Figure 29 Swimlane for NonPO Approval Required ................................................................................................. 52
Figure 30 Swimlane for NonPO Tax Audit Required ................................................................................................ 54
Figure 31 Swimlane for NonPO Credit Memo Processing ....................................................................................... 55
Figure 32 Swimlane for NonPO Processing / Posting .............................................................................................. 56
Figure 34 Process Overview – Approval .................................................................................................................. 60
Figure 35 Approval flow ............................................................................................................................................ 61
Figure 36 Approval Portal – Overview ...................................................................................................................... 62
Figure 37 SAP FIORI Architecture ........................................................................................................................... 63
Figure 38 SAP FIORI Launchpad ............................................................................................................................. 64
Figure 39 SAP FIORI ApprovalBulleted list .............................................................................................................. 64
Figure 40 Approval portal architecture ..................................................................................................................... 65
Figure 41 Process Overview – Invoice Posting ........................................................................................................ 66
Figure 42 Overview – Blocking Invoice Resolution .................................................................................................. 66
Figure 43 Blocking Invoice Resolution Dashboard ................................................................................................... 67
Figure 44 Swimlane Price Block Handling................................................................................................................ 68
Figure 45 Swimlane Quantity Block Handling .......................................................................................................... 69
Figure 46 Liability Report .......................................................................................................................................... 74
Figure 47 Output –search criteria’s .......................................................................................................................... 74
Figure 48 Aging Report............................................................................................................................................. 75
Figure 49 Exception Analysis Report ....................................................................................................................... 76
Figure 50 KPI Report ................................................................................................................................................ 77
Figure 51 License Report ......................................................................................................................................... 78
Figure 52 Productivity Report ................................................................................................................................... 79

Figure 53 Imaging with Enterprise Scan ................................................................................................................... 80

Figure 54 Enterprise Scan GUI ................................................................................................................................ 81
Figure 55 Document Separation ............................................................................................................................... 83
Figure 56 Page Enhancements in Enterprise Scan ................................................................................................. 84
Figure 57 Barcode Recognition within Enterprise Scan ........................................................................................... 84
Figure 58 Scripting in Enterprise ScanClient ............................................................................................................ 86
Figure 59 Enterprise Scan as part of an OCR solution ............................................................................................ 87
Figure 60 Centralized Document Pipeline ................................................................................................................ 87
Figure 61 Document archiving and viewing.............................................................................................................. 88
Figure 62 Windows Viewer ....................................................................................................................................... 89

1 Purpose of Functional Design Document

(FDD)1 with long text that wraps
The purpose of this document is to describe the design of the VIM-Express hereafter called “VIM-X” setup of SAP
Invoice Management by OpenText (SAP IM), also known as OpenText Vendor Invoice Management for SAP
hereafter called as “VIM”.
VIM-X is the pre-configured standardised solution deployed by OpenText Professional Services, designed for
quick deployment and rapid scale up for customers who would like to have hands on experience of the standard
VIM solution before they can decide on process changes they might want to incorporate subsequently to suit their
businesses requirements.
Below figure gives an idea of where VIM-X figures in the services suite offering for VIM implementations from
OpenText Professional Services.
Figure 1 Service Suite for VIM Implementations
The Document is structured in a way to start with a high level function and architectural overview of VIM-X in the
chapter: SAP VIM Functional Architecture and Error! Reference source not found.. In chapter Error! Reference so
urce not found. the process is divided into major sections. Those sections are described in very detail starting
with chapter Error! Reference source not found..

2 SAP VIM Functional Architecture

Vendor Invoice Management brings together best practices in Invoice Management processes from various
industries across geographies using SAP BAPI / SAP Business Workflow technologies to automatically process
vendor invoices in SAP and manage exceptions occurring therein. VIM comes with flexible and configurable
workflow processes to automatically route invoice discrepancies to responsible business groups and eliminates
delays in decision making. VIM dashboard extends visibility into invoice discrepancy, processing history and
provides the ability to view the original paper invoice as an image, thus providing a single collaboration and
communication platform across business groups.
Following is an overview of SAP VIM process architecture:
Figure 2 VIM
Functional Architecture
The SAP invoice management process consists of 4 main steps:
1. Scan the Invoice and run it through the OCR: The incoming invoice is scanned and archived in SAP
and then run through the Invoice Capture Centre (ICC) to extract information from the image and save the
extracted metadata linked to the archived image.
2. Validate Metadata: the document metadata or index data as it is called in VIM is validated against SAP
data. If validation fails, exceptions will be triggered.
3. Duplicate Check: The validated metadata is checked against existing Invoices in the system. If the
incoming invoice is suspected to be a duplicate of an existing invoice, an exception is raised.
4. Invoice Pre-processing: Apply Business rules to detect additional exceptions before posting.

5. Post for payment: Invoice is posted and released for payment and in case of discrepancies an additional
workflow for handling the discrepancy (e.g. Quantity/Price block) is triggered.
Figure 3 VIM System Landscape

3 VIM-Express Vendor Invoicing Process

Description
The process flow for Invoice management delivered with VIM-X is summarised below:
Figure 4 VIM Express Process Overview
The OCR Option for SAP Invoice Management called Invoice Capture Center (ICC) is a standard
component of VIM-X. It extracts the metadata from the archived image and starts the Invoice processing
workflow
The SAP IM Document Processing (DP) workflow evaluates the received invoice metadata by validating
the index data against SAP data and checking all business rules. AP Processors may modify the index
data or route the Invoice to additional parties for clarification.
Work items for invoice processing and exception handling will be consolidated and can be accessed,
through SAP Inbox or VIM Integrated Invoice Cockpit.
Best Practice business rules are pre-configured and deployed out of the box.
An extra functionality only for the AP Processor is activated to simulate all Business rules including Meta
data Validation and duplicate check. This functionality will help him to solve issues before a Business rule
itself gets triggered, which avoids double receipts of work items regarding the same Invoice.
VIM-Express does not have the parking functionality activated. The DP workflow is a substitute for this
standard SAP functionality.

The approval process is based on a single organizational hierarchy for Non PO (FI) Invoices. The
approval process for PO (MM) Invoices is assumed to be taken care through the SAP PO release strategy
outside the scope of VIM-X.
Standard VIM-X roles cover the following:
1. Scanner
Scan User who digitizes the documents
2. Validator
Validates OCR data in separate validation client
3. AP processors
Validates OCR and SAP Data, checks for suspected duplicate invoices, coordinates invoice
exception routing based on best practices, provides account assignment information e.g. G/L
accounts, handles background posting errors and invoice discrepancies.
4. Buyer
Will be contacted by the AP Processor in case of issues with the Purchase order.
5. Receiver
The responsible person for entering goods receipts in the SAP System.
6. Vendor Maintenance
Responsible person for maintaining the Vendor Master.
7. Service Requester
The responsible person for entering service entry sheets in the SAP System.
8. FI approver(s)
Approves Invoices based on financial responsibility within the organizational hierarchy and amount
limits
After approval and checking the metadata the invoice is submitted for automatic posting. In case of
update exceptions, the AP processor will receive a work item, detailing the cause of the issue(s) (i.e.
posting errors due to closed periods). The AP needs to manually fix issue and post it to SAP.
Roles in VIM-X have been consolidated in order to facilitate business rules and exceptions to be carried out in a
combined manner and multiple steps are bundled into one processing unit, which eliminates redundant work items
for the AP processor.

The Vendor Invoice Analytics (VAN) is delivered with pre-configured reporting variables as in standard VIM.
Modifying the report to meet additional reporting requirements is classified as additional scope that goes beyond
the VIM-Express baseline and requires the customer to order extended consulting services
VIM also offers Central reporting capabilities which can address management reporting requirements. In case of
more extended requirements, OpenText recommends use of SAP BI/BW for creating such reports.
4 General Decisions Summary

This chapter summaries shortly major decisions for the concept and implementation of VIM at your company.
Detailed information, such as e.g. Role determination will not be listed here but in the corresponding chapters
afterwards.
Single system environment in place (Dev / QA / Prod)

Activated invoice entries will be
Paper
Mail with single PDF attachment (invoice)
IDOC (INVOIC02)
Usage of OpenText Enterprise Scan and OpenText Archive Server
Archiving as PDF, Viewing with Adobe Acrobat on Fat Clients
ICC for recognition in DE and SK
Base foundation will be VIM-X
Processes designed for DE and SKas EU copy template
Non PO related invoice
PO related invoice
Down payment related invoice
Manual Posting in the starting phase
Approval Portal also for mobile approval in place
5 Document Processing Workflow

The document processing with Invoice Management consist of six blocks which are depictured schematically in.

Figure 5 IM Document processing overview
Starting with Invoice Entry the figure shows the possible main parts of invoice processing and exception handling
until an invoice is ready to be paid. In the following subchapter those blocks, their functionality and their meshing
is described on less-detailed and a comprehensive level.
A detailed description of those is given in the main chapters beginning with chapter Error! Reference source not f
ound. to Error! Reference source not found..
5.1 Invoice Entry

The invoice entry describes the process from paper, PDF file or email attachment to a digital archived image. For
the paper based process, the OpenText Enterprise Scan Client is used. The Enterprise Scan digitizes the paper
invoices and offers the possibilities to review the scanned images and document before channelling in to SAP and
archiving the document. For archiving the invoice, the SAP transaction OAWD is used. With successful archiving
of the invoice the IM workflow starts and the invoice can be monitored during the complete process. Next to
scanned invoices the OAWD offers the possibility for a single file entry by drag and drop. So each invoice in PDF
(e.g. mail attachment received by AP) can be insert into the invoice verification process if necessary. The mail
entry process is achieved through e-mail boxes using the SAP basis email functionality. Those e-mail boxes
receive the e-mails for invoicing. Connected to the mailbox Invoice Management mechanism are triggered and
detach the PDF invoice attachments. At this point the Invoice Management workflow guides the invoice through
the complete process.
5.2 Document Archiving

For Document Archiving the OpenText Archive Server is used. Invoice images acquired from the scanning or
email entry will be stored on the OpenText Archive Server. VIM-Express provides the necessary SAP ArchiveLink
configuration settings to support invoice management with imaging.
5.3 DP Workflow Interface

Once A/P invoice images are archived via Enterprise scan/Email channel/Document Pipeline, the SAP IM DP
workflow needs to be started. This is accomplished according to the standard VIM scenarios:
Scanning with OCR – triggers the DP workflow which then sends the image through ICC and the image is put
through a manual validation process, to confirm the extracted Meta data.
Scanning without OCR – The SAP IM DP workflow is started when an image is archived using transaction
OAWD. This is based on the configuration of the ArchiveLink document type. For A/P Invoices, the ArchiveLink
document type will be configured to start the SAP IM DP Workflow. Invoices will be routed based on the
ArchiveLink document type. There will be one ArchiveLink Document Type for each scan station and country.
5.4 Invoice Recognition

After scanning or receiving an invoice it is sent to the ICC recognition server. It extracts the invoice fields and
sends the invoice for validation. Validation is done by the ICC validator role. For details on the validation client and
ICC see chapter 7 Invoice Capture Center.

Figure 6 Pre-Process
After archiving the images using transaction OAWD or through the email scenario the IM document process (DP)
is triggered as described below:
1. OCR required
Yes: Invoice was scanned with the OpenText enterprise scan and archived via the SAP transaction
OAWD which hands the images over to the OpenText capture center. There the information will be
extracted and then sent, depending on the configuration, either to the data validation or directly handed
over to the IM DP workflow.
No: The IM DP workflow is directly triggered by scanning and archiving through the SAP-Transaction
OAWD. The OCR-Component ICC is not used in this scenario and so the indexing has to be done
completely manual in SAP.
2. Validation required
The system can be setup to skip the validation for certain archive link document types.
3. ICC validation
OCR extraction results get validated manually to allow the upcoming process to run in background as
far as possible.

4. Automatic document type determination
Dependent on certain criteria the workflow determines the IM document type (or base invoice type).
(FI/MM/DP)
5. FI document type
Depending on missing PO number and missing flag for down payment the invoice type gets
determined.
6. MM document type
Depending on existing PO number and missing for down payment flag the invoice type gets
determined.
7. DP Document type
Depending flag for down payment the invoice type gets determined.
5.5 Pre-processing
The pre-process is the link between invoice recognition and exception handling. Within this part business data
determination is done based on the recognized data of the OCR and the information provided by the SAP system.
At this point especially country specific information will be determined. Next to updating several invoice and
process information, a validation and determination depending of the delivered data and process depending on
the country or company code is done. Further tax information (tax code) will be determined and a line assignment
between invoice lines and PO lines is done.
5.6 Invoice Verification

Invoice verification describes the process from an archived image to invoice posting. In case ICC was part of the
preceding process the invoice is already indexed. In case a manual scenario without ICC was picked the invoice
needs to get indexed in SAP. Therefore, VIM offers an indexing screen for entering and changing invoice fields.
Depending on the invoice exception a certain role is determined to solve the exception with predefined options.
5.6.1 Indexing
Indexing is one part of the invoice verification. It provides the possibility to enter, check or change the data
according to invoice before posting. Therefore the so called Dashboard (see Error! Reference source not f
ound.) is used. The invoice management workflow ensures that all necessary data will be indexed in the following
three ways.
Manual indexing – when OCR is not used indexing data can be entered manually.
Automatic indexing – OpenText Invoice Capture Center can automatically extract data and therefore no manual
indexing is necessary. However, indexed data can be changed by defined roles
Automatic field derivation – in case fields are not recognized by OCR or not validated the system tries to
derives information out of given index or process data (e.g. Payment terms get derived from PO (MM) or vendor
(FI)).

Figure 7 DP Dashboard- Indexing pane
The Indexing pane of the dashboard consist of four tabs, which are similar structured to the enjoy posting
transaction FB60, F-47 or MIRO.
5.6.2 Role resolution

Invoice verification is done by certain roles. A role can be one user or a group of users. It should be observed that
the roles in Invoice Management are not comparable to the SAP role concept. The IM-roles define only a certain
user or task group but do not give SAP authorization to them.
The main role in the process is the AP clerk, technically called AP Processor. VIM Express defines this role as the
initial role for an exception. In case the exception handling requires other roles than the AP clerk to support or
directly solve they can be involved by referring the process within the exception. Therefore e.g. the role of a
vendor master team is part of the invoice verification process. In case an issue connected to vendor maintenance
is discovered the invoice can be routed to the vendor master team. The roles in the processes are fixed for all
countries but every local business can decide by their own which agents are assigned to which role.
Details of the role resolution can be found in chapter Error! Reference source not found.. The assignment of the c
ertain roles to an exception will be described for the processes in chapters Error! Reference source not found.,
Error! Reference source not found..
5.6.3 Validate Metadata

The first step in the Document Processing Workflow is validating the Metadata captured manually or through
OCR. If one of the checks fail a work item will be sent out to the responsible AP Processor for corrective action.
Once a work item is sent out for handling a specific case, the AP Processor also has the possibility to take care of
other exceptions which are applicable for this work item.

5.6.4 Duplicate check

The Duplicate check will be performed after validating the metadata within SAP. This order is necessary because
the check will be performed based on the validated data. The validated metadata is used to check whether the
new invoice has been entered in the past. If the new invoice is suspected to be a duplicate of any existing invoice,
an exception is raised and the assigned user needs to confirm manually that it’s a duplicate to end the process.
He can also change data and continue the process by confirming the invoice as not a duplicate.
5.6.5 Exception Handling

The index data is checked against the DP Business rules before they are entered into SAP FI/MM as invoice
transaction data. The DP would identify any exceptions through its Business rules defined in this pre-process step.
The exceptions captured in the pre-process step leaves the image and invoice data in the DP component and
trigger a SAP workflow item to the AP Processor. Dashboard functions vary with the responsible role and may
include a list of configurable SAP Transactions to perform appropriate corrective actions in addition to facilitating
referrals to other business roles when necessary.
Business rules perform the following
Validate Index values for format and validity conformance
Coding at the Last step before sending the Invoice for approval (new to VIM-Express)
Perform special requirement needs that are set up with a specific logic and trigger the corresponding
exception (i.e. freight cost limit)
Clarify issues to prevent errors that will happen during posting afterwards.
5.6.6 Posting
The posting ends the invoice verification process. The posting can be done either in dialog or for certain invoice
scenarios in background. For dialog posting Invoice Management offers the possibility to transfer the index data
into the SAP standard transactions (FB60, F-47, and MIRO). The transaction will be automatically determined
from the invoice type (FI, MM, and DP). The archived document will automatically be attached as Object link.
Further details on posting will be explained in chapter Error! Reference source not found..
5.7 Blocking Invoice Resolution

The blocking invoice resolution (abbr. BIR) provides a system supported solution to solve the blocking reasons on
price or quantity discrepancy determined by the SAP standard. Those blocking reasons will be set by the SAP-
System automatically depending on the general SAP MM customizing, regardless whether the invoice is posted
by in dialog or background.
For each blocking reason on line item level one blocking invoice resolution workflow is triggered.
Depending on the blocking reason (price or quantity) an initial actor is automatically determined and a work item is
provided in his SAP Business Workplace with according information and options to solve the blocking reason.
Depending on the chosen option the action can be carried over for the same blocking reason on further line items
of the invoice. In certain cases, a general action has to be performed by the AP clerk on header level of the
invoice.

If the blocking reason is solved without using Invoice Management components e.g. missing GR is posted or the
purchase order is changed according to the invoiced prices automatically the work item disappears, the workflow
ends and the corresponding status is set in the Invoice Management Analytics.
6 Invoice Entry
The invoice entry describes in general the process from paper, PDF file, e-mail or EDI into the Invoice
Management process and so into the SAP-System.
Figure 8 Process Overview – Invoice Entry
6.1 Paper Entry

The paper based invoice entry uses the OpenText Enterprise Scan to capture the invoice and check the image
quality. The scanned invoices are archived into the Archive Server through the SAP using the OAWD. With
successful archiving of the invoice the Invoice Management workflow starts with the invoice character recognition.
For each company code an entry exists in the OAWD, see Error! Reference source not found..
6.1.1 Archive Document Types

As per the usage of automatic company code detection the archive document types will be created with the
following naming convention, whereas “xxxx” stands for the company code. The next character determines
whether the OCR Channel will be used (“R”ecognition) or processing will be done without OCR (“N”o recognition)
(see also chapter Error! Reference source not found.). The documents will be archived as PDFs, which is m
arked with “P” with the last character.
ZVIMxxxxRP - VIM Incoming Invoices xxxx
6.1.2 OAWD configuration

In SAP transaction OAWD there will be a possibility to start invoice processing for all archive document types. For
each document type certain org-units can be assigned, so that only assigned document entries will be visible to
the users.

Figure 9 OAWD Paper Entry
In the following the sequence of scan and archive preparation are listed:
1. Prepare paper batches.
Every new invoice starts with a separator sheet or barcode sticker.
Attachments are separated with a batch code page or with a barcode sticker.
2. Sort paper batches using company codes.
3. Scan batch for one company code.
4. Do image manipulations if necessary using Enterprise Scan.
5. Call SAP transaction OAWD.
Choose mass entry to input all scanned batches.
Chose single entry to input only first batch of invoices.
6.2 File Entry

In case an invoice is there as PDF-File, this file can be stored using the Drag and Drop functionality of the SAP
Transaction for OAWD. Afterwards the file is automatically archived and the Invoice Management workflow starts
with the character recognition.
For each company code an entry exists in the OAWD, similar to the paper entry (compare Error! Reference s
ource not found.)
In the following the sequence of archive preparation are listed:
Store PDF invoice image locally (N.B. PDF must only contain the invoice otherwise attachments
might slow down or block the OCR engine)
Open transaction OAWD.
Choose single entry to input PDF file
6.3 E-Mail Entry

The mail entry process is achieved through the SAP basis email functionality. The kernel of the SAP NetWeaver
Application Server ABAP supports the Simple Mail Transfer Protocol (SMTP). This enables email exchange
between the SAP ERP system and each SMTP mail server, without having to use additional external components.
Vendor Invoices have been attached to email in PDF format. All email invoices will be sent to ICC for metadata

recognition followed by ICC Validation by AP Processor. Once validation is complete in ICC, either PO or NONPO
VIM workflow will be triggered for further invoice process.
7 Invoice Capture Center

VIM-Express is implementing OpenText’s SAP Invoice Management (SAP IM) Solution to store incoming vendor
invoices and to enhance/optimize Accounts Payables processing. In addition, the OpenText Invoice Capture
Center (ICC) is being implemented to process the invoices using OCR recognition technology before they are
passed on to IM.
This chapter focuses on the Invoice Capture steps (Invoice recognition) shown in the figure below.
Figure 10 Process Overview – Invoice Recognition
The ICC process consists of these basic steps:
1. Scanning & Archiving: The document is scanned and subsequently archived to the archive server.
2. OCR Extraction: OCR processing to extract all business information from invoice.
3. OCR Validation: Validate and correct extracted OCR metadata using the OpenText Validation Client.
Create Document in IM Workflow: Document is released to IM workflow.
The Invoice Capture Center (ICC) is the software that captures information from invoices. These will be scanned
invoices and invoices received as PDF-files.
The Invoice Capture Center uses a technology called Optical Character Recognition (OCR) to extract the invoice
information from the document.

7.1 Workflow controlled Invoice Capture Center
Figure 11 Workflow controlled ICC
A more technical description of the data flow can be found in the introduction of the ICC administrator manual.
The capture workflow is controlled by the VIM/ICC configuration stored in SAP. It controls the recognition and
validation of the documents and the communication between VIM, ICC and Archive Server.
7.1.1 Archiving
Archiving of the invoices is done outside of ICC. When scanning is done in Enterprise Scan, the scan operator
triggers the archiving operation from SAP-transaction OAWD. That will cause an OLE-call from the local SAP-GUI
to Enterprise Scan to send all documents to the Archive ID on the Archive Server defined in SAP for the invoked
document type. Enterprise Scan will send the documents into either a local or a remote OpenText Document
Pipeline that will perform the archiving in the Archive Server and report back the unique Document ID of the
archived document to SAP. SAP in turn will start the OCR-workflow based on that Document ID and Archive ID.
The status of the document in VIM will be set to Scanned.
7.1.2 Extraction
The recognition engine extracts the index information from the document. For the recognition, the product
OpenText Invoice Capture Center (ICC) with its so-called DokuStar-engine is used. This technology is a rule-
based recognition with a predefined knowledge base for international invoices, so no training is needed for the
standard fields. For a detailed description see the Invoice Capture Center Administrator guide.
The VIM-Express ICC Customization runs a scheduled job that will ask SAP regularly if any documents are
available in status Scanned. If so it will take the Archive ID and Document ID from VIM and use it to download the
image from the Archive Server.
The extraction is a process that is running without end user interface. An administrator interface exists, to control
the status of the system. The number of extraction nodes can be increased to increase the throughput of the
system. An automatic load balancing controls the workload on each extraction node.
When extraction has been completed ICC will store the extracted information as a XML-document on the Archive
Server alongside of the scanned image. The extracted information is also handed back to VIM and stored in the
header & item tables. The status of the document in VIM-Express is updated to Extraction Complete.
7.1.3 Validation
The validation client serves for verification or correction of incorrect fields and to enter fields, not found by the
Extraction. The validation client is an ergonomic user interface for this purpose:
Field status by background colour

Labelling of the recognition zone on the image
Zoomed view of the recognition zone
Data entry with the mouse – Single Click Entry
Display of alternative field results
Special display mode for line items
After validation the recognition results are complete and correct. It is not intended to enter information into the
validation client that’s not actually literally available on the invoice. There should be no A/P knowledge needed for
operating the validation client.
Non-ICC-required index fields that are not filled in the validation are transferred as empty fields to VIM-Express.
The fields might have to be entered then in the VIM-EXPRESS indexing mask depending on additional checks in
VIM-EXPRESS itself.
The validation user must login to the Validation Client with his SAP login. If the user is member of the Validation
role in VIM-EXPRESS, he will be authorized to perform validation. The Validation Client will then ask SAP
continuously if any documents are available in status Extraction Complete. If so it will take the Archive ID and
Document ID from VIM and use it to download the image from the Archive Server to be shown alongside of the
validation fields to help the Validator.
After extraction and successful validation, the invoice will go to status Validation Complete and an automatic
trigger in SAP will continue the SAP-based part of the VIM-workflow. However, recognition fields still marked as
incorrect after validation will not be transferred to SAP. The documents are now ready for the invoice verification
process in VIM-Express. If a purchase order number has been found during recognition the PO process will start.
Otherwise the Non PO process will start.
7.2 ART training of adaptive recognition fields

The ICC 7.5 server is able to learn how to extract data for the adaptive recognition fields. This is archived by
human guided training on an example invoice. The training is template based and once a template has been
trained it will be in effect for all similar invoices. The ICC 7.5 server keeps this learning data in special databases
(ART databases). From this databases learning data can be imported and exported. The ART training takes place
on the ICC 7.5 server.
7.3 Hot Spot

The ICC 7.5 server periodically fetches recognition jobs and downloads data from the SAP ERP system. These
periodical tasks are performed by using a technology called “hotspot”.
For each application two download hotspots are configured. One Hot Spot for a weekly full download from PO and
PO items on Sunday. The second download is configured as a daily delta download. In the daily download only
new PO and PO items data were downloaded, this reduces the download time. For the vendor download only a
full download exists because the vendor download is not time-consuming.

Figure 12 Selection Screen for PO Download

Figure 13 Selection Screen for Vendor master data download
7.4 ERP users

The ICC 7.5 server communicates with the SAP ERP system to ask for recognition jobs, download data and
training data. The ICC 7.5 server exports results to SAP ERP. This communication is done using a technical SAP
ERP user.
7.5 Infrastructure
7.5.1 Sizing
The general recommendation is to ensure that the following minimum system requirements are met:
General Recommendation:
Invoices per year: 100.000; working days per year: 250; average pages per invoice: 3; maximum recognition time:
8h; active applications: 2; download records: 1.200.000.
32GB memory; 5 CPU’s and 12 GB RAM
8 Pre- and Background processing

The Pre and background processing describes actions which are taken after the IM workflow is started and the
invoice recognition – in case OCR is used – has been finished. Also with every run of business rules a set of
custom checks and automatic derivations are made.
Figure 14 Process Overview – Pre-Process
In the pre process the document type is determined
FI document type
Depending on missing PO number and missing flag for down payment the invoice type gets determined
MM document type
Depending on existing PO number and missing for down payment flag the invoice type gets determined.

DP Document type
Depending flag for down payment the invoice type gets determined.
Furthermore, the tax code will be determined. This is either be done by the PO Tax code or by using the SAP
code determination based on the recognized tax rate.
Also a line item determination for PO lines will be done based on the data recognized from OCR.
9 VIM-Express Pre-Configured Roles

The roles defined below are used for workflow routing and receiving user(s) for each role is determined based on
organization chart maintained in VIM-Express user master.
Figure 15 Process Overview – Role Resolution
All users must have access to the SAP ERP system to receive notifications and collaborate with other process
participants. Requesters can enter cost settlement from Web UI and communicate with A/P group via remarks and
notes.
The following table lists the VIM-Express roles and compares them to the standard VIM roles as defined in VIM
Baseline:
9.1.1 Combined Roles
VIM-Express Role Description Determine agents in Invoice Processing
Scanner (optionally Scanner Operator who scans the

Org unit
AP Processor) invoices into images

Vendor Responsible party for maintaining the

Org unit
Maintenance Vendor Master Data
Info Provider Receiver of “Refer for Information” Manual forward
Responsible Party for Workflow

WF Administrator Org unit
issues
9.1.2 Non PO (FI) Roles
AP Processor Index data entry and/or validation Org-Unit

role. Interfaces with the dashboard,
routes the Invoice to corresponding
Users. Resolves invoice posting
issues and posts invoice manually if
needed. Identifies and checks
suspected invoice duplicates
Requester Requester of products or services. Email on invoice / or AP processor enters

on Index screen
User is only allowed to change item invoice

data according to VIM X customizing
Invoice Approver Financial approver of the invoice. Defined in the COA table
User is not allowed to change any invoice

9.1.3 PO (MM) Roles

Buyer Responsible party for Purchasing, User is determined by the creator of the PO
resolves Issues related to the PO or
changes It User is not allowed to change any invoice
Receiver Responsible for performing Goods User is last creator of a GR [MKPF-USNAM]

Receipt
User is not allowed to change any invoice
AP Processor Index data entry and/or validation Org-Unit

role. Interfaces with the dashboard,
routes the Invoice to corresponding
Users. Resolves invoice posting
issues and posts invoice manually if
needed. Identifies and checks
suspected invoice duplicates
Service Requester Responsible Party for approving the The Service requester is determined by a
Invoice on job or project base. valid username in the requester field
[EKPO-AFNAM] of the first PO Line
Requester Responsible for approving the PO

based non GR related invoice
9.2 VIM-Express – Workflow Dashboard Functions

Dashboard Functions in VIM and VIM-Express are categorized into three categories of processing functions
(Action, Referral and Authorization) Users can select those to execute and resolve exceptions.
9.3 Operational Requirements

In Baseline terms, operation requirements are the options (action, referral and authorization) the users can take.
In practical terms these options take the form of pushbuttons available to the users on dialog screens.
Option Type Description Notes
Refer Referral Send a work item to another role. The options

available to the receiving role are based on the
[Baseline] configuration of the receiving role. With
execution of this option the role determination
of the receiving role will be executed and
displayed as suggestion. This suggestion can
be changed by removing or adding users.

Forward for Action Referral Send a work item to others in the same role. Agent determination is normally
The other person will have the same options. self-directed.
Refer for information Referral Send a work item to Information Provider. The
Information Provider can only add comments
[Baseline] and send back to requesting agent.
Change of Index data Action For selected IM Roles the possibility will be VIM Express defines following
provided to change, correct or add data to the roles to allow changes on Data:
[Baseline] index data depending on the invoice
exception. AP Processor
Change Document Type Action Change DP document type from DP

Dashboard (switch from NPO to PO process or
the other way round)
Confirm Duplicate Action Mark the index (metadata) as duplicate and Appears only in Business Rule
terminate the DP workflow. “Suspected Duplicate”
Optional: provide reason code for the

duplicated invoice and annotate the image.
Confirm “not Duplicate” Action Confirm the invoice is not a duplicate invoice Appears only in Business Rule
and move the workflow forward. “Suspected Duplicate”
Create PO Action Offers the possibility to create a PO using Might have display restriction,
transaction ME21n depending on customizing
[Baseline]
Displayed only when
Purchase Requisition exists
Change PO Action Offers the possibility to change the PO using Might have display restriction,
transaction ME22n with prefilled values from depending on customizing
[Baseline] invoice
Displayed only when
Create New Purchase Action Offers the possibility to create a new purchase Might have display restriction,
Requisition Requisition using transaction ME51n depending on customizing
[Baseline] Displayed only when

Change Requisition Action Offers the possibility to change the purchase Might have display restriction,
Requisition using transaction ME52n with depending on customizing
[Baseline] prefilled values from invoice
Displayed only when
Post Goods Receipt Action Offers the possibility to post goods receipt Might have display restriction,
using transaction MIGO with prefilled values depending on customizing
[Baseline] from invoice
Displayed only when
Reverse Goods Receipt Action Offers the possibility to reverse goods receipt Might have display restriction,

using transaction MIGO with prefilled values depending on customizing

[Baseline] from invoice
Displayed only when
Coding Action Requester enters "Coding data" for Invoice
If Requester rejects the invoice, it is sent back

to the initial actor of the parked invoice
workflow, most likely the AP Processor.
Approve Action This action adds an “approved” entry in the This action is not configured in
approval log. If coding is performed, the the action table
financial data are also saved. If the approval is
completed in this step, this action also triggers
an event to notify the main workflow to
continue to the next step (most likely auto post
the invoice). If not, the next level approver is
determined.
Reject Action This action adds a “Rejected” entry in the This action is not configured in
approval log. If coding is performed, the the action table
financial data may also be saved. The rejected
invoice goes back to the AP Processor.
Rejecting requires a comment to be entered!
Cancel Invoice Authorization This option authorize another role to perform

the according action and forwards the work
[Baseline] item to this role
Cancel Invoice Action Depending on document type the transaction Action is performed on header
FB08 (FI-Invoices) or MR8M (MM-Invoices) to level
[Baseline] cancel posted invoices. Afterwards the
process will be terminated
Short Pay Authorization This option authorizes another role to perform Might have display restriction,
the according action and forwards the work depending on customizing
[Baseline] item to this role
Displayed only when Purchase
Requisition exists
Short Pay Action Depending on document type the transaction Action is performed on header
FB60 (FI-Invoices) or MIRO (MM-Invoices) to level
[Baseline] post a credit Memo or subsequent credit
against posted invoices. Afterwards the
process will be terminated
Cancel and re-enter as PO Authorization This option authorize another role to perform Might have display restriction,
invoice the according action and forwards the work depending on customizing
item to this role
Cancel and re-enter as PO Depending on document type the transaction

invoice Action FB08 (FI-Invoices) or MR8M (MM-Invoices) to Action is performed on header
cancel posted invoices and post a new PO- level
[Baseline] related invoice. Afterwards the process will be
terminated
Cancel and re-enter as Non- Authorization This option authorize another role to perform Might have display restriction,
PO Invoice the according action and forwards the work depending on customizing
item to this role


Cancel and re-enter as Non- Action Depending on document type the transaction Action is performed on header
PO Invoice FB08 (FI-Invoices) or MR8M (MM-Invoices) to level
cancel posted invoices and post a new Non-
[Baseline] PO-related invoice. Afterwards the process will
be terminated
Release payment Authorization This option authorize another role to perform Might have display restriction,
the according action and forwards the work depending on customizing
block item to this role
Displayed only when price
[Baseline] difference is in tolerance1
Release payment Action The payment block on header level will be Action is performed on header
released level
block
[Baseline]
Change doc type Action The document type can be switched from FI to
MM or the other way round
[Baseline]
Re-Apply Business Rules Action The work item will be finished and the set of
business rules will be checked in background
[Baseline]
Submit for Approval Action The current work item will be finished and the
approval process will be triggered
[Baseline]
Remove payment block and Action After the posted approval process is finished
complete DP or rejected the AP can remove payment block
on header level and complete the workflow
Keep payment block and Action After the posted approval process is finished
complete DP or rejected the AP can keep payment block on
header level and complete the workflow
Reject to Vendor Action A rejection letter can be send to the vendor –
Post FI Invoice Action Post FI Invoice – FB60
Post MM Invoice Action Post MM Invoice – MIRO
Post DP Invoice Action Post DP Invoice – F-47
1 price difference is in tolerance of 100 % or absolute maximum value of 1.000.000 USD

10 Exception Handling of PO Based

Invoices
This chapter describes the invoice verification process within the SAP ERP system. It starts with the exception
dashboards, the entry point for every role to take actions on an invoice or to refer the invoice for issue handling.
Next the business rules themselves will be introduced and explained in detail. VIM Express defines the AP
Processor as starting role for every exception.
Figure 16 Process Overview – Exception Handling
10.1 PO Invoice Business rules

Invoices processed through VIM-Express are tested for several Business rules. If any of the Business rule logic
fails, then an exception is raised and a work item is routed to specific users for resolution. Exception processing
continues until the invoice can be successfully posted, is deleted or the work item is manually stopped. VIM-
Express user(s) will use the simulation functionality of the dashboard, which runs all exceptions in one batch to
eliminate the need of sending multiple work items to the same user (AP processor).
The list of business rules is drawn on the standard VIM documentation. Any of those rules are easily activated /
deactivated according to the specific requirements of the customer. Customer specific enhancement are marked
with CS instead of a process number.
Here is a list of best practice exceptions which will be active within the VIM-X package:
PO Meta Data Validation
Process Description Validation Procedure
701 Invalid PO Number (PO) Indexed PO # is not valid in SAP
Invalid Vendor Number Indexed Vendor # is not valid in SAP

702
(PO)

704 Invalid Currency (PO) Indexed Currency is not valid in SAP
725 Missing Invoice Date(PO) Invoice Date is missing
711 Missing VAT date (PO) Tax Reporting Date is missing
Vendor Invoice Reference Invoice Reference is missing

733
missing (PO)
Index data will be checked against following fields if there are entries
with similar values the exception will be raised
705 Suspected Duplicate (PO) Vendor Reference

PO Number
Vendor Number
Invoice Date
723 Missing Item Qty. Item Quantity is missing for a PO Line
709 Unable to determine PO There are more invoice lines than PO lines
Line no (PO)
710 Manual Check Needed for The Line item determination did fail or there are more Lines on the
Indexing Lines (PO) Invoice than on the PO
720 Invalid Vendor VAT Vendor VAT no. does not match the Master Data.
Number
726 Invalid Tax Information Samples of options:
Auto calculate is enabled but no Invoice tax code is available

Auto calculate is not enabled but Invoice tax amount is blank
Invoice tax code and Invoice country (based on Invoice Company
Code from PO) is used in calculation procedure (V_005_E-KALSM).
Check SAP table T007A to ensure invoice tax code is valid for the
calculation procedure.
706 PO not released or Indexed PO # is not released

incomplete
753 Vendor Mismatch (PO) Indexed vendor # does not match with PO Vendor or PO Partner
755 Currency Mismatch (PO) Invoice currency does not match to PO currency
757 Freight on Invoice (PO) – Exception gets triggered when an amount is captured from ICC as
Unplanned Delivery Costs unplanned delivery costs or fright charges.
738 Missing Mandatory All fields which are set up as required needs to be filled, if not this
Information (PO) exception is triggered.
754 Service Entry Required Service entry sheet is missing

(PO)
751 Vendor Audit Required Indexed vendor is marked for special audit in configuration (not auto-
(PO) posted i.e. certain countries have special treatment for tax) Bypass
possible
758 Tax Audit Required (PO) Indexed invoice is marked for special audit in configuration. Bypass
possible
760 PO Credit Memo If the processed invoice is a credit memo, manual processing will be
Processing triggered, to check the corresponding Invoice.
708 Process PO Invoice (PO) This is the default process when no other business rules apply or the
auto-posting has failed.
10.2 PO Invoice – Document Processing Dates

Date Type Description Available Options Default
This attribute determines 1. Current System Date

the date to be used as the 2. Date on the Vendor Invoice
Posting
Posting date when creating 3. Date of the supply of the Goods or Current System date
data Services
a SAP Invoice Document
4. Scan Date
from a DP document
5. Manual Entry

This attribute determines 1. Current System Date

the date to be used while 2. Date on the Vendor Invoice
Conversion converting the invoice 3. Posting Date
4. Date of the supply of the Goods or
Posting date
Date amount from foreign
currency to company code Services
or local currency.
1. Current System Date

This attribute determines 2. Document Date
the date to be used as the 3. Posting Date
Baseline
baseline date for due date 4. Supply Date Document Date
Date 5. Scan Date
calculation when creating
an SAP Invoice Document" 6. Manual Entry
10.3 VIM-Express PO Exceptions Processing

Exception processing is handled the same way as in VIM. The following sections highlight the most common
exceptions and their ‘best practice’ resolution from an SME perspective.
10.3.1 PO Invalid Meta Data

The Indexed Invoice Data or the one from OCR needs to be validated against SAP Master Data, to be used during
the duplicate check.

Figure 17 Swimlane for PO Invalid Meta Data VIM-Express PO Exceptions Processing
This section covers the handling of following exceptions:
Invalid PO Number
Invalid Vendor ID
Invalid Currency
Missing Invoice Date
Vendor Invoice Reference missing
Exception:
The indexed values are validated against SAP master data and transaction tables. Exception handling is triggered
if any of the above business rules fails validation.
Resolution:

There are several possible solutions to handle the Invalid PO Number / Vendor ID and Currency exceptions:
1. The AP Processor verifies the image and corrects Index data

2. Create a new PO (in case of invalid PO number) and enter the new PO number in index
3. Forward the work item to Vendor Maintenance to maintain Master data and enter the new or maintained
entry in index.
4. Maintains or creates the Purchasing view of the Vendor by himself.
5. Involves other parties to clarify open issues or get assistance to handle the case.
There are several possible solutions to handle the Vendor Invoice Reference and Missing Invoice Date
exceptions:
1. AP Processor does change Index Data and continues processing by simulating the rest of the business
rules.
2. Completes the invoice with the missing data.
3. Involves other parties to get the missing information and continues processing.
4. Marks the Invoice as obsolete.
10.3.2 PO Invoice Duplicate Check

During the check for duplicates, only index data will be evaluated when determining potential duplicates. Currently
only one combination of fields has been specified, if more combinations are necessary it can be adjusted during
testing phase.
Duplicate
Description
Group
Check for Duplicated PO invoice
(any one of the following is a suspected duplicate)

01
Vendor Reference
PO Number
Vendor Number
Invoice Date

Figure 18 Swimlane for PO Suspected Duplicate
Exception:
This exception is triggered when the duplication check process detects the new invoice could be duplicate with at
least one existing invoice from the indexing table.
Resolution:
There are several possible solutions to this exception:
1. AP Processor confirms that the new invoice is a duplicate and terminates the workflow.
2. AP Processor confirms that the new invoice is not a duplicate and continues the workflow.
3. AP Processor changes the index and checks for duplicate again.
4. AP Processor does request Action from the Buyer, Buyer creates or changes a current PO to solve the
Issue.
Responsible Parties Involved:
1. AP Processor – confirms a duplicate or a valid Invoice, Analyses the Invoices and or request information
from the Buyer
Buyer - Create new PR or change PO and provide information
10.3.3 PO Invoice Exception Handling

Figure
E N T 19
E RSwimlane
PRISE for PO
I N Invoice
F O R Exception
M A T I OHandling
N MANAGEMENT 38
Trigger/Exception:
PO is not Released or Incomplete

Missing Item Unit Price
Missing Item Quantity
Vendor Mismatch
Currency Mismatch:
Freight on Invoice:
Invalid Vendor VAT Number
Invalid Tax Info
Missing Mandatory Information
Process configuration:
The invoice exception handling process in VIM-Express is configured as to fit into one swim lane. This will prevent
receiving duplicate (redundant) work items from/to the central role (AP Processor).
The AP processor itself will get a work item for the first failed business rule. From that point on it is possible to
simulate all business rules and clarify all issues within the exception handling framework all at once. She will get
an overview with traffic lights, indicating which business rule failed and why. In the case the AP Processor is
satisfied with the Invoice data and wants to ignore business rules she can bypass them.
There are several possible solutions to handle the Currency- and Vendor Mismatch exceptions:
1. AP Processor changes the index data to match the PO

2. AP request action from the buyer to change the PO or create a new PO to match the data
3. AP adjusts the Index Data to resolves the exception
4. AP requests information to clarify the issue
5. Marks the invoice as obsolete or requests a credit memo / new Invoice
6. Forwards the work item to Vendor Maintenance to maintain master data and enters the new entry on the
index screen.
There are several possible solutions to handle the Freight on Invoice exceptions:
1. AP Processor gets the notification that there are unplanned delivery costs on the invoice, e.g. freight.
Controls it and accept to post as unplanned Costs.
2. AP requests the Buyer to adjust the PO and add a new Line for freight, handling or packing charges to
resolve the issue
3. AP enters the unplanned delivery costs directly to a GL account when he has the authorization to do
coding on the DP document
There are several possible solutions to handle the Invalid Vendor VAT Number, - Tax Info,
1. AP clarifies the issue or corrects the invoice data and continues processing the invoice.

2. A tax expert (if the AP Processor is not one) provides necessary information to clarify the issue or gives
okay to bypass the business rule allowing processing the invoice without VAT no.
3. AP sends the invoice to Vendor Maintenance to initiate the correction in master data management.
4. Includes a tax expert to clarify on a zero tax rate invoice. When she gets the okay she maintains the
invoice as tax exempt (also in tax exempt text field), and continues processing
5. Marks the Invoice as obsolete.
There are several possible solutions to handle the PO is not Released or Incomplete exception:
1. Buyer changes/releases the PO.

2. The Buyer creates a new PO and AP changes the index data accordingly.
There are several possible solutions to handle the Missing Item Unit Price and Missing Item Quantity
exception:
1. AP adds the missing Data

2. AP bypasses the Exception and tries to post without the missing data.
1. AP Processor - Maintains index information, coordinates the communication between the other involved
parties.
2. Vendor Maintenance – Maintains the central vendor view or creates new vendors
3. Receiver – responsible party to enter goods receipts
4. Buyer – Changes or creates Pos, clarifies MM related issues.
5. Tax Expert – If special TAX input needed to resolve or clarify tax related issues.
10.3.4 Rescan required
Figure 20 Swimlane for PO Rescan Required
Trigger/Exception:
This exception is manually triggered when AP requests a new scan.
Resolution:

1. Scanner confirms the rescan and triggers a new process.

2. Scanner sets the Invoice to obsolete
1. Scanner – Process the rescan
10.3.5 PO Tax Audit required
Figure 21 Swimlane for PO Tax Audit Required
Trigger/Exception:
The exception Tax Audit required is triggered if a Vendor / Material is maintained for special tax review. (OT
Table)
Resolution:
There are several possible solutions to handle the Tax Audit-, exceptions:

1. Tax Expert checks the blacklisted vendor and gives okay for further processing by by-passing the
business rule.
2. Tax Expert checks the blacklisted vendor and informs AP to gives his okay for further processing by by-
passing the business rule.
3. Tax Expert requests information from the AP Processor.
4. The Buyer changes the existing PO or creates a new PO and maintains the index data.
5. Sends the invoice to Vendor Maintenance to initiate the correction of the master data.
6. Adjusts the vendor blacklist by removing the vendor, and corrects the vendor master.
7. AP sets the invoice to obsolete.
1. AP Processor - Maintains index information, coordinates the communication between the other involved
parties.
2. Buyer – Changes or creates a PO, clarifies MM related issues.
3. Tax Expert – Clarifies special Tax issues.
10.3.6 Process PO Credit Memo
Figure 22 Swimlane for PO Credit Memo processing
Trigger/Exception:
If the Invoices have processed the Meta Data Validation and all other Invoice exception, it will be checked if it is a
Credit memo. If so, AP has to manually Post the Credit Memo to do the Linkage to the SAP Invoice.
Resolution:
1. AP Post the Credit Memo and Links it to an Invoice

2. AP sets the Credit memo to obsolete.

1. AP Processor - Process PO Credit Memo
10.3.7 Process PO Invoice
Figure 23 Swimlane for PO Processing / Posting
Exception:
This exception is designed to be a default process type. For various reasons, the invoice cannot be posted in the
background automatically. One common reason why auto-posting fails, is due to a closed posting period. In this
case the AP gets the work item with the SAP message which tells him why auto posting failed. She can adjust the
invoice and post it manually. If auto posting is disabled, this exception indicates that all business rules had been
applied successfully and the invoice is ready for posting.
Resolution:
(1) AP manually posts the invoice.

(2) AP changes Invoice data and checks the business rules again.
(1) Buyer – Provides input to AP.
Special Requirements:
Not applicable

11 Exception Handling of Non-PO Based

Invoices
11.1 Non PO Invoice Business rules

Invoices enabled through VIM-Express are tested for several Business rule logics. If any of the Business rule logic
Here is a list of best practice exceptions which will be active within the VIM-X package. Customer specific
enhancement are marked with CS instead of a process number.
Non-PO Metadata Validation
801 Invalid Vendor ( NPO) Indexed Vendor # is not valid for the company or status is blocked in
SAP
802 Invalid Currency ( NPO) Indexed Currency is not valid in SAP
823 Missing Invoice Date Invoice Date is missing

(NPO)
833 Vendor Invoice Reference Invoice Reference is missing

missing (NPO)

804 Suspected Duplicate Index data will be checked against following fields if there are entries
(NPO) with similar values the exception will be raised
1. Vendor Reference
2. Vendor Number
Invoice Date
820 Invalid Vendor VAT Vendor VAT no. does not match the Master Data.
Number
824 Invalid Tax Information 1. Auto calculate is enabled but no Invoice tax code is available
2. Auto calculate is not enabled but Invoice tax amount is blank
Invoice tax code and Invoice country (based on Invoice Company

809 Derivation Rule -Non PO- Runs in Background

Expense Type
838 Missing Mandatory All fields which are set up as required needs to be filled, if not this
Information (NPO) exception is triggered.
803 Invalid Requester Requester email is missing.
850 Approval Required (NPO) The VIM standard force normally a four eye principal. This means that
the requester, who will do the coding can’t approve the invoice in one
step even his limits are sufficient.
853 Vendor Audit Required Indexed vendor is marked for special audit in configuration in a
(NPO) customizing table
854 Tax Audit Required (NPO) Indexed invoice is marked for special audit in configuration in a
customizing table
806 Non PO Credit Memo If the processed invoice is a credit memo, manual processing will be
Processing triggered, to check the corresponding Invoice.
807 Process Non-PO Invoice This is the default process when no other Business rules apply, at this
(NPO) step the AP Processor has the possibility to post the Invoice in the
ODG process.

11.2 NPO Invoice – Document Processing Dates

This attribute determines the 1. Current System Date

date to be used as the Posting 2. Date on the Vendor Invoice Current
Posting data date when creating a SAP 3. Date of the supply of the Goods
System Date
Invoice Document from a DP or Services
document 4. Scan Date
5. Manual Entry
This attribute determines the

date to be used while 1. Current System Date
converting the invoice amount 2. Date on the Vendor Invoice
Conversion Date Posting Date
from foreign currency to 3. Posting Date
company code or local 4. Date of the supply of the Goods
currency. or Services
This attribute determines the 1. Current System Date

date to be used as the baseline 2. Document Date
Document
Baseline Date date for due date calculation 3. Posting Date
Date
when creating an SAP Invoice 4. Supply Date
Document" 5. Scan Date
6. Manual Entry
11.3 VIM-Express Non PO Exception Handling

11.3.1 Non PO Invalid Invoice Data
Figure 25 Swimlane for NonPO Invalid Invoice Data
Invalid Vendor ID
Invalid Currency
Invalid Requester ID (Blank Requester does not trigger this process)
Exception:
When the DP Workflow is started invoice data (Vendor ID and Currency Type) is validated against SAP master
data. This exception is triggered when the validation of either of these fields fails.

Resolution:
1. Correct the metadata (index) manually

2. Create a new Vendor or (in case of invalid Vendor ID) and enter the new Vendor ID in index.
1. AP Processor – Change the index information or communicate with Vendor Maintenance if a new vendor
is required.
2. Vendor Maintenance -Triggering point for the external Process to maintain/create new Master data
entries.
11.3.2 Non PO Invoice Duplicate Check

During the check for duplicates, only index data will be evaluated when determining potential duplicates. Currently
only one combination of fields has been specified, if more combinations are necessary it can be adjusted during
testing phase.
Duplicate
Description
Group
Check for Duplicate non-PO invoice
(any one of the following is a suspected duplicate)

02
Vendor Reference
Vendor Number
Invoice Date

Figure 26 Swimlane for NonPO Duplicate Check
Exception:
This exception is triggered when the duplication checks fails, in other words, the new invoice could be a duplicate
with at least one existing invoice from the indexing table.
Resolution:
1. AP Processor confirms that the new invoice is indeed a duplicate and terminates the workflow.
2. AP Processor confirms that the new invoice is not a duplicate and continues the workflow.
3. AP Processor changes the index and check for duplicate again.
1. AP Processor – Confirm the duplicate invoice or continue processing
11.3.3 Non PO Invoice Exception Handling

Figure 27 Swimlane for NonPO Invoice Exceptions
Trigger/Exception:
Vendor Invoice Reference Missing

Missing Mandatory Information
Invalid Vendor VAT Number
Invalid Tax Info.
Freight on Invoice
Invalid Requester ID
Process setup:
When the DP Workflow is started invoice data is validated against the Business rule logic. Like for the PO Process
this swim lane is a common process which handles almost all exceptions which can appear during Invoice
processing. The AP Processor is able to simulate the Business rules and can handle all exception cases in one
step. IF AP thinks a business rule doesn’t need to be validated anymore she can by-pass specific business rules
to continue processing. All business rules are handled in the same way in VIM-Express, so it is not necessary to
split all processes into separate swim lanes. It also prevents work items being sent redundantly from/to the same
role.
Resolution:
There are several possible solutions to handle the Invalid Vendor ID and Currency exceptions:
1. Correct the metadata (index) manually and simulate the business rules.
2. Forward the work item to Vendor Maintenance to create a new vendor or adjust an existing one (in case
of invalid Vendor ID) and enter the new Vendor ID in index.
There are several possible solutions to handle the Invalid Vendor VAT Number, - Tax Info, - Recipient VAT
Number and Missing Tax exempt Text exceptions:
1. AP Processor clarifies the issue or corrects invoice data and simulates the business rules to continue
processing the invoice.
2. Tax expert (if different from AP) provides necessary information to AP to clarify the issue e.g. gives okay
to bypass the business rule and let the invoice process without VAT no.
3. AP Processor sends the invoice to Vendor Maintenance to initiate the correction of master data.
4. AP Processor potentially involves a tax expert (if different from AP) to clarify on a zero tax rate invoice.
When she gets the okay to process the invoice without tax, she maintains a tax exempt text and continues
with processing.
5. She marks the invoice as obsolete.
There are several possible solutions to handle the Missing Invoice Date and Vendor Invoice Reference
Missing and Missing Mandatory Information exceptions:
1. AP Processor changes index data and validates the changes by simulating the business rules.
2. Completes the invoice with the missing data

3. AP Processor sends the Invoice to Vendor Maintenance to initiate the correction of master data.
4. AP marks the invoice obsolete.
There is only one possible solution to handle the Invalid Requester ID Exception:
1. AP Processor maintains a requester ID. Requester is the first approver when reapplying the business
rules and the invoice is being sent for approval. This exception is setup to assure that the approval will be
triggered with the right requester.
1. AP Processor – Change the index information or communicate with Vendor Maintenance if a new vendor
is required.
2. Vendor Maintenance - maintain/create new master data entries.
3. Tax expert (if different from AP) - In case the AP Processor needs to get special TAX input to resolve or
clarify issues.
Potential Special Requirements:
Prevent posting: All invoices which are processed through VIM-Express will be prevented from posting if
they haven’t gone through an approval successfully. An extension to the SAP FI transactions needs to be
created which will perform the check.
11.3.4 Rescan required
Figure 28 Swimlane for NonPO Rescan Required
Exception:
This exception is manually triggered when AP requests a new scan.
Resolution:
1. Scanner confirms the rescan and triggers a new process.

2. Scanner sets the Invoice to obsolete
1. Scanner – Process the rescan

Not applicable
11.3.5 Non-PO Approval Require
Figure 29 Swimlane for NonPO Approval Required
Trigger/Exception:
AP manually triggers the PO approval flow out of the DP Workflow (“Submit for Approval”). The flow is similar to
the one in VIM. There is a pre-approver step before the financial approvers. The requester pre-approves the
invoice before the financial approvers get the approval work item (from this point on the approval process equals
the one in standard VIM). The requester has the chance to complete accounting information on the invoice in the
same transaction (work item) where she makes her approval decision.
Resolution:
This exception is resolved when the invoice is finally approved by all approvers (with sufficient approval authority).

1. AP Processor has provided as much coding as possible before she triggers the approval flow through
reapplying the business rules. Once the approval is triggered it will be routed to the first approver. The first
approver is going to be the requester as specified in the index data. The subsequent approvers will be
determined based in the COA table entries as for the standard VIM FI approval process.
2. Should the need arise for it the requester may supplement or correct the account assignment entries
(coding) while in the work item of approving the invoice as first approver. If she determines that someone
else has to enter coding info or approve the invoice she delegates the invoice to other user(s).
3. Requester can enter special handling cost settlement instructions for AP.
4. Once a requester approves the invoice the financial approval will start and the invoice is routed to the first
approver as set up in the approval hierarchy (COA).
5. Approval is completed when the last financial approver’s approval limit (as defined in COA) equals or
exceeds the invoice amount.
6. Invoice will be routed for auto posting.
Approval Chart of Authority:
The VIM standard approval authority configuration. Approval conditions in COA:
1. Approval amount
2. Currency
3. Expense type
4. Company Code
5. Cost center
6. WBS element
7. G/L account
All entries can be maintained with wildcards. The standard logic will first try to resolve the most plausible users
according to the wildcard entries.
1. AP Processor - Enters coding info / Resubmits for approval if the invoice is rejected by the requester.
2. Invoice Requester – Enters the accounting data to allocate the cost of the invoice and approves.
3. Invoice Approver(s) – Approve the invoice until sufficient authority level reached.
Potential Special Requirements:
Invoice Requesters custom table: Holds list of requesters with potential conflict of interest in approving
the invoice; in compliance with SOX requirements (segregation of duties).
User Mapping Management: VIM-Express baseline supports web GUI and SAP GUI interfaces.
Baseline supports the user mapping to be managed in two ways:
1. Maintain directly in standard User Map and Chart of Authority tables, maintenance utility provided.
2. Download from other user master sources; to support download program utilizing an API. This download
program has to be created by the client based on client requirements.
Coding fields:

Cost center
G/L account
Project / internal project
Profit center
11.3.6 Non PO Tax Audit Required
Figure 30 Swimlane for NonPO Tax Audit Required
Exception:
Invoice is marked for reviewing by AP before posting. The marking criteria can be dropped down by company
code(s), GL Account(s) and vendor(s) in single or range.
Resolution:
1. Tax Expert provides necessary information to AP to clarify the Issue e.g. gives okay to bypass the
Business rule and let the AP process the Invoice further.
2. AP checks the Invoice, changes Data or gives his okay for further processing by bypassing the business
rule.
3. Hold invoice for clarification from Vendor using the Return to Vendor Option by sending a pre populated
mail out to the Vendor
4. AP sets the Invoice to obsolete.

1. AP Processor – Checks the Invoice for further processing.

2. Tax Expert - provides information to clarify issues.
Configure Invoices to be audited: Maintenance has to be done in a SAP IM Table on Company Code, GL Account
and Vendor. Wildcards and ranges are possible.
11.3.7 Process non PO Credit memo
Figure 31 Swimlane for NonPO Credit Memo Processing
Exception:
This exception is triggered when the invoice is identified as credit memo. AP adjusts the index data to establish
the link between the invoice and this credit memo or triggers an approval flow as she deems it necessary.
Resolution:
1. AP Processor enters credit memo reference number and date and posts the credit memo manually.
2. AP Processor sends the credit memo into an approval process (FI approval process).
3. AP Processor involves other roles to get information about the processing of the credit memo.
1. AP Processor – Processes credit memo
11.3.8 Approval required

Exception:
The VIM standard force normally a four eye principal. This means that the requester, who will do the coding can’t
approve the invoice in one step even his limits are sufficient. After the requester entered the invoice will be send
for approval in parallel to the approvers according to the cost centers and limits.

Resolution:
1. Approver needs to approve the invoice.
1. Approver
11.3.9 Process non PO Invoice
Figure 32 Swimlane for NonPO Processing / Posting
Exception:
This exception is designed to be a default process type. For various reasons, the invoice cannot be posted in the
background automatically. One common reason why auto-posting fails, is due to a closed posting period. In this
case the AP gets the work item with the SAP message which tells him why auto posting failed. She can adjust the
invoice and post it manually. If auto posting is disabled, this exception indicates that all business rules had been
applied successfully and the invoice is ready for posting.
Resolution:
1. AP manually posts the invoice.

2. AP changes Invoice data and checks the business rules again.
AP Processor– Provides input to AP

12 Exception Handling of DP Invoices
12.1 DP Invoice Business rules

Invoices enabled through VIM-Express are tested for several Business rule logics. If any of the Business rule logic
Here is a list of best practice exceptions which will be active within the VIM-X package. Customer specific
enhancement are marked with CS instead of a process number.
DP Meta Data Validation
Invalid Vendor Number Indexed Vendor # is not valid in SAP

910
(DWN)
915 Invalid PO Number (DWN) Indexed PO # is not valid in SAP
920 Invalid Currency (DWN) Indexed Currency is not valid in SAP
Invalid Requester ID Requester email is missing.

923
(DWN)
Vendor Invoice Reference Invoice Reference is missing

925
missing (DWN)

Missing Invoice Invoice Date is missing

930
Date(DWN)
933 Determine Expense Type Runs in Background
Index data will be checked against following fields if there are entries
with similar values the exception will be raised
935 Suspected Duplicate (PO) Vendor Reference

PO Number
Vendor Number
Invoice Date
911 Missing VAT date (PO) Tax Reporting Date is missing
PO not released or
950 Indexed PO # is not released
incomplete
Samples of options:
Auto calculate is enabled but no Invoice tax code is available

Auto calculate is not enabled but Invoice tax amount is blank
965 Invalid Tax Information Invoice tax code and Invoice country (based on Invoice Company
955 Vendor Mismatch (DWN) Indexed vendor # does not match with PO Vendor or PO Partner
Currency Mismatch
975 Invoice currency does not match to PO currency
(DWN)
Missing Mandatory All fields which are set up as required needs to be filled, if not this
980
Information (DWN) exception is triggered.
985 Approval Required (DWN) Single Step header based approval
990 Vendor Audit Required Indexed vendor is marked for special audit in configuration (not auto-

(DWN) posted i.e. certain countries have special treatment for tax) Bypass
possible
Tax Audit Required Indexed invoice is marked for special audit in configuration. Bypass
995
(DWN) possible
12.2 DP Invoice – Document Processing Dates

1. Current System Date Current System
date to be used as the Posting
2. Date on the Vendor Invoice Date
date when creating a SAP 3. Date of the supply of the
Posting data
Invoice Document from a DP Goods or Services
document 4. Scan Date
5. Manual Entry

date to be used while 1. Current System Date
converting the invoice amount 2. Date on the Vendor Invoice
Conversion Date 3. Posting Date Posting Date
from foreign currency to
company code or local 4. Date of the supply of the
currency. Goods or Services
1. Current System Date

This attribute determines the 2. Document Date
date to be used as the baseline 3. Posting Date
Baseline Date date for due date calculation 4. Supply Date Document Date
when creating an SAP Invoice 5. Scan Date
Document" 6. Manual Entry
12.3 VIM-Express DP Exception Handling

The detailed exception handling for down payment exceptions can be reviewed in the chapters Error! Reference s
ource not found. and Error! Reference source not found.

13 Invoice Approval
In VIM Express the approval is configured as approval before posting for Non-PO invoices.
Figure 34 Process Overview – Approval
Trigger/Exception:
When a NPO invoice has gone through all exception handling in the DP workflow leading up to the exception
“Approval required”, the NPO invoice approval workflow will start. This will actually set the DP workflow on hold
until the invoice is finally approved. When invoice is finally approved DP workflow will continue and will auto-post
the invoice in background.
Requesters, approvers can be configured based on cost elements. The requester is determined based on initial
Requester on Invoice. The requester will enter the line item information on the invoice. If the requester cannot
complete the line item information he/she will be able to forward the invoice to another requester. Requester can
also send invoice to a reviewer (requester) as part of the forwarding functionality in this step. The three
possibilities outlined below:
1. Requester knows all line item information, enters it and does not need a reviewer
2. Requester does not know all line item information and forwards it to another Requester to finish it
3. Requester enters the line item information but require a reviewer to review the invoice (Forward)
Once the Requester has entered the coding and reviewed the invoice, then the invoice is sent for approval. The
Requester has the possibility to override an approver as long as the approver is maintained in COA for that cost
assignment. After the approval is made the invoice will be auto-posted.
Invoice Approval process is based on pre-defined level based approval process.
The Approval Limit/Level defines the approval levels and amounts, depending on the Company Code and the
Expense Type.
Each Requester, Approver is maintained in COA table with approval level for a specific cost object. Requesters
and approvers are validated based on information available in COA table.
Once all invoice lines are validated and approved by Requesters invoices is moved for first level of approval.
Definition of Pack: Logical grouping of all Invoice lines a specific approver/requester can potentially approve at an
approval level. Sum of amount in all line items of a pack are compared with amount on approval level.

Invoice lines are automatically grouped into packs based on approvers/requesters maintained to approve invoices
for various cost objects. Pack amount is the sum of different line items assigned to an Approver/Requester per
company code. If the pack amount is approved at a level, then invoice is routed to corresponding approvers if
additional packs available at same level. When all packs (lines) within one level are approved, the next approval
level is processed. If Pack amount is less than approval level amount, then invoice lines corresponding to the pack
are finally approved. Approval is completed when all lines on NONPO invoice are finally approved.
Approvers and requesters can visualise lines that they could approve and lines that are already approved by
various icons against each line.
Approval Limit can be maintained per company code currency or based on a fixed currency.
Trigger
Approval
Requester
enters coding
Declined Back to AP
Decision
Approved
Forward to
other No
Coding
requester
completed /
balance zero
Yes
Determine
Approvers on
Cost Object
and level
Responsible Responsible Responsible

user for user for user for
financial financial financial ….
approval on approval on approval on
line item level line item level line item level
Declined
Decision
Approved
No
All lines
approved on level
Yes
No
Approval for
all level finished
Approval finished
Figure 35 Approval flow

1. Requester- Responsible for reviewing NPO cost coding before the invoice could be financially approved
by approvers.
2. Approvers – Approves the invoice and will not have the possibility to make any changes to cost coding.
Rejection Processing:
There are 3 possibilities to route the approval Workflow when an approver/requester rejects the invoice.
1. One Step Back

2. Back to Initial Requester
3. Terminate Approval Process
13.1 Invoice Approval Portal

Invoices which are pending approval workflow can also be processed in VIM Approval Portal.
VIM Approval Portal can be accessed by each approver by default web browser.
Figure 36 Approval Portal – Overview
Each invoice can be approved and rejected as it is in SAP GUI. Additionally, invoices can be forwarded and
referred to specific users if needed.
Requestors are able to code invoice directly in VIM Approval Portal including coding of GL Account, Cost Center,
Item amount and etc.
13.2 SAP FIORI Architecture

Figure 37 shows you how the FIORI architecture works. You can get access on mobile devices or desktop PC’s
over the Internet on a standard Internet-Browser or get access on premise for example on your workplace in the
office. The FIORI Launchpad has a smart design which can individualized for a smart work experience.

Figure 37 SAP FIORI Architecture
The SAP FIORI Launchpad communicates directly with the installed FIORI Apps. These Apps get and set the data
out of the SAP-ERP-Productive-System. For example, “Approval Invoice” to approve or reject incoming invoices.
With “Enter Cost Assignment” you can enter a cost center or split the costs how they achieved for Non Purchase
Orders.
13.2.1 Invoice Approval via FIORI Launchpad

Invoices pending approval can also be processed via SAP FIORI. VIM FIORI approval application can be
accessed by each approver via FIORI Launchpad.

Figure 38 SAP FIORI Launchpad
Each invoice can be approved and rejected. Additionally, invoices can be forwarded and referred to specific users
if needed. Requestors are able to code invoice directly in FIORI including coding of GL Account, Cost Center, Item
amount etc.
Figure 39 SAP FIORI ApprovalBulleted list

13.3 Approval portal architecture with WAS:
Figure 40 Approval portal architecture
The following requirements must be fulfilled:
SAP NetWeaver 7.0 or higher and WAS (Web Application Server) 7.0 or 7.3
SAP WAS 7.0 SP9 or above with SPNegoLoginModule
SAP NetWeaver Portal (NWP) 7.0 SP9 or above
The requirement “SP9 or above does also refer to the EhP level
The authentication is performed via Active Directory where SPNegoLoginModule picks up the Kerberos certificate
from the Directory. The windows user name and domain will be maintained in an OpenText SAP table. If the user
is maintained in this table an access to the web application is granted else the access is denied.

14 Invoice Posting
VIM-Express provides dialog as well as background posting for invoices.
Figure 41 Process Overview – Invoice Posting
Dialog posting can be done manually when an exception occurs in the last business rules where the option button
Post Invoice is provided to the AP Processor. Therefore, the SAP Standard transactions depending on the Invoice
Type will be called with the invoice data from the indexing screen without any further manual assistance.
In case that no business rules raise an exception Invoice Management will post the invoice in background using
Standard functions provided by SAP. There is no further action by a dialog user required. But in case the posting
fails the process will go into the last business rule. There the user gets the information why background posting
was not successful (e.g. closed posting period).
15 Blocked Invoice Resolution
Figure 42 Overview – Blocking Invoice Resolution
The Blocked Invoice Resolution in VIM Express provides workflows on line item level for price and quantity
discrepancies. This means for each blocking reason on each line a separate workflow is triggered and a work item
provided to an initial actor role.

The dashboard (see Figure 43Error! Reference source not found.) provides all information and options to solve t
he blocking reason.
Figure 43 Blocking Invoice Resolution Dashboard
The option buttons provided can be categorized into action, authorize and refer options.
Action Buttons
Offer the option according to the description given in chapter
Authorize Buttons
Offer the possibility to authorize the role customized behind to perform the according action. This action will be
performed on header level and effect therefore the whole invoice and possibly existing further workflows and
blocking reasons
Referral Buttons
Offer the possibility to refer to a certain role customized behind the refer button
In case one or more blocking reasons are solved by an action performed the workflow(s) are automatically
terminated and the corresponding status is displayed in Invoice Management Analytics.
Next to the workflow based solution it is still possible to solve blocking reasons (e.g. by posting missing GR or
changing price in PO) with SAP Standard options. Depending on the action performed outside and the run of the
SAP-Standard Report RM08RELEASE the workflows are also automatically being terminated and the
corresponding status is displayed in Invoice Management Analytics.

The according customizing per blocking reason of the initial actor role, roles involved in the process and the
buttons is described in the following chapters.
15.1 Price Block handling

A workflow to solve a price block on line item level will be send to the price block agent as initial actor. The Error! R
eference source not found. shows the according option buttons customized for the dashboards per role. Beside
the
Price Block Agent, the roles AP Processor and Info Provider can be involved in the process. For the Info Provider
no separate swimlane is shown, because he always has only the option to enter a comment and send back to the
requesting agent.
Figure 44 Swimlane Price Block Handling
Swimlane Notes:
1 Option Button is only displayed when Purchase Requisition exists
2 OptionButton is only displayed when price difference is in tolerance of 100 % or absolute maximum value
1.000.000 USD
3 Option Button is only displayed when Authorization is given by Price Block Agent

15.2 Quantity block handling

A workflow to solve a quantity block on line item level will be send to the Quantity Block Agent as initial actor.
Error! Reference source not found. shows the according option buttons customized for the dashboards per role. B
eside the Quantity Block Agent, the roles AP Processor and Info Provider can be involved in the process.
For the Info Provider no separate swimlane is shown, because he always has only the option to enter a comment
and send back to the requesting agent.
Figure 45 Swimlane Quantity Block Handling
Swimlane Notes:
1 Option Button is only displayed when Purchase Requisition exists
2 OptionButton is only displayed when price difference is in tolerance of 100 % or absolute maximum value
1.000.000 USD

3 Option Button is only displayed when Authorization is given by Price Block Agent
16 Reports in VIM by OpenText

For reporting purposes and for audit purposes VIM offers some standard reports which need to be customized
and activated.
The reporting tools are very useful. Foundation report is VIM Analytics (VAN).
16.1 VIM Analytics (VAN)

In VAN most data are collected in real time. VIM Analytics (VAN) provides users clear data report on their
documents with exceptions as well as the invoice exception workflows. It is intended to give further ability to track
the documents routed through SAP workflows via the VIM solution.
VAN features include
Statistic on processing
Status report on process metrics
Use standard SAP reporting tool as needed
This is not a productivity report, but a status report that shows various process metrics. It shows the number of
days until the invoice is due and so can help you manage due dates. A negative in the days to due column means
the invoice payment is overdue. VAN does have two different views. One is Document Views the other one is the
Workflow View.
Document View:
Invoice centric reporting: vendor, payment due date etc.

One invoice per line.
Workflow View:
Workflow centric reporting: all tasks, current task and agent etc.
One line per workflow instance.
Below are the standard fields available in VAN report for Document View.
1. COMPANY_CODE Company Code 7. REF_DOC_NUM Reference document number
2. DOC_NUM Accounting document number 8. DOC_STATUS_CODE Document Status
3. FISCAL_YEAR Fiscal year 9. DOC_DATE Document date in document
4. DOC_LINE Document Line Item 10. EXCEPTION_DAT Exception Date
5. DOC_TYPE SAP Document Type 11. TOTAL_AMOUNT Doc Amount
6. VENDOR_NUM Vendor Number 12. DOC_CURRENCY Doc Currency

13. REVERS_DOC_NUM Accounting document 41. VENDOR_NAME Vendor Name

number
42. BLOCK_PARK_FLAG Block flag
14. REVERS_DOC_FY Fiscal year
43. DOC_STATUS Document Status Text
15. CREDITMEMO Credit Memo flag
44. POST_DATE Post Date
16. DOCID DP Document Number
45. OLD_DOC_NUM Document number
17. DP_DOCTYPE DP Document Type
46. OLD_FISCAL_YEAR Fiscal year
18. DUE_DATE Due date
47. OLD_COMPANY_CODE Company Code
19. ENTRY_DATE Document entry date
48. PROCESS_DURATION Cycle Time
20. ENTRY_TIME Time of entry
49. DP_PROCESS_TYPE DP Process Type
21. START_DATE Document entry date
50. RESCAN_REASON Rescan Reason
22. START_TIME Time of entry
51. DELETE_REASON Obsolete Reason
23. END_DATE Document entry date
52. TARGET_SYSTEM System ID
24. END_TIME Time of entry
25. PARK_REASON Parking Reason
26. REQUISITIONER_ID Requisitioner ID
27. UPDATE_DATE Update date
28. UPDATE_TIME Update time
29. BLOCK_REASON Exception Reason
30. LINE_AMOUNT Doc Line Amnt. in Rpt.
31. GR_TOTAL_AMOUNT Gross Amnt.
32 GR_LINE_AMOUNT Gross Line Amnt.
33. GR_CURRENCY Gross Currency
34. REASON_TEXT Reason text
35. BAL_DAYS Days to Due Day
36. OVERDUE_FLAG Overdue
37. PO_DOC_NUM Purchasing Document No.
38. PO_DOC_LINE Purchasing Document Line
39. PLANT_NUM Plant
40. PURCH_GROUP Purchase group

Below are the fields in VAN for Workflow View
1. WI_ID Work item ID
2. CURR_AGENT Current Agent
3. CURR_ROLE Current Role
4. WI_STATUS Processing status of work item
5. MULTIPLE_AGENTS Indicator that there are multiple agents
6. LAST_OPTION_TYP Last selected Option Type
7. LAST_OPTION_ID Last Selected Option ID
8. TASK_ID Workflow Task ID
9. OPTION_TEXT Last selected Option text
10. AGENT_FIRSTNAME First name
11. AGENT_LASTNAME Last name
12. WI_STATUS_TEXT Work Item Status Text
The VAN report does also have data synchronization feature. Because it is possible to make changes to parked and posted
SAP, the VAN tables must be updated with those changes. These changes include:
Parked document:
Changes to all the changeable fields including amount, account assignment, (coding), and text fields.
Posted document:
All the SAP change rules apply. Unless there are customer specific change rules in place, this means the only allow
fields that do not update an account balance anywhere in SAP. These are generally text fields.
Style List Bullet 1 for the first level of a bulleted list. Style List Bullet 1 for the first level of a bulleted
list.
Style List Paragraph for an indented paragraph in a list.
Style List Bullet 1 for the first level of a bulleted list. Style List Bullet 1 for the first level of a bulleted
list.
Style List Bullet 2 for the second level of a bulleted list. Style List Bullet 2 for the second level of
a bulleted list. Style List Bullet 2 for the second level of a bulleted list.
Style List Paragraph 2 for indented paragraph on second level.

Title here
16.2 VIM reminder Reports

Second report in VIM is the VIM Reminders Report which:
Sends collective emails notifications to users with overdue work items.

Does not forward work item – only notification for action sent.
One can use various selection criteria
Collective Reminder is planned once a day (VIM - DAILY NOTIFICATION RUN).
Reminder email text setup can be maintained in SO10 transaction. As outgoing emails are not enabled in SOST
have to be viewed in SOST and send by an administrator from there. Administrator can find one mail with my recip
Notifications per invoice have to be maintained individually by user
Transaction code is:
/OPT/REMINDER
16.3 Liability Report

The third report in VIM Express is the Liability Report. The user of this report can create the report based on specific search
group by company code, vendor, cost center etc. There is also possibility to create the report on document type or docume
The transaction code for this report is:

/OPT/VAN_LIABILITY
The Information Company™ 73

Title here
Figure 46 Liability Report
The output of the search criteria´s is shown below.
Figure 47 Output –search criteria’s
16.4 Central Reporting

In VIM Express package one can find other reporting tool which is more related for audit purposes and that is why these re
central reporting.
Transaction Code: /OPT/VIM Report –> Central Reporting.
Following reports can be found and will be briefly described:
Aging Report
Audit Report
Exception Analysis Report
Key Process Analytics
License Report
Productivity Report

Title here
16.4.1 Aging Report

The benefits of this reports is that it reports about the aging of documents and work items in the current system.
It comprises following features:
Provides an overview of the processing times of documents that have not been posted without error.
Provides a snapshot of documents that have not been posted and are still work in process.
Provides a snapshot of work items that are still work in process.
Allows displaying a detailed list of:
Documents still in process, grouped by document type,
Work items still in process, grouped by role.
Figure 48 Aging Report
16.4.2 Exception Analysis Report

Reports all work items with exceptions, grouped by exception, company code or vendor.
Business view provides:
Finds and tracks exceptions with the highest impact on your business.
Monitors how often exceptions occur.

Title here
Finds companies or vendors who cause the highest number of exceptions.

Indicates the invoice amount that is affected by work items with exceptions.
Technical view provides:
grouping by exception, vendor or company code

an overview of the processing times (average) and wait times (average) per exception
a sum of gross amounts related to the work items
an analysis of the average number of touches per work item with exception
an analysis of the average number of referrals per work item with exception
a comparison of exceptions of a freely selectable period to a comparison period
a detailed list of work items with exceptions (by double-click)
Figure 49 Exception Analysis Report
16.4.3 Key Process Analytics

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.
Report panels highlight the following aspects:
Total Liability
Processed / In Process Documents
Channel Analysis
First Pass

Title here
Top Exceptions by Count.

Top Vendors by Amount
Figure 50 KPI Report
16.4.4 License Report

The licensing report is to print a report of number of invoices processed through VIM by customer in all
channels in a given time period and send the report to Open Text or SAP.

Title here
Figure 51 License Report
16.4.5 Productivity Report

Productivity report is used to get reports about the productivity of users/roles and the activities of
users/roles.
It comprises the following features:
Provides an overview of the processing times (total and average) and wait times (average) per
user/role.
Enables the comparison of productivity of a freely selectable period to a comparison period.
Provides a snapshot of reserved and in process items per user/role.
Enables the analysis of the average number of touches (per invoice) of users/roles.
Enables the analysis of the average number of referrals (per invoice) of users/roles.
Allows displaying a detailed list of:
documents processed by a single user/role
currently reserved items of a single user/role
currently processed items of a single user/role

Title here
Figure 52 Productivity Report
For further details and information about each report please read the VIM user guide.
17 Authorizations
VIM 7.5 is delivered with a number of authorization objects in order to control the following objects:
VIM Index Data Screen

J_6NIM_BC1 – (Checks only Company Code)
Activities: Change, Display
VIM Reporting
J_6NIM_BUK – (Checks Company Code, Logical System)
Activities: Display
COA Maintenance
J_6NIM_CA1 – User Map (Checks only User Group)
J_6NIM_CA4 – Approval limits (Checks only company code)
J_6NIM_CA5 – Approver list (Checks user group & company code)
J_6NIM_CA3 – Coder details (Checks user group & company code)
Activities: Create, Change, Display
VIM Workplace
For VIM Workplace there are a number of authorization objects which controls this transaction,
these are listed in the attached excel-file:

Title here
VIM Workplace
Authorisation Checks.xlsx
The authorization objects controlling the above areas are controlled by a global constant in table
/PTGWFI/Z_CONST. If switched on, it means that all these authorization objects need to be
maintained in authorization profiles. If a single one is not to be used, it can be maintained with
* in order to be applicable for all values.
Customers have to include and consider above authorisation objects to their existing roles.
18 Imaging Enterprise Scan

18.1 Imaging with Enterprise Scan
Enterprise Scan is a high-performance scan client, which enables the digitization, indexing, and archiving
of large quantities of paper documents.
Figure 53 Imaging with Enterprise Scan
Enterprise Scan is used to scan large quantities of paper documents at a centralized scan center. This
high-performance scan client enables the digitization, indexing, and archiving of documents.
Enterprise Scan enables users to capture black and white and colour documents from scanners via
Image and Scanner Interface Specification (ISIS) or Kofax Virtual Rescan (VRS), and fax via Microsoft
Exchange or Lotus Notes, file system, or from an external storage device. Output formats are TIFF,
JPEG, JPEG2000 or PDF, searchable PDF, PDF/A and searchable PDF/A.
With the high quality of modern scanners and well-prepared profile management by the Enterprise Scan
administrator, manual post-processing steps are rarely necessary. Most of the post-processing is already
performed automatically during scanning. However, if required, Imaging Enterprise Scan offers a

Title here
complete toolkit
of image manipulation and correction functions such as: rotate, sort, separate, and join document pages;
change index; homogenize colours; archive documents in the Archive Server; and import document links
into the SAP system.
User interface of Enterprise Scan presented on the figure below:
Figure 54 Enterprise Scan GUI
18.2 Key features of Enterprise Scan

Suited for low, medium, and high-volume scan scenarios, easily scaling from hundreds to many
thousands of documents per day, and across multiple departments to accommodate to entire
enterprise.
Ability to support complex business processes by integrating with and initiating SAP Workflow or
Enterprise Server workflows.

Title here
Supports all SAP ArchiveLink document storage scenarios (early/late, with or without barcode)
Enhanced integration with OpenText Content Server including single sign on between
applications and indexing based on category and system metadata.
Integration with Exchange and Lotus Notes fax connectors
Automatic document separation (blank page, barcode, patch code, page number, file name)
Manipulation of images (crop, colour, grayscale, deskew, despeckle, dpi, smooth, delete, rotate)
and documents (separate, join, merge, reverse order)
Classification into groups of documents manually, based on barcode or on patch code
Export/import from/to file system or external storage
Powerful document indexing capabilities
18.2.1 Document separation

An important task for the scanning operator is to ensure that the pages are properly sorted into
documents. When a batch of several documents is scanned it enters Enterprise Scan as a sequence of
pages. The software needs to find out where one document starts and the next one begins. This can be
done automatically based on certain features of a page. Typical arrangements are: Patch code sheets
between documents, barcodes on the first page or blank pages between documents.
If the document structure need correction the operator can move pages between documents, split or
merge documents. The documents can be structure by folder and / or batches and a group attribute can
be assigned which denotes a certain document class.

Title here
Figure 55 Document Separation
18.2.2 Page enhancements

Today’s scanner produces high quality images. However sometimes tweaking is still required. Enterprise
Scan provides a full set of image enhancements functions like:
Image enhancement through intelligent processing algorithms

Colour to B/W conversion
Automatic and manual processing
Erase page, mark for deletion, quality marker

Title here
Figure 56 Page Enhancements in Enterprise Scan
18.2.3 Barcode recognition

Barcode can be used to separate documents as well as barcode value can be used as index value for the
document. Most barcode types are supported. 1D barcode recognition is part of the Enterprise Scan
installation. A 2D barcode is available from a partner and can be easily purchased an installed.
Figure 57 Barcode Recognition within Enterprise Scan

Title here
18.2.4 Document indexing

Document Indexing for pre-indexing of scanned documents (for example, in a Shared Service Center),
Enterprise Scan provides a set of sophisticated pre-indexing capabilities, including:
Pick lists and dependant pick lists can be filled with values originating in OpenText Document
Management, SAP solutions or other systems.
A rectangular zoom area is shown in addition to the full page view.
Support for integrated SAP and OpenText Document Management systems with single sign-on
between applications and indexing based on custom and system metadata.
Zonal OCR allows you to send a part of the scanned document to an OCR/ICR engine and then
reuse the OCR result for document indexing in Enterprise Scan
Integrated barcode recognition
Full scripting capabilities (JScript .NET) support the indexing process
18.2.5 Scripting
Although Enterprise Scan’s set of functions is very complete there are always special situations and
project specific requirements. Using Jscript.Net the functions can be extended. A typical example would
be to implement a business rule that the content of a field has to follow a specific syntax.
There are several times where scripting functions are called: When a page is picked up from the scanner,
before a batch of documents is released and during interactive mode when a user accesses an index
field.

Title here
Figure 58 Scripting in Enterprise ScanClient

Title here
Figure 59 Enterprise Scan as part of an OCR solution
18.3 Document Pipeline

For ease of installation and administration it is possible to use a document pipeline that is running
remotely on a server. A local installation of document pipelines is no longer necessary.
Connection is done via HTTP no file shares are necessary

Several scan stations use typically the same document pipeline host
Communication is protected by checksums and SSL to prevent manipulation and loss
Figure 60 Centralized Document Pipeline
19 Document archiving and viewing

architecture
VIM Express by OpenText does also include the viewer. The viewer will be installed on local clients for
each user who wants to see the scanned and archived image during the workflow. Since the user is not
going to see the physical invoice, the viewer will retrieve the archived image each time the user wants.
Below is the architecture, which describes different way for the document to enter VIM and the image
archival/ retrieval.

Title here
Figure 61 Document archiving and viewing
Regarding the archival of documents, three basic variants can be distinguished.
Paper documents are scanned first; this is normally done using the scanning application Enterprise
Scan. The resulting image files are then transferred to the Archive Server for archival.
Machine-generated documents can be archived directly from the generating server to the Archive Server
via a specialized interface — provided that such an interface exists for that application system. The
“classical” example for this type of archival is archiving from SAP R/3 (outgoing documents and print
lists).
Document files from external sources are archived via the so-called batch input interface of the Archive
Server. This is the most generalized way of archiving: The documents may origin from any leading
application — there is no special integration interface necessary. Moreover, scanned images of paper
documents can be archived that way as well as machine-generated documents.

Title here
Document retrieval is carried out the same way, no matter how the documents have entered the archive
(as detailed above): The retrieval client component downloads the document from the Archive Server to
the user’s workstation, then the document is displayed in a suitable viewing application.
19.1 Imaging Windows Viewer

The Imaging Windows Viewer by OpenText is fully integrated into SAP IM. Each time the user wants to
display the archived image this is possible.
The figure below shows a screenshot from the windows viewer and its functionalities:
Figure 62 Windows Viewer

Title here
The Imaging Windows Viewer allows users to:
Display documents
Zoom / scroll / turn pages
Work with documents
Add notes
Annotate
Search print lists for text (free/attribute)
Print / send via e-mail

Title here
Glossary
COA Approval chart of authority
PO Purchase Order
ArchiveLink Service integrated in the SAP WAS for linking archived

documents
ArchiveLink document types Document types that need to be customized for ArchiveLink
BAdI Business Add-Ins (BAdI) is a new 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.
Baseline Set of functionality with pre-defined configuration
BTE Business Transaction Event (BTE) used for extending a Non PO

invoice functionality to call a custom program
Business rules Rules that describe the operations, definitions and constraints
that applies to an organization.
Coding Coding allocates an invoice to G/L account, cost object, etc. if

required.
Dashboard User interfaces that organizes and presents information in a way

that is easy to read. Users can also perform actions from the
dashboard.
(DP) Document Processing SAP IM 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
Exception Action that is not part of normal operations or standards
FI SAP module for the Finance and Accounting department
Indexing Process of entering or storing data into the system
(IAP) Invoice Approval SAP IM component that enables users to perform coding,
approving and rejecting of invoices
(ICC) Invoice Capture Center SAP IM OCR component

Title here
Invoice coder Person who enters the accounting info on invoices to allocate
the cost
(IE) Invoice Exception SAP IM component that handles the exceptions that arise after a
SAP invoice is created
Invoice requester Person who requested goods and services for Non PO invoices
(LIV) Logistic invoice Invoices related to a purchase order
(MM) Materials Management SAP MM is the materials management module of the SAP ERP
software package. Materials management is used for
procurement and inventory management.
Non PO Invoice that is not based on a Purchase Order
OCR Optical character recognition. Mechanical or electronic

translation of images of handwritten, typewritten or printed text
(usually captured by a scanner) into machine-editable text
SAP IM Packaged business solution that solves a business problem –

paying correct amount to vendor’s on-time and with the lowest
cost. SAP IM delivers not technology but best-practice business
processes. SAP IM provides values to customers in process
efficiency, visibility and compliance.
Price discrepancy Situation where the price on the invoice is different from the price
in the purchase order
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.
Quantity discrepancy 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
Swimlane Diagram representing a specific SAP IM process. A Swimlane

comprises the process description, roles, user interface and
options of the process.
(VAN) SAP IM Analytics SAP IM component that gives users a clear data report on their
invoices in progress. SAP IM Analytics allows to track the
documents routed through SAP workflows via SAP IM.

Title here
Workflow SAP business workflows can be used to define business

processes that are not yet mapped in the R/3 system.
WAS Web application Server
© 2017 OpenText
All rights reserved, including reproduction, copying or communication of the contents of this document or
parts thereof and accompanying software. No part of this publication may be reproduced, transmitted to
third parties, processed using electronic retrieval systems, copied, distributed or used for public
demonstration in any form without the written consent of OpenText Corporation. OpenText Corporation
reserves the right to update or modify the contents. Any and all information that appears within
illustrations of screenshots is provided coincidentally to better demonstrate the functioning of the
software. OpenText Corporation hereby declares that this information reflects no statistics of nor has any
validity for any existing company.
SAP®, R/3® SAP BI® and SAP CRM® are registered trademarks of SAP AG.
Microsoft®, Microsoft Windows NT® and the names of further Microsoft products are registered
trademarks of Microsoft Corporation.
Other product names are used only to identify the products and they may be registered trademarks of the
relevant manufacturers.
About OpenText
OpenText enables the digital world, creating a better way for organizations to work with information, on
premises or in the cloud. For more information about OpenText (NASDAQ: OTEX, TSX: OTC) visit
opentext.com.
Connect with us:
OpenText CEO Mark Barrenechea’s blog
Twitter | LinkedIn | Facebook

OpenText VIMX FDD

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

OpenText VIMX FDD

Caricato da

Copyright:

Formati disponibili

Functional Design

ENTERPRISE INFORMATION MANAGEMENT 2

10 Exception Handling of PO Based Invoices ................................................. 31

ENTERPRISE INFORMATION MANAGEMENT 3

16.4.4 License Report .............................................................................. 77

ENTERPRISE INFORMATION MANAGEMENT 4

Figure 1 Service Suite for VIM Implementations ........................................................................................................ 7

ENTERPRISE INFORMATION MANAGEMENT 5

Figure 53 Imaging with Enterprise Scan ................................................................................................................... 80

ENTERPRISE INFORMATION MANAGEMENT 6

1 Purpose of Functional Design Document

OpenText Professional Services.

Figure 1 Service Suite for VIM Implementations

ENTERPRISE INFORMATION MANAGEMENT 7

2 SAP VIM Functional Architecture

Following is an overview of SAP VIM process architecture:

The SAP invoice management process consists of 4 main steps:

ENTERPRISE INFORMATION MANAGEMENT 8

Figure 3 VIM System Landscape

ENTERPRISE INFORMATION MANAGEMENT 9

3 VIM-Express Vendor Invoicing Process

Figure 4 VIM Express Process Overview

ENTERPRISE INFORMATION MANAGEMENT 10

Standard VIM-X roles cover the following:

ENTERPRISE INFORMATION MANAGEMENT 11

4 General Decisions Summary

Single system environment in place (Dev / QA / Prod)

5 Document Processing Workflow

ENTERPRISE INFORMATION MANAGEMENT 12

Figure 5 IM Document processing overview

5.1 Invoice Entry

5.2 Document Archiving

5.3 DP Workflow Interface

5.4 Invoice Recognition

ENTERPRISE INFORMATION MANAGEMENT 13

ENTERPRISE INFORMATION MANAGEMENT 14

4. Automatic document type determination

5.6 Invoice Verification

ENTERPRISE INFORMATION MANAGEMENT 15

Figure 7 DP Dashboard- Indexing pane

5.6.2 Role resolution

5.6.3 Validate Metadata

ENTERPRISE INFORMATION MANAGEMENT 16

5.6.4 Duplicate check

5.6.5 Exception Handling

Business rules perform the following

Validate Index values for format and validity conformance

5.7 Blocking Invoice Resolution

ENTERPRISE INFORMATION MANAGEMENT 17

Figure 8 Process Overview – Invoice Entry

6.1 Paper Entry

6.1.1 Archive Document Types

ZVIMxxxxRP - VIM Incoming Invoices xxxx

6.1.2 OAWD configuration

ENTERPRISE INFORMATION MANAGEMENT 18

Figure 9 OAWD Paper Entry

1. Prepare paper batches.

Every new invoice starts with a separator sheet or barcode sticker.

2. Sort paper batches using company codes.

3. Scan batch for one company code.

4. Do image manipulations if necessary using Enterprise Scan.

5. Call SAP transaction OAWD.

Choose mass entry to input all scanned batches.

Chose single entry to input only first batch of invoices.