DOCUMENT APPROVALS

WHITE PAPER
ORACLE PROCUREMENT 11.5.X

Author: Michael Filakosky

Oracle Corporation
Creation Date: March 06, 2002
Last Updated: May 08, 2002
Version: 1.0
Contents

Overview of Document Approvals………………………...………………….3

Purchasing Workflow Approvals Process…………………………………….3

Understanding Position Hierarchies………………………………….……….5

Understanding Employee/Supervisor Relationships………….……………7

Forwarding Methods ……………………………………………………..…….8

Understanding Approval Groups…………………………………..…………9

Debugging the Approval Workflow…………………………………………10

2
Overview
The focus of this paper will be on the approval of Purchase Orders and Purchase
Requisitions. Workflow, in short, can be considered an in-depth detailed
flowchart which, at each step, makes calls to various code segments which apply
to the overall process to be completed.

There are several important pieces that make up Workflow. The most common
pieces consist of the Workflow engine and the Workflow builder. Some
components of Workflow are the Workflow monitor and the Notification System.
The Workflow engine is the “workhorse” and handles the many different PL/SQL
calls against Workflow processes throughout the application. The engine consists
of a series of Workflow API’s which are called in unique sequences to execute the
assigned task or function. As these calls are made, the Workflow engine begins to
handle the requests based on the Workflow definition file that has been loaded
into the system. Workflow does not call the actual definition file located on the
server or some other location; instead, the file’s content is loaded into the
database and eventually called upon when the triggering event is executed.

Within Oracle Purchasing, Workflow has been designed to handle some of the
more intense decision-making processes. A Workflow Item Type represents a
grouping of a particular set of processes, messages, item attributes, and functions.
Each Item Type is introduced into the database via Workflow files. As the
Workflow definition is updated certain processes within the Workflow can be
preserved, usually customizations and modified item types. This ensures easy
migration to updated processes, as the customizations will not be overwritten by
future enhanced Workflow file releases.

Purchasing Workflow Approvals Process

Within each of the Item Types are a series of processes. Below is an example of
the layout of processes within the Standard Purchase Order Approval Workflow.

Question: How can it be known which process is going to be engaged for the
Workflow?
3
The answer lies in the Document Types form – from within Oracle Applications –
PO Super User.

In Purchasing, Setup > Purchasing > Document Types. Choose the option for
Standard Purchase Order from the menu that appears.

On the displayed this Document Types form, you will see the field ‘Workflow
Startup Process’.

The contents of this field determine what process Workflow should be used when
starting the approval flow in Oracle Purchasing at time of approval.

In this case – we see that the Workflow Startup Process is POAPPRV_TOP.

The correlation to this Workflow Startup Process comes when looking in the
Workflow builder at the properties of the PO Approval Top Process.
POAPPRV_TOP represents the top level process shortname within the Workflow
builder. In Release 11.5, this short name is instead populated with the actual top
level startup process, which in this case would be ‘PO Approval Top Process’.
The shortname is used in Release 11.0 instead, yet both represent the same.

In Release 10.7, the user would be prompted to enter a forward to employee if he

did not contain the appropriate authority to approve the document in question.
This coded warning message is no longer present in release 11.0 and 11.5.
Instead, the system utilizes the Workflow to locate the next employee in either the
Position Hierarchy or Supervisor specified on the employee record. If the
Workflow is unable to locate a next position or supervisor, the document will be
returned to an ‘Incomplete’ status and a notification will be sent to the employee
stating that ‘No Approver Found’. The Notification Summary and Purchase Order
action history should be checked if a document is considered to be ‘In-Process’
inappropriately.

The Workflow Monitor is the first tool that should be utilized to locate why a
document is in a ‘In-Process’ state. It can be accessed from the Summary screens
within the Oracle Purchasing Module. Navigation: Purchase Orders > Purchase
Order Summary or Requisitions > Requisition Summary. Use the initial FIND
form to enter search criteria to fetch the document in question. Upon retrieving
the document, choose ‘Tools’ from the top text menu, followed by a selection to
‘View Approval Through Workflow’ if Release 11.5, or ‘SPECIAL’ then ‘View
4
Approval Through Workflow’ for Release 11.0. A new session in your default
web browser will be launched revealing the route selected for the document
approval in question. Utilize the mouse to double click and drill down into
processes until the Green Line ending point is located. This is the current activity
waiting for some sort of action, such as a response, or the running of the
Workflow Background Process.

The Workflow background process is used to advance Workflow events to the

next set of processing. Different events within Workflow have been set to a
deferred status purposely, usually to await a response or update from a user. An
example of this would be a notification. By default, all Notifications have a
timeout period of two weeks. For example, if User A forwards a document to
User B, the initial notification that is sent to User B will have a two week timeout
period. Once the time out period expires, it is necessary to run the Workflow
background process to re-engage the process to advance to the next event. A total
of three notifications are sent to the user requesting action against the document in
question, after which the Workflow will automatically search for the next
approver in the hierarchy/supervisor position. The Workflow background process
should be scheduled at the minimum, once a day. This process is accessible via
the System Administrator responsibility, using ‘Requests > Run’.

Understanding Position Hierarchies

There are two options that can be used in Oracle Purchasing with regards to how a
document will be forwarded. The first and most common option is ‘Position
Hierarchy’. The system determines whether a Position Hierarchy should be used,
based on the setting within the Financial Options. Purchasing Responsibility –
Navigation: Setup > Organizations > Financial Options – Human Resources tab.
Here there is a checkbox ‘Use Approval Hierarchies’. If this box is checked,
Purchasing will utilize Position Hierarchies to route documents to for approval.

Each document type has it’s own default hierarchy. When a certain document is
created, the default hierarchy is searched and if the position of the employee
submitting the document for approval does not have the appropriate authority, the
document will be returned to an ‘Incomplete’ status, and the employee notified of
‘No Approver Found’. Workflow calls the code to locate the default hierarchy
for the document type submitted. The default hierarchy is then searched in
attempt to locate the position of the employee submitting the document. Once the
position is located, the next position for which an employee is assigned is located,
and the document is forwarded. If no position can be located, or the employee
which submitted the document for approval belongs to a position which is NOT in
the hierarchy, then the document will be set to ‘Incomplete’ and a ‘No Approver
Found’ message will be sent to the employee which submitted the document.

Within the Financial Options, under the same Human Resources tab previously
mentioned, is a field – Business Group. When employees are created, they are
assigned to a business group. The profile HR: Business Group determines which
grouping the employee will be created in. The profile is most commonly set

5
Responsibility level. Therefore, if a business group were created with the name
of ‘North America’, then all employees created while the profile HR: Business
Group ‘North America’ would be visible within the Purchasing Module for this
Operating Unit. The Financial Options within Oracle Purchasing are Operating
Unit specific. Therefore, employees do not belong to Operating Units instead,
their visibility is determined in Purchasing by the select made in the Financial
Options.

Approval authority is determined from the Position and Approval Group

assignment. Each position will be assigned an Approval Group for every
document type used in Oracle Purchasing – eight total. The employee is then
assigned to a position in the ‘assignment region’ of the ‘Enter Employee’ form. It
is this assignment that governs the approval authority for the employee. Positions
are assigned to Operating Units that are called upon during the approval cycle
when a document is submitted for approval within the Operating Unit.

It is important to keep in mind that when the system locates the next position in a
hierarchy, if multiple employees are assigned to the position, the system will
choose the first employee alphabetically based on the last name. This is important
to know when setting up a position based system, as there may be requirements
for certain employees to be part of an Approval Process. There is always an
option to change the ‘Forward To’ if users are allowed. But, if the system is
dependent only on users submitting via the Approve button with no forward to,
then the system is going to locate the next position of authority and then select the
employee based on last name, if multiple employees to one position.

6
In this diagram, the employee has been created within the Business Group – North
America. The Business Group has then been selected in the Financial Options for
the United States Operating Unit. The employee has also been assigned to a
Position that exists in the United States Operating unit, which in turn is tied to
Approval Groups created within the United States Operating unit. Essentially, the
employee is tied to the United States Operating Unit because of the business
group selection in the financial options. The employee gains approval authority
when actions are taken with a responsibility pointing to the MO: Operating Unit
of North America.

Position Hierarchies are more widely used in larger corporations as they offer
much lower maintenance. An example scenario would be as follows: Suppose
there was a department consisting of 100 employees all with the same supervisor.
These employees would be assigned to the position of Clerk, which in-turn
reports to the position Director. The Directory position would be assigned to one
individual, while the Clerk Position would be assigned to 100 employees. When
each of the 100 employees created requisitions, if the dollar amount should
exceed that allowed in the approval group for their position, the document would
then be routed to the Director, who in turn would represent a person.

In this example, if employee ‘C. Black’ should be promoted or leave the

company, a new employee could be assigned to the position Director, and after
running the ‘Fill Employee Hierarchy’ report, all requisitions created by Clerks
would now route to the newly assigned employee. However, if
Employee/Supervisor was being used, it would be mandatory that all 100
employee records be queried, and a new supervisor entered, as this is how the
system determines the forward to.

Understanding Employee/Supervisor Relationships

Unlike Positions, Employee/Supervisor utilizes Jobs. It is not mandatory to setup
Positions on a system that is going to be using Employee/Supervisor relationships.
The Human Resources tab in the Financial Options must have the ‘Use Approval
Hierarchies’ un-checked in order for Employee/Supervisor approval method to be
engaged. When an employee is assigned to a Job, the job must also be assigned to
an Approval Group. When an Employee submits a document for approval, the
system locates the employee’s job assignment, validates the document amount
7
against the approval group limits assigned to the job, and then the action to
Approve the document, locate a forward to, or forward action is taken. If the
employee does not have a supervisor, the document will be set to an ‘Incomplete’
status, and a message will be sent to the submitter stating ‘No Approver Found’.

Forwarding Methods
There are two types of Forwarding methods within Oracle Purchasing. The
forwarding method selection will come from the Document Types setup screen,
for the document selected upon opening the form initially. Purchasing
Responsibility – Setup > Purchasing > Document Types.

The two methods of Forwarding are ‘Direct’ and ‘Hierarchy’. Both methods can
be used regardless of whether using Position Hierarchies or Employee Supervisor.

When using the ‘Direct’ forwarding method and ‘Position Hierarchies’, the
system will search automatically, within the default hierarchy, to locate the next
position that has the Approval authority for the amount on the document being
submitted.

In the above scenario, if ‘Direct’ forwarding method was being used, should any
Clerk create a requisition over $100.00, it would skip the position of Director, and
instead forward to President. The system actually confirms that Director does not
have enough approval authority, and therefore the document is forwarded on to
the next position, President, resulting in a notification to C. Brown.

8
If Employee/Supervisor method is used and the forwarding method is ‘Direct’,
then the system will query employee records to review job assignments, and
locate the appropriate supervisor to forward the notification to. If choosing to use
the ‘Direct’ method, a supervisor must be entered on the Employee records.
Notice in the diagram the emphasis for forwarding has shifted from the
assignment to the Supervisor.

Understanding Approval Groups

Approval Groups define the rules to be considered when a document is submitted

for Approval. The group is a series of rules that can restrict approval authority
based on different factors, to include: Document Total, Account Range, Item
Category, etc… An Approval Group alone will have no bearing on a system. It
must be assigned to a position or job in order to be engaged. Within Oracle
Purchasing, it is possible to have different approval groups assigned to a position,
for different documents. This allows for different limitations to be imposed on
different document types.
The potential also exists for assigning multiple approval groups to the same
document type – for one position. When this is done, the least restrictive rule will
be accessed during the approval process. An example is as follows:
Position Clerk has the ‘Approve 100$’ approval group, and ‘Approve 200$’
approval group assigned to the document type of Purchase Requisition.
‘Approve 100$’ group has an account range of low – 1.1.1.1 and high – 9.9.9.9.
‘Approve 200$’ group has an account range of low – 0.0.0.0 and high - 2.2.2.2,
for 200$. This would mean that any requisition which has an account
combination 1.1.1.1 or 2.2.2.2 for up to 200$ dollars could be approved. Now, if
a requisition were created for 50$ using the account combination of 3.3.3.3, the
system still would NOT allow it to approve. The code will first validate that the
total, which is 50$, is below the 100$ limit in ‘Approve 100$’ group, which it is.
Next, the account will be validated, and 3.3.3.3 is between 1.1.1.1 and 9.9.9.9 for
‘Approve 100$’ group, which it is. Now, the system will move into ‘Approve
200$’ group. First, the total will be confirmed, and the 50$ is again less than the
200$ limit specified. Next, the account range will be validated, and 3.3.3.3 does
not fall between 1.1.1.1 and 2.2.2.2 in ‘Approve 200$’ group. Therefore the
validation of Approval authority fails. The system will now pursue the
appropriate action to locate the next approver.

9
Debugging the Approval Workflow
The first question in debugging the Approval Workflow is to know if the process
has ever worked. If, at an earlier time, the employee could create and approve a
purchasing document for an amount which is not rendering the document ‘In
Process’, then most likely something has changed either with the setup, the
employee, or the code level.

Step 1 – Review the action history of the document having a problem.

This is done in the Purchasing Summary screens – either

Requisitions > Requisitions Summary or Purchase Orders > Purchase

Order Summary. If you attempt to view the action history and you receive
the following error:
‘APP-14288 This document is either incomplete or you do not have
access to it’ then this represents that Workflow has not yet performed a
submit into the action history table. The document approval manager
performs the action of submitting a record into the Action History and
therefore is required to be running. It should be confirmed that the
document approval manager is running.

Step 2 – Notification Summary – review the Notification Summary for the

user that submitted the document. Are there any notifications present?
Because online form messaging alerts are now present in the form of
notifications, it is imperative that the summary be reviewed for any
informative notifications explaining in more detail as to the problem.

Step 3 – Confirmation that the Workflow Background Process has been

run via the System Administrator responsibility. This is done via Requests
> Run within the System Administrator Responsibility. The parameters
should be the Item Type – PO or Requisition Approval – and then
Processed Deferred = Yes, Process Time Out = Yes. Process Stuck = Yes,
if the Process Stuck parameter is available.

Step 4 – Ensure that all tables contain the necessary space to record the
Workflow processing data. As users submit a document for Approval and
the Workflow process is called, data is recorded into a series of Workflow
tables. To quickly confirm whether the tables are having space
limitations, please request the database administrator to run the following
in SQL:
select value
from v$parameter
where name like ‘background_dump_dest’;

The value returned by this SQL statement represents the location of the
alert
log on the database server, for the instance in question. Please ask the
Database Administrator to review the latest entries into the alert.log to
confirm if any errors are being thrown with regards to tablespace.
The most common scenario that has been linked to tablespace, is when a
10
 user hits the ‘Approve’ button in the approval screen, only to have nothing
happen. There is no message returned stating document has been
submitted for Approval, nothing happens. The hourglass comes for 1
second, and then leaves, and the approval form is still present. This is most
likely a tablespace issue.

Step 5 – Workflow Monitor from the Purchase Summary screens. Utilize

the Workflow monitor to track the path which the document has taken
during it’s submission to Workflow. Some important milestones to look
for in the Workflow monitor are ‘Can Owner Approve’ and ‘Does
Approver have Approval Authority’. Are there any processes that contain
errors? Or does it appear that a process has stopped at a point that is
incorrect? Example is if a process stopped at a point that is not referencing
a notification or some other request point for user interaction.

Conclusion
It is our desire that this paper has helped you understand the fundamentals of
Document Approvals We hope you are now better equipped to troubleshoot
problems and determine what needs to be done to resolve the Approval issue.

If you encounter a problem that requires assistance, please remember to log an

iTAR with Oracle Support.

About the Author

Michael Filakosky is a Technical Specialist with the Oracle Procurement Support

Group. He has been with Oracle Support for over 4 years.

11