VIM 7 5 Upgrade Guide

OpenText Vendor Invoice Management
Upgrade Guide
Version 7.5
May 8, 2015
VIM 7.5 Upgrade Guide 1

Contents
OpenText Vendor Invoice Management Upgrade Guide ............................................................................. 1
1 Getting started ...................................................................................................................................... 4
1.1 VIM versions supported for the upgrade...................................................................................... 4
1.2 Introduction: upgrade goals and options ..................................................................................... 4
1.3 Overview of VIM 7.5 new and obsolete features ......................................................................... 5
1.4 Overview of upgrade activities ..................................................................................................... 6
1.5 Related documentation ................................................................................................................ 7
2 VIM 7.5 new features............................................................................................................................ 8
2.1 New document types .................................................................................................................... 8
2.1.1 Excluding a country from a business rule ............................................................................. 9
2.1.2 Using different line item matching procedures for different countries or company codes
if using the global doctype .................................................................................................................... 9
2.1.3 Defining roles per country .................................................................................................... 9
2.1.4 Assigning multiple archive link document types based on country ................................... 10
2.1.5 Changing the ArchiveLink document type of a document.................................................. 10
2.2 New Indexing Screen................................................................................................................... 10
2.2.1 Migrating the VIM standard fields ATTRIBUTE1 - 4 and CUSTOM_FIELD4 – 0 ................... 11
2.2.2 Handling other missing VIM standard fields e.g. XMLVERS ................................................ 12
2.2.3 Is the country specific sub-screen still supported? ............................................................. 12
2.2.4 What about the two fields PO_List and DN_List which have been removed from
/OPT/VIM_1HEAD? ............................................................................................................................. 12
2.2.5 Using the new indexing screen for old document types .................................................... 13
2.3 Business Rule Framework ........................................................................................................... 13
2.4 New VAN Report ......................................................................................................................... 13
2.5 New Approval approach ............................................................................................................. 13
3 Obsolete features ............................................................................................................................... 14
3.1 Country-specific document types ............................................................................................... 14
3.2 Old COA & simple, manager-based approval workflow ............................................................. 14
3.3 Old indexing screen..................................................................................................................... 14
3.4 VIM Analytics .............................................................................................................................. 14
3.5 Integrated Invoice Cockpit .......................................................................................................... 14
4 Upgrade options ................................................................................................................................. 15
4.1 Technical upgrade using version switch ..................................................................................... 15
4.2 Options for existing processes .................................................................................................... 15
4.2.1 Existing DP processes .......................................................................................................... 15
4.2.2 Existing approval processes ................................................................................................ 15
4.3 Functional Migration Areas......................................................................................................... 16
4.3.1 Implications of Business Rules Framework and Logic Modules.......................................... 16
4.3.2 Business rule 113 – “Manual Check Needed / Missing Data for Indexing Lines”. .............. 18
4.3.3 PO_LIST and DN_List ........................................................................................................... 18
5 Post installation activities ................................................................................................................... 19
5.1 Recommended sequence of post-installation steps ................................................................... 19
5.2 Migration tool/steps documentation ......................................................................................... 19
5.2.1 Document type migration ................................................................................................... 19
5.2.2 COA migration ..................................................................................................................... 26
5.2.3 Approval Workflow Migration Tool – Report for mass approval actions ........................... 34
5.2.4 VAN Migration Report......................................................................................................... 46
5.2.5 Workplace Migration Report .............................................................................................. 52
6 Contact Information............................................................................................................................ 57

1 Getting started
1.1 VIM versions supported for the upgrade

Upgrade packages are available for upgrading from VIM 6.0 or VIM 7.0 to VIM 7.5. Direct upgrade from
versions older than 6.0 is not supported.
Upgrading from VIM 6.0 SP2 and older versions/SPs has some specifics in regard to the processing of the
workflows started before the upgrade using VIM Workplace and reporting on those workflows in the
new 7.5 VIM Analytics report. Please see the sections describing corresponding migrations steps later in
this document.
We recommend upgrading to the latest VIM 7.5 SP currently available. You can perform the SP
installation in the same step as the installation of the upgrade package with SAP’s SAINT environment.
Please note that you will still have to perform post-installation steps for each additional SP you are
installing.
1.2 Introduction: upgrade goals and options

Upgrading to VIM 7.5 gives your project many benefits, including a new support lifecycle frame and
getting new features that may allow you to optimize the way your organization works with VIM.
Additionally, new features may help you to eliminate some existing extensions, thus reducing the costs
of running the software (when compared to standard).
An upgrade involves several steps. Whether all of them are necessary depends on your project needs.
The corresponding section describes different ways to perform the upgrade depending on the goals you
set.
There are two major upgrade options. Both have potential effect only on the Document Processing
component of VIM. The other modules like Approvals, Parked or Blocked process are not affected by the
upgrade (apart from the obsolete features).
The simplest option is to perform a purely technical upgrade to VIM 7.5 without migration to the new
business rules framework / logic modules (BRF/LM) functionality. This allows you to benefit from the
new support lifecycle time frame, get the latest fixes, and potentially start using new features that do
not require a full upgrade. A technical upgrade involves installing upgrade packages, performing the
post-installation steps, migrating document type and indexing screen settings (in case pre-7.0 document
types and screens are used) and setting a technical version switch (a new Z-constant) that makes 7.5
behave in the same way as 7.0 in terms of BRF/LM.
In general, if you are upgrading a VIM 6.0 system to VIM 7.5, it will include many steps you would do
when upgrading to VIM 7.0. If a 7.0 system is being upgraded, many steps will not be necessary. For
example, if you are using the new 7.0 indexing screen and new document types, the settings for those
will not need to be migrated. However, the business logic will be affected in case you do a full migration.
Please note that even if you perform a technical upgrade only, it does not reinstate VIM features that
are declared obsolete. You may choose to continue using them however, although OpenText does not
provide development support for them anymore.
A full upgrade means that you perform a technical upgrade, with the exception of the technical version
switch, thus making the BRF/LM functionality fully active for your document processing. In this case,
even documents of old (migrated, pre-7.5) DP document types will be processed using the new BRF/LM
logic. While you can keep the old process types running for the old document types, the logic modules
will always be called depending on the customizing settings (with some LMs called for all document
types regardless of the migration status).
If you decide to fully use the new BRF/LM logic, you have to perform a full upgrade. It is not possible to
let some processes run in 7.0-fashion, while others use the BRF/LM.
The Business Rules Framework and Logic Modules are described in detail in the VIM 7.5 configuration
guide. The upgrade aspects of BRF/LM are described later in this upgrade guide.
1.3 Overview of VIM 7.5 new and obsolete features
VIM 7.5 New features:
 New baseline DP document types configured for use with the new indexing screen and standard
configuration of Business Rules Framework / Logic Modules.
 New VIM Analytics report (VIMI-10922)
 Automatic Posting (VIMI-12814)
 Business Rule Framework (VIMI-10179)
 Logic Modules (VIMI-10178)
 Single Click Entry Integration (VIMI-10467)
 Invoice references for credit memos (VIMI-3480)
VIM 7.5 Obsolete features:
The following features have been discontinued in VIM7.5
 Old VIM Analytics available in VIM 7.0 and earlier versions: Use new VIM Analytics released in
VIM 7.5 SP1.
 Old COA –Chart of Authority available in VIM 7.0 and earlier versions, for Non-PO invoices: Use
new COA released in VIM 7.0 SP1/SP2.
 Old Simple /Manager Approval Flow available in VIM 7.0 and earlier versions, for Non-PO
invoices: Use new Approval Flow released in VIM 7.0 SP1/SP2.
 Old Indexing available in VIM 7.0 and earlier versions: Use new Indexing released in VIM 7.0
 Integrated Invoice Cockpit (IIC) available in VIM 7.0 and earlier versions: Use VIM Workplace
released in VIM 7.0
 Old UI of Web Portal available in VIM 7.0 and earlier versions: Use New UI of Web Portal
released in VIM 7.0 SP2.
For complete information refer to OpenText Vendor Invoice Management 7.5 documentation.
1.4 Overview of upgrade activities
Installation of the upgrade package
VIM 7.5 contains of six ABAP add-on components with one to three packages each and of two non-ABAP
components. Only the main component (OTEXVIM) is mandatory, the other components are optional.
The installation of Vendor Invoice Management 7.5 is described in OpenText Vendor Invoice
Management for SAP Solutions 7.5 -Installation Guide (VIM-IGD).
Post installation activities
To ensure the integrity of the installed transports, you must perform and validate the following
procedures:
 Activating Business Configuration Sets

 Maintaining Number Ranges After Upgrade
 Checking the BTE Handler Modules Configuration
 Checking Status and Runtime Behavior of BAdIs for Invoice Processing
 Installing Transport with Layout Variants
 Populating Invoice Transaction Field VORGANG for Credit Memos
 Removing Obsolete User Process Option 2742
 Copying Standard Text /OPT/VIM_RTV_EXAMPLE to Client
 Checking settings for PDF History Log
For complete information of post installation activities please refer to OpenText Vendor Invoice
Management for SAP Solutions 7.5 -Installation Guide (VIM-IGD).

1.5 Related documentation
The following documentation is available for VIM in the OpenText Knowledge Center
(https://knowledge.opentext.com/knowledge/cs.dll/Open/10151494) (KC):
 Open Text Vendor Invoice Management for SAP Solutions - Installation Guide (VIM-IGD): This
guide describes the installation of all VIM components.
 Open Text Vendor Invoice Management for SAP Solutions - Configuration Guide (VIM-CGD): This
guide describes the technical aspects of configuring VIM.
 Open Text Vendor Invoice Management for SAP Solutions - Administration Guide (VIM-AGD):
This guide describes the technical and functional aspects of administering VIM.
 Open Text Vendor Invoice Management for SAP Solutions - User Guide (VIM-UGD): This guide
describes the typical tasks for end users in VIM.
 Open Text Vendor Invoice Management for SAP Solutions - Scenario Guide (VIM-CCS): This guide
describes functional and technical scenarios of VIM.
 Open Text Vendor Invoice Management for SAP Solutions - Reference Guide (VIM-RGD). This
guide collects reference information for VIM.
 Upgrade FAQ (VIM 7.0 documentation set)

2 VIM 7.5 new features
2.1 New document types

The document type is the key object in the DP component of VIM. The document type holds key
information about how the document is created in the system (from external data using OCR or manual
entry etc.), Invoice Type etc. OpenText provides standard document types for most scenarios in VIM.
New global document types for VIM 7.5 can be customized to a characteristic in several aspects (mainly
business rules and screens).
In our baseline, the characteristic is the country. So in general, the attributes of the country specific
document types of the older VIM version can be adopted easily to the global document types. However,
attributes in the main screen configuration of the document type definition cannot be switched by
characteristics. So if you have country-dependent differences in these settings, you have to use
dedicated document types, or you have to handle the differences in available exits.
VIM 7.5 SP2 introduces the new report /OPT/VIM_IDX_UPD. The report updates the configurations in
the areas of document type and indexing screen for existing VIM 6.0 document types in a VIM7.5
environment and reduces the effort of manual entries in configurations.
The report updates the following configuration areas for the following document types.
PO document types:
 Updates main screen configuration for document types.

 PO line automation
 Index screen options
 Index item configurations
NPO document types:

Down Payment types:

The report /OPT/VIM_IDX_UPD will be used after post-upgrade. For technical details of this report, see
section 5.2: Migration Tool/Steps Documentation.

Note the following additional points to be considered while upgrading to VIM 7.5 document types:
2.1.1 Excluding a country from a business rule

Maintain Process Types and activate “Characteristics Check”.
Add the process type for the selected country in ‘Characteristic Specific Document type Configuration”
and deactivate it.
Add the process type for all other countries in ‘Characteristic Specific Document type Configuration” and
activate it.
2.1.2 Using different line item matching procedures for different countries or company
codes if using the global doctype
You cannot do that by configuration. It is possible to configure different logic on document type level.
2.1.3 Defining roles per country

You must define a new attribute for delegated sub-object of /OPT/V1001 that refers to country field of
characteristic determination (in baseline /OPT/VIM_1HEAD-LAND1). If the new attribute is available, you
are able to create a new template based on country.
Alternative: Use company code ranges within existing company code profile. Also VIM determines the
country by company code in characteristic determination. You are more flexible with company code
approach.

2.1.4 Assigning multiple archive link document types based on country
You need to specify the OAC2, OAC3 and SOA0 entries per country. At the time of archiving in OAWD,
the user has to choose the correct entry. Now the document type determination procedure is taking
over to determine the correct VIM document type. The ArchiveLink mapping table in the document type
configuration can contain multiple archive document types.
Starting with 7.0 SP3, the ArchiveLink mapping table in the document type configuration will contain a
country column. So the archive document types can be configured per country. If the country is
changed, the archive document type will be adjusted automatically.
2.1.5 Changing the ArchiveLink document type of a document

You cannot do this, if the ArchiveLink document type is associated to a global DP document type.
There is no function in VIM to changing ArchiveLink document types of a document directly. An indirect
change of the ArchiveLink document type is possible by changing the DP document type, if you have a
1:1 assignment between document type and archive document type. Starting with 7.0 SP3, a dynamic
adjustment of the ArchiveLink document type according to country can be configured.
2.2 New Indexing Screen

VIM 7.0 introduced a completely new indexing screen (DP Dashboard). New installations of VIM 7.0 and
higher versions will use the new indexing screen. The old indexing screen of versions prior to 7.0 will not
be used any more after upgrading to VIM7.5.
For upgrading to the new indexing screen, VIM 7.5 SP2 introduces the new report /OPT/VIM_IDX_UPD.
The report updates the configurations in the areas of document type and indexing screen for existing
VIM 6.0 document types in a VIM7.5 environment and reduces the effort of manual entry in
configurations. Please refer to section 8.2 Migration Tool/Steps Documentation for execution of this
report. Perform the following task after upgrading the new indexing screen.
For PO document types, select the Show Match check box in the Index Screen Options for all processes
with role PO_AP_PROC.

Note: the screenshot does not show all occurrences!
Note: It is recommended to select this check box also for role PO_BUYER.
Note the following additional points to be considered for the new indexing screen:
2.2.1 Migrating the VIM standard fields ATTRIBUTE1 - 4 and CUSTOM_FIELD4 – 0

With 7.0 SP2, a new tab is delivered (Tab 6) on the index screen that can be configured within the
document type. Once the configuration is available, the tab “Other Data” will be available. In baseline
the fields Attribute 1-4 and Custom_field4-0 are provided (Program /OPT/SAPLVIM_IDX_UI and Screen
1900). The tab can also be used to integrate custom fields within an own screen.

2.2.2 Handling other missing VIM standard fields e.g. XMLVERS
The field XMLVERS does not exist in the standard indexing screen. If you need it, integrate it based on
screen 1900.
2.2.3 Is the country specific sub-screen still supported?

The sub screen that can be configured within the country specific configuration is no longer supported
for the new indexing screen. Now it is possible to configure all screen fields on characteristic (country)
level and it is also possible to overwrite logic in a very simple way within a screen exit. With the class
model and the custom tab, the new index screen provides all possibilities of extensions.
2.2.4 What about the two fields PO_List and DN_List which have been removed from
/OPT/VIM_1HEAD?
If the upgrade has been performed according to the Installation Guide, the field contents have been
saved into the new table /OPT/VIM_1PO_DN by running a program before the upgrade. If you have
forgotten to run this tool, the data is lost. This is not very serious, however, because the PO numbers are
contained in the line items.

2.2.5 Using the new indexing screen for old document types
There is a Migration report for upgrading from old indexing screen to new indexing screen. For
information about this report, see section 8.2.1 Document type migration.
2.3 Business Rule Framework

The new Business Rules Framework, along with Logic Modules, allow you to reorganize VIM processes in
more clear way. Please refer to the Configuration Guide for more information about the new functions.
The upgrade specifics related to the new functions are discussed in a separate section of this guide.
2.4 New VAN Report

A new VIM analytics report (/OPT/VIM_VA2) is delivered with 7.5. This report is available for HANA and
non-HANA databases.
2.5 New Approval approach

In VIM 7.5 a new approval strategy – the Level-based approval - has been implemented. This should
replace the old approval approach for Non-PO invoices – simple, manager based approval.
In the old, simple approval, the flow calculates the amount based on the gross amount value of the total
invoice. The simple approval flow is based on manager’s information provided in the “old” Chart of Authority
(COA).
Level-based approvals can be done as line-based (sequential or parallel flow) and header-based approvals.
Whereas in Header-based approval the invoice can be approved as a whole on header level, in Line-based
approval each line item of the invoice can be approved separately. Moreover, the line-based approval
approach allows to approve different line items either in sequential manner (in one flow) or in some parallel
flows.
The new approval approach makes use of the new Chart of Authority (new COA) to determine the
approvers for each approval step.
For more information please refer to the newest version of the Configuration Guide of VIM 7.5 –
Chapter 13 – Invoice Approval.

3 Obsolete features
3.1 Country-specific document types
The country specific document types delivered in VIM baseline configuration in VIM 6.0 and older are
not used anymore. While you can still use them and enable process types per document type according
to the country rules, the recommended approach since VIM 7.0 is to use characteristic based
customizing.
If you are migrating from country specific document types to global document types, you need to verify
whether all expected process types are configured in characteristics in the same way you were using
them in the document types directly. Potentially present custom process types can be migrated to
characteristic specific process types.
3.2 Old COA & simple, manager-based approval workflow

The old simple, manager-based approval will not be supported any further for Non-PO invoices from
VIM 7.5. Instead the new approval approach – level-based approval – should replace the old one.
3.3 Old indexing screen

The old indexing screen that was the only one available in VIM 6.0 and older is not supported anymore.
While it is still possible to use it, Open Text will not be providing development support around the old
screen (no patches will be developed). We recommend to migrate to the new indexing screen available
since VIM 7.0. Open Text provides a report to migrate the screen settings, documented in a separate
section of this guide.
Please note that if you were using custom subscreens with the old indexing screen, those will not be
compatible with the new one. You will first need to verify, whether the custom functionality can be
eliminated if the new screen supports the same as a standard feature. If this is not possible, new
subscreens to support the custom functions will need to be developed.
3.4 VIM Analytics

A new VIM analytics report (/OPT/VIM_VA2) is delivered. The old transaction /OPT/VIM_ANALYTICS is
obsolete. During the update, an initialization report needs to be executed. This migration is described
later in this document.
3.5 Integrated Invoice Cockpit

The integrated invoice cockpit (IIC) is replaced by the VIM workplace (/OPT/VIM_WP). The tree based
navigation of IIC is replaced by the selection option and user based navigation of the workplace. During

the update, an initialization report needs to be executed. This migration is described later in this
document.
4 Upgrade options
4.1 Technical upgrade using version switch

To make your VIM 7.5 system behave in the same way as 6.0/7.0 in regard to BRF/LM, create a new
entry in the table /PTGWFI/Z_CONST, using the transaction SM30 (Technical Version Switch):
 Product code: 005

 Version: empty
 Constant name: VIM_VERSION_SWITCH
 Constant description: VIM version switch for 7.5 upgrade
 Constant value: 700
If the constant is set to 700, the logic modules will not be called even for 7.5-specific document types.
The business rules (document process types) will be called according to their definition. To return to
standard 7.5 behavior, make the constant value empty or completely delete the record from the table.
4.2 Options for existing processes

4.2.1 Existing DP processes
For your DP process, you need to consider whether you will be doing a technical upgrade with the
version switch as described above, or doing a full upgrade. In either case, the document type and
indexing screen settings need to be migrated. Open Text provides a migration program, documented
later in this guide.
If you are doing a full upgrade, you need to review the process in regard to logic modules and Business
Rules Framework, as described below in the section “Functional Migration Areas”. Don’t forget that, as
described in the section about the upgrade options, there are some logic modules, like the one of PO
invoice line items determination, that in a baseline configuration are running for all DP document types,
including old pre-VIM 7.5 ones.
4.2.2 Existing approval processes

Two upgrade approaches are available for the customers:
1. Approval processes which are created before upgrading can be processed further with the old
approval approach using the old COA.
Note: Although the old approval process is not supported for Non-PO invoices anymore, the workflows
started before the upgrade will be considered as exception. Even in this case, Open Text will not be
providing any patches for the old approval functionality if it’s specific to Non-PO processing.
2. If you plan to make use of the new approval approach for the invoices that are already in the
approval flow before the upgrade, you must perform the following actions for all invoices after
Upgrade:
- Kill (Recall) the active approval workflows of all invoices in consideration.
- Maintain AFS for the document type of all invoices in consideration, or change document type of
all invoices (see 8.2.3 Approval Workflow Migration Tool – Report for mass approval actions)
- Maintain new COA (see 8.2.2 COA migration).
- Resubmit the invoice for approval again.
The first action and the fourth action can be done in mass mode using the migration tool – the Report
“Mass Approval Actions”. The second action must be done manually.
If this approach is selected, the following points must be considered:
1. Which new approval options shall be used for invoices in consideration? - create AFS
accordingly. See Configuration Guide.
2. New COA must be maintained fully and available in the production system.
3. Decide which invoices will “jump” into new approval. Consider that the new approval will be
applied to all invoices of one document type. It is not possible to use new approval for some
invoices of a certain document type but old approval for other invoices of the same document
type.
4. Do you want to use the new document type for all invoices in consideration, or keep the old
document type but with the new AFS settings maintained for it. If the new document type must
be used, make sure that this document type is available in the production system.
5. Decide to which extent you can use the report “Mass Approval Actions”. Note that an invoice
can be recalled and resubmitted outside of the Report individually.
4.3 Functional Migration Areas
4.3.1 Implications of Business Rules Framework and Logic Modules
Business Rules Framework and Logic Modules
General information

VIM 7.5 introduces the new concept of logic modules and business rules framework (BRF). While
business rules (process types) existed before, the new framework allows finer customizing and can be
used to improve the ways you process invoices. The BRF is provided with VIM 7.0 SP5. Logic modules in
VIM 7.5 are replacing the business rules that were used to update the invoice data (populate the missing
information automatically). In addition, while in VIM 7.0 some data was being extracted at different
points in the process (often, at the process start, to assign initial values), in VIM 7.5 this task is
performed using logic modules.
In the course of the upgrade planning, you will need to decide whether you will keep running VIM in the
7.0-fashion, when logic modules will not be called (using the technical version switch), or you make a full
upgrade and start using logic modules. In the case of full upgrade, it is recommended to migrate
business rules that update the data into logic modules, setting them in the manner similar to how the
standard 7.5 document types NPO_75 and PO_75 are set up.
Verification and migration of business rules to logic modules in case of full upgrade
In general, each process type used by “old” DP document types has to be verified:
Simple check: compare your process type list against baseline 7.5, standard document types. If it is still
present in standard – it should normally work with no changes. Otherwise, verify:
Is it just a check? (Business rule) – If yes, it remains a business rule. In addition, verify if the new BRF
configuration (vendor groups etc.) can or must be used.
Does your old business rule update the data? If yes, migrate the business rule to a logic module.
Verify standard migrated process types, find which logic modules they are migrated to, and make sure
the corresponding processing is activated. Example: process types 109 and 110 has been migrated to LM
P_ITEM_001 and BR 113.
If you have some custom updating business rules, convert them into custom LMs. Decide on their
processing type (start/rerun).
Note: As of now, VIM 7.5 BRF does not prevent you from updating the data inside of business rules.
However this may be changed in the future and we recommend to migrate updating business rules to
logic modules as quickly as possible.
Migrations of BRs to LMs in VIM 7.5 standard:
PO line determination – 109+110 has been migrated to LM P_ITEM_001 and BR 113. Please note that if
you are doing a full migration and will be therefore using the new business rule 113 (Manual Check
Needed / Missing Data for Indexing Lines), you will need to decide on the logic of this rule and
potentially configure it, as described in a next section.
Localization for Russia - Map single service PO, migrated from BR 109 into LM G_HEAD_012. Note: If still
using 109, the logic will NOT be called after the full upgrade!

It is important to remember that some logic modules are called for all document types. In the following
screenshot of baseline configuration the first two lines of the processing mapping are highlighted to
show the two corresponding process IDs (lines without the DP document type).
4.3.2 Business rule 113 – “Manual Check Needed / Missing Data for Indexing Lines”.
The old 7.0 business rule 110 – “Manual Check Needed / Missing Data for Indexing Lines” has been
migrated to the logic module P_ITEM_001 and the new business rule 113 (with the check function
module /OPT/VIM_DETERMINE_PROC_108).
In case the line items data will be changed by the logic module by matching with the proposal, DP
process will stop with a generic exception allowing you to verify the changed data. The business rule 113
is now only checking the completeness of line items using the same logic as the older rule 110. In
addition, in contrast to pre-7.5 business rule, this new version also checks if the invoiced quantity on
each line does not exceed the GR quantity (that has not been invoiced yet). For service POs, SES is
checked similarly. This additional check can be switched off if needed, to have the 7.5 business rule to
make only completeness checks, which will be same as in VIM 7.0 and older.
The additional GR/SES check is made by default in VIM 7.5, and when doing a full upgrade and migration
to VIM 7.5, you need to verify which check logic is suitable for your process. To switch the additional
checks off, create a new entry in the table /PTGWFI/Z_CONST, using the transaction SM30:
Product code: 005

Version: empty
Constant name: DISABLE_GR_CHECK
Constant description: Set to X to disable additional GR checks in PO line determination (BR 113)
Constant value: X
4.3.3 PO_LIST and DN_List

The two fields PO_LIST and DN_LIST have been removed from /OPT/VIM_1HEAD. That means if you
have customer programs or customer data structures referring to these fields, you will get generation
errors. To prevent these errors, you should remove the fields from your own data structures and
comment the code lines using these fields before the upgrade.

5 Post installation activities
5.1 Recommended sequence of post-installation steps
 Post installation steps as listed in the Installation Guide
 Post installation steps of each additional SP you are installing
 BRF / version switch for technical upgrade
 COA migration – using provided report or project-specific way
 Document type settings / indexing screen migration
 Migration report for VAN
 Migration report for Workplace
 Approval workflows mass recall / resubmit
If upgrading from VIM versions 6.0 SP2 and older – decide whether migration reports for VAN and
Workplace need to be scheduled in a periodic job.
5.2 Migration tool/steps documentation

5.2.1 Document type migration
VIM 7.5 SP2 introduces the new report /OPT/VIM_IDX_UPD. The report updates the configurations in
the areas of Document type and indexing screen for existing VIM 6.0 document types in a VIM7.5
environment and reduces the effort of manual entries in configurations.
The report updates the following configuration areas for the following document types.
PO document types:

 PO line automation
 Index item configurations
NPO document types:

Down Payment types:


This report will be used after post upgrade.
Using the selection screen.

To start the Migrate Document Type Configuration (6.0 to 7.5) report, run the /OPT/VIM_IDX_UPD
program. The Selection screen is divided into two parts.
 Adjust Document Type Configuration (6.0 ->7.5)

 Compare Document Type Configuration
Adjust Document Type Configuration (6.0 ->7.5)
First, click the radio button Adjust Document Type Configuration (6.0 ->7.5).Enter the reference
document type PO_75 or any other document type as shown below. Click to run the report.
The report shows the following sections:
 Application toolbar
 ALV Grid
 Document view

Application toolbar
ALV Grid
Document view
Application toolbar: The application toolbar contains the following buttons:
 Update Entries: updates the selected VIM6.0 Document type to VIM 7.5 Document Type
Configuration features.
 Select All: Select all displayed document types
 Deselect All: Deselect all displayed document types

ALV Grid: The ALV Grid control provides various SAP-specific buttons for the ALV list viewer.
Document view: The Document View (ALV Grid) presents the following columns.
Selection option
Select this check box to consider only document types that need to be upgraded to VIM7.5 document
type features. It includes document type main screen configuration changes along with indexing screen
changes.
Document type
Will display all existing VIM 6.0 document type to be upgraded to VIM7.5 document type’s configuration
features.
Reference document
This field is filled with the value from the selection screen input.
This program will update the PO line automation configurations tables with values of below Z-Constants,
from /OPT/VIM_ZCONST table. Product code is 005.
PO Line Determination Setting

By default this setting will be updated with the Z-Constant PATH_INCOMPLETE_LINE, value from
/OPT/VIM_ZCONST table maintained in VIM 6.0. The user has the option to configure to the following
values.
 OK: Use OCR lines as basis without deletion of incomplete lines.
 OD: Use OCR lines as basis with deletion of incomplete lines.
 MO: Use MIRO proposal as basis for indexing lines.
 PO (Default for PO Automation): Use MIRO proposal with no dialog action.
 M2
For complete information about these options, see VIM 7.5 Configuration Guide.
Level Preference
This program will update values of Z Constant LEVEL_PREFERENCE from /OPT/VIM_ZCONST table
maintained in VIM6.0.
The user has the option to configure PO/delivery note either at header level (H), or line level (L), or both
levels (B).
Ref Doc Preference

This program will update values of Z Constant REF_DOC_PREFERENCE from /OPT/VIM_ZCONST table
maintained in VIM6.0.
The User has the option to configure either purchase order (PO) or delivery note (DN) as their base for
proposal.

Report execution
After completing the Selection screen options, click the Update entries button. You will get a pop up for
generating or selecting a transport request and all entries will be saved under this transport request.
When the transport request is saved, you will get a message “Selected records updated successfully”.
The following sections describe the report results:
5.2.1.1 Updates main screen configuration for document types
 Updates the global control from “No” to “Yes” for new indexing screen field.
 Updates new indexing screen programs along with screen numbers.
5.2.1.2 PO line automation
Updates the below configuration with values used in program.
5.2.1.3 Indexing screen options
Updates the initial tab for each DP process type & role by taking reference as document type given in
the selection screen. Updates the initial tab with the following indexing screens:
 Basic Data: Shows the basic indexing information, which is also available on the invoice
document.
 Line Item Data: Shows the relevant line items.
 Accounting Data: Shows additional SAP specific data for the accountant to post the document.
 Tax Data: Shows relevant tax information.

 Process Data: Shows relevant process information and also provides access to the duplicated
invoices.
5.2.1.4 Index item Configurations
For PO document types: updates the PO tab strip control tab for all fields with the following options by
taking reference as document type given in the selection screen.
 All Tabs / Not relevant

 G/L based Tab only
 PO reference Tab only

For NPO Document types: Updates PO tab strip control with default tab as “All Tabs / Not relevant” for
all fields, as this tab is not relevant for NPO DP document types.
5.2.1.5 Index Header Configuration
There are some special fields that are not in the database but can be displayed in the indexing screen.
To use them, you must configure the Field Stat column for the following parameters.
NOTE: Add the below parameters manually in the indexing screen header configuration, as the
migration program does not process header fields.
VORGANG
To display Subsequent Debit and Subsequent Credit for PO in the index screen, under Invoice Data,
Transaction field, set the parameter VORGANG to Input.
DIFFERENZ
To display the Balance traffic light in the indexing screen, under Invoice Data, set the parameter
DIFFERENZ to Display Only.
DN_LIST, PO_LIST
To display the DN List and PO List buttons in the indexing screen, under Invoice Data, set the parameters
DN_LIST and PO_LIST to Input.
5.2.1.6 Identify the difference between Document types of VIM6.0 & VIM7.5
Click the radio button Compare Doc Type Config:
Enter VIM6.0 and VIM7.5 document type and click the Execute button.
This will display the configuration differences for both document types. See the following screenshot.

Double-click any of the difference entries. This will display the fields that had configuration differences
for both document types.
5.2.2 COA migration

To facilitate the migration from old COA to new COA during the VIM 6.0 (or 7.0) to VIM 7.5
upgrade, two migration programs are provided to reduce the effort and simplify the migration.
 Migrate Coder Determination Data (/OPT/BL_AP_CODER)

 Migrate Approver Details (/OPT/BL_APPCOA)
Note: There may be different ways to migrate the COA setup depending on your
project specifics. OpenText attempts to provide migration programs to support a very general
case. If your project requires different migration logic, custom migration reports must be
created.
Prerequisites:
Before starting the migration process, you must have decided on the following:
1. AFS ID of Level Based Approval, against which Coder Determination settings must be
migrated.
2. Maintain the “Approver Limits/Level” tab of the new COA.
3. List of coders and requesters per company code.
User Details, Preference, Substitutions remains unchanged and do not need migration.
Note:
1. No change logs are generated during the migration.
2. Data in old COA remains as is post migration.
5.2.2.1 Migration of Coder Determination (Table /OPT/BL_AP_CODER)
All coder determination entries are migrated to the new COA, for specific AFS ID.
Old CoA New CoA
Old COA table: /OPT/BL_AP_CODER
New COA table: /OPT/AFS_CODER
Program: /OPT/COA_CODER_UPG
Input:
1) AFS ID – of level based approval workflow

2) Test Run
Notes:
1) Coder determination setting on AFS ID must be the same as the Coder Determination constant
(CODER_DETERMING) value, to migrate data from old COA.
2) Migration is not possible if constant CODER_DETERMING is S (Use Requestor).
3) Existing data for given AFS ID is overwritten in the new COA, if any.
4) During migration, only the relevant fields as per constant CODER_DETERMING are considered.

Output:
Coder setting data from the new COA in ALV Format.
In case of Test Run, except for actual update, the rest of the process remains the same.

5.2.2.2 Migration of Approver Details (Table /OPT/BL_APPCOA)
Migrates COA Approver details from old COA to new COA, for a given company code(s), based on user-
selected rules (lower, higher, near).
Program: /OPT/COA_APPR_UPG
Old COA table: /OPT/BL_APPCOA
New COA table: /OPT/APPR_COA

Prerequisites:
 Approver Limit/Level tab is maintained already.

 Prepare the list of Coders and Requesters per company code.
 Cost Element ‘Company Code’ is maintained in the old COA and it must not be ‘*’.
Input:
1. Company Code
2. Delete New COA approval Data(/OPT/APPR_COA) – (radio button; Delete the data for given
company code(s))
3. Migrate Data – from old COA to new COA
3.1. Approval level matching rule:
3.1.1.Lower (radio button)
3.1.2.Higher (radio button)
3.1.3.Nearest (radio button)
3.2. Approval limit currency:
3.2.1.1. Local currency (radio button)
3.2.1.2. Fixed currency (radio button) - Currency field
3.2.2.Conversion Date
3.3. Coder and Requester List – Input file:
(CSV file format: Company Code, User ID, Indicator (C – Coder or R – Requestor). No header line.
Sample Record(s):
1000, CODER1, C
1000, REQUESTER1, R
3.4. Test Run
Approach:
Within a company code:
 Coders (Tab: COA Details > Coder/Requester Details): Old COA Approver (/OPT/BL_APPCOA)
users are mapped to Level 0 along with cost elements as defined in the old COA, if the user is
marked as Coder in the input file. If a coder has more than one record in the old COA, with
“unique” combination of cost elements, then all are replicated into the new COA at level 0.
 Requesters (Tab: COA Details > Coder/Requester Details): Old COA Approver (/OPT/BL_APPCOA)
users are mapped to Level 1 along with cost elements as defined in the old COA, if the user is
marked as Requester in the input file. If a requester has more than one record in the old COA,
with “unique” combination of cost elements, then all are replicated into the new COA at level 1.
 Approver (Tab: COA Details > Approver Details): Remaining approver users of the old COA
(/OPT/BL_APPCOA) are mapped to the respective level of the new COA, based on the “Approval
Limit/Level” according to the following rules:
Old COA Data (COA Approver Details tab):
UserID Amount Curr CompCode CostCenter

C1 0 USD CCode1 *
R1 1000 USD CCode1 CCenter1
R2 2000 USD CCode1 CCenter2
A1 3000 USD CCode1 CCenter1
A2 4000 USD CCode1 CCenter2
A2.1 6000 USD CCode1 CCenter2
A3 8000 USD CCode1 *
C1 is coder, R1 & R2 are requesters according to the input file.
o Lower: to the level, when its corresponding amount (in new COA) is same as the old
COA Amount of the User. If equal amount is not found in “Approval Limit/Level”, then

the migration tool looks for the next lower amount and map the user to the respective
level.
Example:
Scenario 1 Scenario 2 Scenario 3

Lower
Amount Mapping Amount Mapping Amount Mapping
Level 0 0 C1 0 C1 0 C1
Level 1 2000 R1, R2 1500 R1, R2 2000 R1, R2
A1, A2,
Level 2 3000 A1 3400 A2.1 3000 A1
A2, A2.1,
Level 3 4000 A3 6500 A3 4000 A2,
Level 4 8500 8500 6000 A2.1
8000 A3
Note:
If the approval limit of a user is in between Level 2 and 3, then the user gets mapped to
Level 2.
If the approval limit of a user is in between Level 1 and 2, then the user is not mapped to
any level. (Except if the user is present in Coder & Requester Input file).
o Higher: to the level, when its corresponding amount (in the new COA) is the same as the
old COA Amount of the user. If equal amount is not found in “Approval Limit/Level”,
then the migration tool looks for the next higher amount and map the user to the
respective level.
Higher Scenario 1 Scenario 2 Scenario 3

Level 0 0 C1 0 C1 0 C1
Level 1 2000 R1, R2 1500 R1, R2 1500 R1, R2
Level 2 3000 A1 3400 A1 3000 A1
Level 3 4000 A2 6500 A2, A2.1 4000 A2,
Level 4 8500 A2.1, A3 8500 A3 6000 A2.1
8000 A3
o Near: to the level, when its corresponding amount (in the new COA) is the same as the
old COA Amount of the user. If equal amount is not found in “Approval Limit/Level”,

then the migration tool looks for the nearest (lower or higher) amount and map the user
to the respective level.
Example:
Near Scenario 1 Scenario 2 Scenario 3

Level 0 0 C1 0 C1 0 C1
Level 1 2000 R1, R2 1500 R1, R2 1500 R1, R2
Level 2 3000 A1 3400 A1, A2 3000 A1
Level 3 4000 A2, A2.1 6500 A2.1 4000 A2,
Level 4 8500 A3 8500 A3 6000 A2.1
8000 A3
How Rule Works (Lower, Higher, Near)?
Currency handling:
1) In case of Fixed currency, convert all other currencies from the old COA into given currency,
before applying the rules.
2) In case of Local Currency, convert all other currencies into the local currency of the company
code, before applying the rules.

Usage Guidelines – due to currency handling:
- Local Currency: If amounts defined in “Approval Limit/Level” are in local currencies for a
company code, all company codes can be processed/migrated in one go.
- Fixed Currency: If amounts defined in “Approval Limit/Level” are in Fixed currencies for a
company code, all company codes with the same local currency (in other words, for a given
country) can be processed/migrated in one go.
Notes:
1) Company code and ‘Expense Type’ combination of the old COA must exist in the ‘Approver
Limits/Level’ tab of the new COA. Else, migration of those records from the old COA is not
possible.
2) Migration is not possible if Company Code is not part of the ‘active’ cost elements (according to
table OPT/BL_T401) in the old COA.
3) Approvers data is not migrated if Company code OR Expense type is * in the old COA.
4) Z-constant “IAP 000 MULTI_ACCT_ASSIGN” must be set as “X”, if multi account assignment
functionality is used, while migrating to Level Based Approval/new CoA.
Output (in ALV):
Additional Notes:
1) During migration, no change documents are generated for the new COA. Thereafter, any
changes to the COA generate change documents.
2) Data in old COA remains the same.
5.2.3 Approval Workflow Migration Tool – Report for mass approval actions
The report is designed in a way that it helps to execute the actions Recall Approval and Resubmit for
Approval in bulk/mass mode. This is a one-time report designed for the administrator to support the
transition phase after upgrading from old VIM versions to VIM 7.5.
The report delivers 3 functionalities: Mass Recall, Mass Resubmit and Display Report.
Notes:
- The report is not designed for the end user.

- Custom enhancement and custom exits are not considered in the report. They should be
handled by the customer.
- Consider that the mass actions like Recall or Resubmit requires a lot of workflow resources. It is
advised to perform mass actions in small chunks (per logic system or document type or
company code) and in the time slots where not much activities are going on.
- Since the report is designed for restricted use, some aspects like layout management and
performance will not be considered. No extension is planned.
5.2.3.1 Mass Recall

5.2.3.1.1 Prerequisites
- System landscape settings must be configured properly before running the report, also in
case of single backend system.
- Assign the authorization to execute the report to a dedicated user. The user should have
authorization to execute all approval work items.
- Maintain the role so that after recalling the workflow will not run into error status because
of no agent is found. Since recall works similar to rejection, it makes sense to test rejection
functionality before doing recalling.
- The date of executing upgrading should be ready to be used as Input. Only invoices with
approval workflows which have been created before this date will be considered.
- If resubmit should be executed by the report, take care that all recalled document will not
be touched until resubmit is done.
5.2.3.1.2 Functionality
Call the SE38 transaction and run the program: /OPT/VR_MASS_AWF_ACTIONS.
Select the Mass Recall radio button.

Field “Upgrade Date” is mandatory.
2 checkboxes:
- Workitem not intact : List all WI that are unnormal and should be handled manually.
- Workitem intact : List all WI that are correct and can be recalled. Only intact WI will be
considered in the Recalling function.
Output list
All invoices that are in an approval process which has been started before the Upgrade Date will be
displayed in the output list:

You can select all invoices that you want to recall. Click the Recall button. Recalling will be executed only
for invoices with status INV_OK.
Invoices that have been recalled will be removed from the output list. You can see them in the Display
Report.
Visible fields in the output list:
Apart from the self-explaining fields, the following fields are available:
Last Agent: The last agent who got the work item in his inbox for the current approval WF.
First Agent: The very first agent who processed the invoice in the current approval WF.
Work item ID: the ID of the current approval work item.
WI status: 2 possible status of the approval work item:
Icon Status Description
INV_OK Work item is ok and can be recalled.
ERROR WF is not-ok and must be handled manually.
Hidden Fields in the output list:
Approval Type: can be A_DPNPO, A_DPPO for DP, A_PRKNPO, A_PRKPO for parked document approval,
A_PSTNPO, A_PSTPO for posted document approval.
Reference Key (Object Key) and Reference Transaction (Object Type): Those values are unique for an
approval WF.

Possible messages of a workflow that is not OK:
Message Details
Error: No SAP data found for the Approval No SAP document found for
WF posted/parked VIM document
Error: no Entry in table sww_contob Self-explaining
Error: Object Type and Object Key not Self-explaining

correct in sww_contob
Error: No valid current approver found for No agent found in /ors/stack_body

the current Approval WF.
Error: No valid stack number in table Self-explaining

/ors/stack_hdr
Error: Current stack number not found in Self-explaining

table /ors/stack_body.
Possible returned error messages in Recall:
Error Message Details
Recall failed : Approval Workitem not For some reason the WI has been
available: WI ID executed, deleted, cancelled
Recall failed : Top Approval Workflow not For some reason the parent approval
available: Top WI ID workflow has been executed, deleted,
cancelled
Workitem currently locked by another user Self-explaining
Approval step currently locked Self-explaining
No active approval object found Self-explaining
Current approver not found Self-explaining
Error terminating approval workflow Settings for approval is not correct, or

not able to execute some actions with
history log or stacks, or not able to send
terminating event
Error changing approval status Not able to change Approval Status to

Recall

5.2.3.1.3 Remarks/Restrictions
1. Only active Approval WFs which have been started BEFORE upgrading will be considered by
the report.
2. An Approval WF which failed to be recalled must be handled manually.
5.2.3.2 Mass Resubmit

5.2.3.2.1 Prerequisites
- Multi-backend landscape has been configured.
- The Administrator who executes the report should have full authorization to execute all VIM
work items.
- Recall report has been executed. All recalled invoices have been untouched.
- The new COA is correctly maintained (see the COA chapter).
- AFS is maintained. Consider that PO approval is not supported in baseline LBA yet. You can
use AFS for PO document type only if a corresponding custom class for PO approval is
implemented.
- Document type is correctly adjusted and mapped to the correct AFS (see the Document
Type chapter). It is strongly recommended to test thoroughly some new approval workflow
with new document type before executing the Resubmit report.
- All Custom Enhancement and exits are examined and updated to the new approval WF
template.
- The Mass Resubmit action simulates the process option “Resubmit for Approval”, which can
be executed in the Dashboards. It will use the baseline process option IDs as default:
o Process Option 2021 for Resubmit posted PO invoice
o Process Option 2020 for Resubmit posted NPO invoice
o Process Option 2027 for Resubmit parked PO invoice
o Process Option 2028 for Resubmit parked NPO invoice

If you want that the mass resubmit action behaves like specific custom process options, the Z-
constant 005 / MASS_RESUB_ACTIONS must be maintained correctly on each systems with such
process option IDs.
The process option IDs are maintained in the following order with separator “comma” and
no space between values:
<Posted PO>,<Posted NPO>,<Parked PO>,<Parked NPO>
Empty value is allowed, for example “2021,,,2028“.
5.2.3.2.2 Functionality
Select the radio button Mass Resubmit in the selection screen.

Output list
Invoices which have been successfully recalled will be shown in the list.
Select invoices which need to be resubmitted and click the Resubmit button. All selected invoices will be
resubmitted for approval.
After executing Mass Resubmit, the selected invoices will be updated with the current status (field Work
item Status) in the output list. Those items will not be included in the output list in the next run, but can
be displayed on demand, executing the same report and selecting the “Display report” option on the
selection screen.
Recalling Agent : Agent who executed the recall action

Recall Date : Date of recall action
Recall Time : Time of recall action
Resubmitting agent : Agent who executed the resubmit action

Resubmit Date : Date of resubmit action
Resubmit Time : Time of resubmit action
Hidden (available) fields in output list:
Last Agent: The last agent who got the work item in his inbox in the recalled approval WF. This field is
only relevant for recalling function.
First Agent: The very first agent who processed the invoice in the recalled approval WF. This field is only
relevant for recalling function.
Reference Key (Object Key) and Reference Transaction (Object Type): those values are unique for an
approval WF.
Possible returned error messages in Resubmit
Error Message Description
Resubmit successful Resubmit successfully executed
Resubmit failed: Invoice Something wrong with parent WF: it may be error or completed.
Workflow is not available.
Please check.
Resubmit failed: Cannot send Event cannot be sent to the WF.

Event to WF.
Resubmit failed: Cannot initiate Approval WF cannot be initiated.

approval WF.
Resubmit failed: Doc is not The document type in use is not maintained for Posted Approval.
maintained for Posted
Approval.

Error Message Description
Resubmit failed: Invoice not After being recalled, the top (parent) workflow of the invoice will
ready for resubmit. Please be active again. The status of this top workflow will be checked
check. before doing Resubmit. If there is something wrong with the top
WF, the invoice should be handled manually. Some examples:
1. In some case after being recalled, the top workflow will run
into error, since the role determination fails and no agent is
found for the next work item.
2. Approval is triggered for the invoice outside the Report.
5.2.3.2.3 Remarks/Restrictions
1. Only active Approval WF which have been started before upgrading and successfully
recalled by Mass Recall Report after upgrading will be considered by the report.
2. All Approval WF which start after upgrading (with new Approval Template) or recalled by
other means will not be considered.
3. Approval WF which failed to be recalled or resubmitted must be handled manually.
4. No explicit log implemented. The resubmit simulates some process options, therefore logs
for such process options will be used.
5. For Resubmit of posted invoice, comment is allowed only for single resubmit.
5.2.3.3 Display Report

Select the radio button Display Report in the selection screen.

Output list
All invoices which have been recalled or resubmitted by the report will be shown in the output list:

Recalling Agent : Agent who executed the recall action

Recall Date : Date of recall action
Recall Time : Time of recall action
Resubmitting agent : Agent who executed the resubmit action
Resubmit Date : Date of resubmit action
Resubmit Time : Time of resubmit action
Workitem status
Possible statuses
Icon Status Description
RECOK Recall successful
RECFAIL Recall failed
RESOK Resubmit successful
RESFAIL Resubmit failed
Hidden (available) fields in output list:
Last Agent: The last agent who got the work item in his inbox in the recalled approval WF. This field is
only relevant for recalling function.
First Agent: The very first agent who processed the invoice in the recalled approval WF. This field is only
relevant for recalling function.
Reference Key (Object Key) and Reference Transaction (Object Type): those values are unique for an
approval WF.

5.2.3.4 Troubleshooting
1. Check entries in the Z-constant table:

The following Z-constants must be maintained correctly:
005 DP_DASHBOARD_TASK_ID
PIR PIR_PSS_TASK_ID
LIX PRK_PSS_TASK_ID
IAP APPROVAL_TASK
2. Check that all roles are maintained correctly in transaction /OPT/VIM_7CX1 - Simple /
Manager Approval - Chart of Authority Maintenance. The WF can run into error after being
recalled if there is no agent found for the WF after invoice is recalled.
3. Before Resubmit, check that Coder will be determined correctly in the old COA (if old
Approval will be used further on) or in the new COA (if new Approval will be used instead).
The Approval WF can run into error if there is no agent found for the WF after invoice is
resubmitted.
4. If WF runs into error after being recalled or resubmitted, see chapter “Troubleshooting and
Monitoring” in the Administration Guide.
5.2.4 VAN Migration Report

5.2.4.1 Scope
With VIM 7.5, a new VIM Analytics report is delivered. This report is based on data maintained in the
following new tables:
- /OPT/VIM_2HEAD: Extension table for /OPT/VIM_1HEAD
- /OPT/VIM_1PROC: Contains all processes relevant for one Document ID
- /OPT/VIM_1WI_AGT: Contains the current agents of work items.
These tables are filled consistently during the runtime of the work item.
The report has two main scopes:

5.2.4.1.1 Initialization mode
When upgrading from a lower VIM version (6.0), these tables need to be filled initially for old instances.
The new VIM Analytics will not show any values if the /OPT/VIM_2HEAD table is not filled. This
migration report needs to be executed accordingly.
5.2.4.1.2 Update mode

The report can be executed for chosen document IDs by an administrator to correct data in the
mentioned database tables.
5.2.4.2 Report execution

The report /OPT/VR_ANALYTICS_750_INIT can be called using the SE38 transaction.

5.2.4.3 Selection Screen
The report offers the following parameters:
Document Selection:
- Document-ID: Selection for VIM Document ID, mandatory

- Select Charge: The processing in the report is done by charges. The number of processed
documents before committing (COMMIT) can be maintained here. In normal cases, this number
can be left on the standard setting. For optimization, this parameter can be set differently.
Update Properties
- Test Run: If you select this check box, the report will not update any values in the database
tables. This mode can be used to runtime measurement before planning the actual productive
run.
Note: If this check box is not selected, you must also unselect two options in Extended Display
Option (see below).
Extended Display Option
Note: these options are only available in Test mode. In Productive mode both options must be
unselected.
- Display calculation results: If this check box is selected, the report will show a list comparing the
current database values with the ones calculated by the report (see next section). This mode can
especially be used to analyze issues with content of the tables for single documents.
- Only show inconsistent data: Only relevant in combination with option “Display calculation
results”. If this check box is set, the protocol will only show lines with differing content between
database and calculation. If the check box is cleared, the protocol will show all database content
compared to the calculated values.
5.2.4.4 Output
- “Display calculation results” not selected:
The report will show a protocol about successful or unsuccessful execution which can be accessed in the
Job Spool when running in the background.
- “Display calculation results” selected:
The report will calculate all values within the selection range and display them in intervals according to
the “select charge” setting. On the main screen, the tables can be analyzed for these intervals by
pressing the respective button. The button “Go to next interval” will start the calculation of the next
interval.
The table view will show a list of all values already present in the database and compares them to the
calculated value. The first line is representing the current value in the database, the second line the
calculated value.

Database
[Grab yourvalues
reader’s attention
with a great quote from the
document or use this space to
Calculateda values
emphasize key point. To
[Grab your
place this text box anywhere
reader’s
on the page, just drag it.]
attention with
5.2.4.5 Migration strategy a great quote
from the
The scope for migration needs to be defined. As the report is based on time-consuming analysis of
document
workflow instances, a long runtime has to be expected. or Therefore, a proper migration strategy has to be
defined. use this space
to emphasize
5.2.4.5.1 Data archiving a key point. To
To minimize the migration time, consider placedata
thisarchiving
text of old VIM items before the upgrade. See
chapter 33 – “Data Archiving Configuration” of the
box anywhere Configuration Guide and chapter 20 – “Archiving VIM
Information” of the Administration Guide on
for the
more details.
page,
5.2.4.5.2 Scope of migration just drag it.]
Before migration, the scope of use for VIM Analytics needs to be evaluated. The following data use cases
can be considered.
- Current work items: For all currently running workflows (started before the upgrade and not
finished), a migration is mandatory. Highest priority for migration, needs to be done before the
users start working after the upgrade.
- Finished work items, relevant for current analysis (that means relevant for the current fiscal
year): These work items should be migrated with second priority. As these workflows are
already finished, the migration can also be done after the users started to process current work
items.
- Finished work items, relevant for historical analysis (that means data from the last fiscal year):
These work items can be migrated with third priority.
- Finished work items, not relevant for analysis: for older data, which is not relevant for analysis
using VIM Analytics, a migration is not necessary. If the migration is not done for these items,
they will not occur in the new VIM Analytics. This will also improve the runtime.
5.2.4.5.3 Runtime analysis

Due to the complex selections on workflow data, the runtime of the report needs to be calculated
before doing the productive migration. This can be done on a test system, preferably with a comparable
hardware sizing as the productive system.

Starting with small amounts of invoices (that means, starting with 100), the overall runtime of the
migration can be calculated. The runtime of the report is scaling linear, so an estimate for the runtime of
the whole migration can be calculated based on these tests.
Additionally, the optimal size for one run can be calculated. Parallel processing is possible, overlapping
ranges of DocIDs have to be avoided.
With this data and the consideration done in chapter 5.2.4.5.2, the migration can be planned.
5.2.4.6 Known issues

5.2.4.6.1 Upgrade from VIM 6.0 SP2 or lower
When upgrading from a very low service pack level, the data in the tables will not be updated
automatically during the processing of the work items. This is due to the workflow structure of the old
running instances and cannot be avoided.
OpenText recommends that you finish most of these old instances before the upgrade. If this is not
possible, the migration report should be executed as described in the chapters before. The old work
items can be processed normally via SAP business workplace (SBWP) or in the approval.
Note that the updates done during this processing will not be reflected in VIM Analytics. For these cases,
the migration report can be executed again to refresh the tables. The report can be scheduled to run
periodically until the last workflow started before the upgrade will be finished. For each of such
workflows, it is important that the report runs at least once after the workflow and all subsequent
processes complete.
5.2.4.6.2 Old referrals

Referrals started before the upgrade will not be shown in the process view of the new VAN. This is due
to the workflow structure of the old running instances and cannot be avoided. OpenText recommends
that you finish all old referrals before the upgrade.
If this is not possible, these referrals can be processed and finished after the upgrade via SAP business
workplace.
5.2.4.6.3 Short dumps due to inconsistent container structures

If the migration report is aborting with a short dump related to wrong container structure, refer to
chapter 7.2 - “Handling Workflow Container Inconsistencies” in the Installation Guide and the relevant SAP
note 910573. This issue can occur in special cases when upgrading from a very low service pack level with
running workflow instances.

To continue with the migration, you can exclude the affected Document IDs from the migration report in
the selection screen and migrate them later after the issue is fixed. You can identify potentially affected
work items by using report /OPT/VR_ANALYTICS_750_PRECHECK.
5.2.5 Workplace Migration Report

5.2.5.1 Scope
Since VIM 7.0, the VIM Workplace is delivered. It is based on data maintained in the following tables:
- /OPT/CT_PMC_RG00: Contains information about work items in the inbox
- /OPT/CT_PMC_RG01: Contains information about work items in the inbox
- /OPT/CT_PMC_RG02: Contains information about work items in my pending
- /OPT/CT_PMC_RG03: Contains information about work items in finished items
These tables are filled consistently during the runtime of the work item.
The report has two main scopes:
5.2.5.1.1 Initialization mode

When upgrading from a lower VIM version (6.0), these tables need to be filled initially for old instances.
The VIM Workplace will not show any work items if these tables are not filled. This migration report
needs to be executed accordingly.

5.2.5.1.2 Update mode
The report can be executed for chosen document IDs by an administrator to correct data in the
mentioned data base tables.
5.2.5.2 Report execution

The report /OPT/CR_PMC_REG_UPDATE can be called using the SE38 transaction.
5.2.5.3 Prerequisite
This report is based on data contained in /OPT/VIM_1PROC. This table is initially filled by the VAN
migration report, which is documented separately. Therefore it is obligatory, that the VAN migration
report is planned and executed before the workplace migration report.

5.2.5.4 Selection Screen
The report offers the following parameters:
Document Selection:
- Document-ID: Selection for VIM Document ID, mandatory

- Select Charge: The processing in the report is done by charges. The number of processed
documents before committing (COMMIT) can be maintained here. In normal cases, this number
can be left on the standard setting. For optimization, this parameter can be set differently.
Update Properties
- Test Run: If this check box is selected, the report will not update any values in the database
tables. This mode can be used to runtime measurement before planning the actual productive
run.
Note: If this check box is not selected, you must unselect also 2 options in Extended Display
Option (see below).
Extended Display Option
Note: these options are only available in Test mode. In Productive mode both options must be
unselected.
- Display calculation results: If this check box is selected, the report will show a list comparing the
current database values with the ones calculated by the report (see next chapter). This mode
can especially be used to analyze issues with content of the tables for single documents.
- Show inconsistent data only: Only relevant in combination with option “Display calculation
results”. If this check box is selected, the protocol will only show lines with differing content
between database and calculation. If the check box is not selected, the protocol will show all
database content compared to the calculated values.

5.2.5.5 Output
- “Display calculation results” not selected:
The report will show a protocol about successful or unsuccessful execution, which can be accessed in
the Job Spool when running in the background.
- “Display calculation results” selected:
The report will calculate all values within the selection range and display them in intervals according to
the “select charge” setting. On the main screen, the tables can be analyzed for these intervals by
pressing the respective button. The button “Go to next interval” will start the calculation of the next
interval.

The table view will show a list of all values already present in the database and compares them to the
calculated value. The first line is representing the current value in the database, the second line the
calculated value.
[Grab your reader’s attention

with a great quote from the Database values
document or use this space to
emphasize a key point. To
[Grab your
place this text box anywhere Calculated values
reader’s
on the page, just drag it.]
attention with
5.2.5.6 Migration strategy a great quote
from the
The scope for migration needs to be defined. As the report is based on time-consuming analysis of
workflow instances, a long runtime has todocument or Therefore, a proper migration strategy has to be
be expected.
defined. use this space
to emphasize
5.2.5.6.1 Data archiving
a key point. To
To minimize the migration time, consider data archiving of old VIM items before the upgrade. See
place this text
chapter 33 – “Data Archiving Configuration” of the Configuration Guide and chapter 20 – “Archiving VIM
box anywhere
Information” of the Administration Guide for more details.
on the page,
5.2.5.6.2 Scope of migration just drag it.]
Before migration, the scope of use for VIM Workplace needs to be evaluated. Primary focus is to fill the
“My Inbox” and “My Pending” view in the VIM Workplace. All finished items can be migrated to appear
in the “My Completed” view, but it is not mandatory to fill them if this data is not needed by the end
users for old work items.
The following data use cases can be considered.
- Current work items: For all currently running workflows (started before the upgrade and not
finished), a migration is mandatory. This has the highest priority for migration, it needs to be
done before the users start working after the upgrade. These items will occur in the “My Inbox”
and “My Pending” view of the VIM Workplace only.
- Finished work items, relevant for current analysis (that means relevant for the current fiscal
year): These work items should be migrated with second priority. As these workflows are
already finished, the migration can also be done after the users started to process current work
items. These items will occur in the “My Completed” View of the VIM Workplace only.
- Finished work items, relevant for historical analysis (that means data from the last fiscal year):
These work items can be migrated with third priority. These items will occur in the “My
Completed” view of the VIM Workplace only.

- Finished work items, not relevant for analysis: for older data, which is not relevant for analysis
using VIM Analytics, a migration is not necessary. If the migration is not done for these items,
they will not occur in the new VIM Analytics. This will also improve the runtime.
5.2.5.6.3 Execution Plan

As the workplace initialization report is based on data contained in table /OPT/VIM_1PROC, the
execution of the VAN migration report needs to be executed before this report.
5.2.5.6.4 Runtime analysis

Due to the complex selections on workflow data, the runtime of the report needs to be calculated
before doing the productive migration. This can be done on a test system, preferably with a comparable
hardware sizing as the productive system.
Starting with small amounts of invoices (that means, starting with 100), the overall runtime of the
migration can be calculated. The runtime of the report is scaling linear, so an estimate for the runtime of
the whole migration can be calculated based on these tests.
Additionally, the optimal size for one run can be calculated. Parallel processing is possible, overlapping
ranges of DocIDs must be avoided.
With this data and the consideration done in chapter 5.2.5.6.2, the migration can be planned.
5.2.5.7 Known issues
When migrating VIM Workplace data for workflows started before the upgrade, the same problems may
arise as for the migration of VIM Analytics data. Please see “Known issues” in the section “VAN
Migration Report”.
6 Contact Information
OpenText Corporation
275 Frank Tompa Drive

Waterloo, Ontario
Canada, N2L 0A1
Email: support@opentext.com
Knowledge Center: https://knowledge.opentext.com
For more information, visit www.opentext.com

Copyright © 2015 Open Text SA and/or Open Text ULC. All Rights Reserved.
Open Text is a trademark or registered trademark of Open Text SA and/or Open Text ULC. The list of trademarks is not exhaustive of other
trademarks, registered trademarks, product names, company names, brands and service names mentioned herein are property of Open Text
SA and/or Open Text ULC or other respective owners.
Disclaimer
No Warranties and Limitation of Liability Every effort has been made to ensure the accuracy of the features and techniques presented in this
publication. However, Open Text Corporation and its affiliates accept no responsibility and offer no warranty whether expressed or implied, for
the accuracy of this publication.

VIM 7 5 Upgrade Guide

Uploaded by

Copyright:

Available Formats

VIM 7 5 Upgrade Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VIM 7 5 Upgrade Guide

Uploaded by

Copyright:

Available Formats

OpenText Vendor Invoice Management

VIM 7.5 Upgrade Guide 1

VIM 7.5 Upgrade Guide 3

1.1 VIM versions supported for the upgrade

1.2 Introduction: upgrade goals and options

1.3 Overview of VIM 7.5 new and obsolete features

VIM 7.5 New features:

VIM 7.5 Obsolete features:

The following features have been discontinued in VIM7.5

1.4 Overview of upgrade activities

Installation of the upgrade package

Post installation activities

 Activating Business Configuration Sets

VIM 7.5 Upgrade Guide 6

 Upgrade FAQ (VIM 7.0 documentation set)

VIM 7.5 Upgrade Guide 7

2.1 New document types

 Updates main screen configuration for document types.

NPO document types:

 Updates main screen configuration for document types.

Down Payment types:

 Updates main screen configuration for document types.

VIM 7.5 Upgrade Guide 8

2.1.1 Excluding a country from a business rule

2.1.3 Defining roles per country

VIM 7.5 Upgrade Guide 9

2.1.5 Changing the ArchiveLink document type of a document

2.2 New Indexing Screen

VIM 7.5 Upgrade Guide 10

2.2.1 Migrating the VIM standard fields ATTRIBUTE1 - 4 and CUSTOM_FIELD4 – 0

VIM 7.5 Upgrade Guide 11

2.2.3 Is the country specific sub-screen still supported?

VIM 7.5 Upgrade Guide 12

2.3 Business Rule Framework

2.4 New VAN Report

2.5 New Approval approach

VIM 7.5 Upgrade Guide 13

3.2 Old COA & simple, manager-based approval workflow

3.3 Old indexing screen

3.4 VIM Analytics

3.5 Integrated Invoice Cockpit

VIM 7.5 Upgrade Guide 14

4.1 Technical upgrade using version switch

 Product code: 005

4.2 Options for existing processes

4.2.2 Existing approval processes

If this approach is selected, the following points must be considered:

4.3 Functional Migration Areas

4.3.1 Implications of Business Rules Framework and Logic Modules

Business Rules Framework and Logic Modules

VIM 7.5 Upgrade Guide 16

Migrations of BRs to LMs in VIM 7.5 standard:

VIM 7.5 Upgrade Guide 17

Product code: 005

4.3.3 PO_LIST and DN_List

VIM 7.5 Upgrade Guide 18

5.2 Migration tool/steps documentation

 Updates main screen configuration for document types.

NPO document types:

 Updates main screen configuration for document types.