Professional Documents
Culture Documents
The document provides the overview of invoice approval process cycle in OpenText VIM for both PO and
Non-PO invoices along with important configuration steps involved. It also covers linkage of process types
and chart of authority in invoice approval process along with their configurations.
1. DP processing stage: Process type needs to be configured accordingly (steps to configure the
2.
process type are written below). Approval workflow can be started by clicking Submit for
Approval option.
After conversion of DP document into SAP parked invoice: Appropriate parking reason has to be
provided. Create parking reason if required. Based on the parking reason workflow starts.
Approval workflow is triggered by changing the parking reason. Trigger points can be configured
for this by going to /n/opt/spro > Configuration > Non PO Processing > Invoice Approval Process
> Approval Workflow > Additional Configuration Web Approval. Below is the screen shot.
Configure Process type: A process type needs to be created for approval when approval is required at
DP processing stage. Process type can be defined using transaction /n/opt/vim_8cx1. Below are the
important fields:
Initial Actor Function: If no initial actor is available then it is picked from the function module
specified here.
Is Exception: If this check box is selected then process type will be not be relevant for automatic
document processing.
Auto Start: If this check box is not checked then Initial Actor manually starts the workflow else it is
automatically started.
Workflow Type: Opentext Approval Workflow or External Workflow can be selected for this.
Task ID
Binding Function
Mail Config ID
Logical System: Enter the name of the system where the external workflow is supposed to run.
To receive and send email the configurations are done in the process type for respective function
modules.
Below are the important steps involved in the invoice approval configuration.
Defining Multi Level Approval: For PO invoices a custom extension is required. If the approver
rejects the invoice then it is send back to previous approver. If the first approver rejects the
invoice then it is send to AP department. The user from AP department has the option to select
the approver if process is started from DP dashboard. Approvers are maintained in Chart of
Authority.
Driving the Approval Flow for DP Invoices: The process starts when invoice gets the process type
for approval or Submit for Approval button is clicked. For Non-PO invoices the initial approver is
usually entered in the indexing screen in the Email ID field. For PO invoices the approver is the
requisitioner.
Driving the Approval Flow for Parked Invoices: The process starts when document is parked or
Submit for Approval button is clicked.
Defining Approval Hierarchy and Approval Level: Approval hierarchy can be implemented by
either using OpenText delivered approval hierarchy table or customization as per business needs.
OpenText delivered approval hierarchy table allows defining the approver, coder and respective
hierarchy for them along with approval amount, currency, company code and plant for which the
user is authorized to approve.
Defining the Expense Type: For few expenses (Marketing Expense, Office Supply,
Communication, Utility, etc.) a different path might be required and for this expense types are
configured which allows defining different approval limits for different expense types. Expense
type can be created by going to /n/opt/spro and then to LiveLink VIM - Configuration > Non PO
Processing > Invoice Approval Process > Setup Approval Chain > Expense Types > Maintain
Expense Types. Create the expense type, provide description and indicate if approval is required
for the expense type.
Defining Approval Access Rights: Some of the access rights are: Approve, Coding,
Coding_Display, Coding_Delegation, Override, Look_ahead and Configuration
Configuring the Email Notification: Approvers will receive email notifications if any new invoice is
waiting for their approval for this method Get_Approver_List of business object type /ORS/INVAP
is used to get the approvers and method SENDEMAIL is called to send the mail. The actual
function to create the send request is /PTGWFI/CP_SENDMAIL. The body of the mail can be
easily configured.
Configuring the Certify Message: When approver approves the invoice then a message is
displayed. This can be configured at /n/OPT/SPRO transaction and follow LiveLink VIM
-Configuration > Non PO Processing > Invoice Approval Process > Technical General > Invoice
Approval Configuration. Maintain the text id here that needs to be shown post approval.
Configuring General Ledger Fields and Search Help for Web Screen Fields: This can be done at
LiveLink VIM - Configuration > Non PO Processing > Invoice Approval Process > Financial
Processing > Online Coding > GL Titles.
Figure 6: General Ledger Fields and Search Help for Web Screen Fields
Chart of Authority:
Chart of Authority (COA) is required to setup the approval hierarchy for Non-PO invoices. In case of PO
invoices
baseline
implementation
determines
the
requester as the first approver and is the only approver unless a customization is done for PO approver.
In COA one can configure the approval hierarchy, the approval limit and coder for the invoice approval
process. T-code to access the COA is /n/opt/vim_7cx1. There are three views available in COA.
User Details View: It contains the general details for all the users like user id, users manager id, if
user is allowed for bulk approval or not, department of user, email address, telephone number,
default coder etc. If the requirement is to allow the approval to go first to the approver and then to
the manager then maintain the manager for the user in this view without manually entering the
user in COA Details View. The data for the user is automatically populated in COA Details View.
COA Details View: In this view the data for approval are maintained like approval amount up to
which approver can approve, currency for which approver is allowed to process approval,
company code and cost center for which approver is authorized etc. Thus it basically controls the
approver limit and scope of approval.
Coder Details View: This is where coders are maintained for the requester. Thus due to this
configuration the system knows from where to pick the coder for a particular requester. If the
Default check box is ticked then it means that user is always a coder.