9Define Approval Management for Procurement

This chapter contains the following:

Approval Management: Highlights

Use approval management to define policies that apply to approval workflows. For example, to reflect your own corporate policies, you can specify levels of approval for expense reports over a particular amount and determine how the approvals are routed.

Approval management:

  • Controls workflows for business objects such as expense reports.

  • Enables you to define complex, multistage task routing rules.

  • Integrates with the setup in Human Capital Management (HCM) to derive approvers based on the supervisory hierarchy.

To define approval management:

  • In the Offerings work area, enable the Approval Routing Administration feature for your offering so that relevant setup tasks are available.

  • In the Setup and Maintenance work area, use the following tasks under the Application Extensions functional area.

    • Manage Task Configurations

    • Manage Approval Groups

Task Configuration

Manage rule sets and rules that control approval flows.

Approval Groups

Each approval group includes a set of users that you configure to act on tasks in a certain pattern. Tasks can be defined to get routed to an approval group instead of an individual user.

Approval Rules: Explained

Approval rules are routing policies or rules that are evaluated to determine the approvers or FYI recipients for a business transaction.

Action Type

There are three types of actions:

  • Approval Required: The document or object will be routed for approvals.

  • Automatic: The document or object can be approved or rejected automatically.

  • Information Only: FYI tasks will be sent to notify the specified persons.

Route Using

The Route Using attribute identifies the type of users needed to approve or receive notification of a document. The following list is supported for document approval. Each type has a specific set of parameters or properties that must be defined. Route Using attributes include:

  • Approval Group

  • Job Level

  • Position Hierarchy

  • Single Approver

  • Supervisory Hierarchy

  • User-Defined Routing

Job Level

The Job Level attribute allows you to specify:

Approval Chain Of

  • Select the approval chain of the persons within a document, for example, preparer and requester in purchase requisitions, or a buyer in purchasing documents.

You can also choose to route approvals through a specific worker chain by selecting the name of the worker.

Start With

  • Identify the first participant in a list. The Start With attribute can be:

    • Manager (default value).

    • The value selected in the Approval Chain Of choice list.

Minimum Job Level

  • Indicate the number of job levels that are required to perform the approval action if the rule applies. For example, using the figure below, if Mary (Job Level 1) submits a document for approval and the Minimum Job Level is set to 3, then only John Allens must also approve.

This figure shows a hierarchy of employees and
their job levels, from 1 through 3.

Top Worker in Hierarchy

  • Identify the person at the top of the employee hierarchy, or the top person in the approval chain. In most cases, this is the CEO.

Include

  • Indicates if everyone returned in the list of participants from this action will be included, the first and last approver from the list will be included, or only the last approver will be included.

Position Hierarchy

Defined in Oracle Fusion Human Capital Management, positions are defined along with corresponding job levels, and employees are assigned appropriate positions. For example, the position Buyer is an instance of a position in the Purchasing Department. The job level of that Buyer could be any job level assigned to that position.

Position Hierarchy

  • Indicates if everyone returned in the list of participants from this action will be included, the first and last approver from the list will be included, or only the last approver will be included.

Position Chain Of

  • Select the approval chain of the persons within a document. For example, select preparer and requester in purchase requisitions, or a buyer in purchasing documents.

Start With

  • Identify the first participant in a list. The Start With attribute can be:

    • Next Position (default value).

    • The value selected in the Approval Chain Of choice list.

Minimum Job Level

  • Indicate the number of job levels that are required to perform the approval action if the rule applies. For example, using the figure below, if Job Level 1 submits a document for approval and the Minimum Job Level is set to 3, then only Job Level 3 must approve.

This figure shows a hierarchy of positions and
their job levels, 1, 3 and 5.

Top Worker in Hierarchy

  • Identifies the person at the top of the employee hierarchy, or the top person in the approval chain. In the most cases, this is the CEO.

Include

  • Indicates if everyone returned in the list of participants from this action will be included, the first and last approver from the list will be included, or only the last approver will be included.

Single Approver

Single approver allows you to route the approval to a specific person on the document, or a specific worker.

Supervisory Hierarchy

Approval Chain Of

  • You can select the approval chain of the persons within a document. For example, preparer and requester in purchase requisitions, or a buyer in purchasing documents.

  • You can also choose to route approvals through a specific worker chain by selecting the name of the worker.

Start With

  • Start With identifies the first participant in a list. The Start With attribute can be:

    • Manager (default value).

    • The value selected in the Approval Chain Of choice list.

Number of Approval Levels

  • The number of approvers in the supervisory hierarchy starting with the person specified in Start With.

Top Worker in Hierarchy

  • The Top Worker in Hierarchy identifies the person at the top of the employee hierarchy, or the top person in the approval chain. In the most cases, this is the CEO.

User-Defined Routing

You can configure user-defined attributes to return a single user, or a list of users, to whom human tasks can be routed.

Project Information in Approval Rules for Requisitions and Orders: Explained

You can set up approval rules and routings, for requisitions and purchase orders, based on sponsored project information.

Aspects of using project information in approvals that are covered in this topic include:

  • Example

  • Attributes

  • Setup

Example

Use the award contract number attribute in an approval rule condition, to evaluate if a purchase order distribution is associated to a sponsored project. Then add the principal investigator in charge of the award as an approver to the approval workflow, to ensure they approve expenditures against the award.

Attributes

Some of the project attributes you can use for approval rules and routings include:

  • Award Owning Business Unit

  • Award Purpose

  • Award Type

  • Contract Number

  • Funding Source

  • Principal Investigator

For more information refer to the white paper available on My Oracle Support (MOS): Setting Up Document Approvals for Oracle Fusion Procurement (document ID 1967303.1).

Setup

Set up approvals using the Manage Requisition Approvals and Manage Purchasing Document Approvals tasks. They are located in the Setup and Maintenance work area, Procurement offering, Approval Management functional area, under the Define Approval Management for Procurement task list.

Procurement Category Hierarchy in Approvals: Explained

A procurement category hierarchy can be used for approval rules, account generation, and reporting.

Approval Rules

Within the procurement category hierarchy, you can set up approval rule conditions using up to 10 levels of categories.

For example, the graphic below shows four levels of categories for IT level spend.

This figure shows four levels of categories for
IT level spend

If you have approval policies that apply to all hardware categories, you need only one rule condition applied to the highest hardware category level in the hierarchy. The rule might be, for example, if procurement category hierarchy level 2 equals hardware, then route the requisition to the IT approval group for approvals. This way, you do not need separate approval policies for the lower levels (notebooks and standard laptops).

In this example, any changes you make to the categories below hardware would not affect the approval policy rule because everything rolls up to hardware.

You can use procurement category hierarchies for approvals is available for requisitions, purchasing documents, and negotiation approval tasks.

Account Generation

You can also use procurement category hierarchies for deriving accounts. You can use the top 10 levels of categories for account mapping sets. Using the same example above, the input source can be based on hierarchy level 2, and the mapping can be set for hardware to derive an account. Anything that rolls up to level 2 can then use a specific account.

There is a seeded mapping set that is used to derive natural account segments based on the requisitioning BU and Procurement Category Hierarchy Level 1.

Reporting

BI reports can also be created using procurement category hierarchies. You can use the top 10 level categories in the procurement category hierarchy to run reports on requisitions, purchasing, and sourcing.

Creating an Approval Rule Using a Procurement Category Hierarchy: Worked Example

This example shows how to use a procurement category hierarchy to set up an approval rule for purchase orders for hardware and software.

Use a procurement category hierarchy having the level 2 category, Information Technology, to set up an approval rule. Set up the approval rule to route hardware and software purchases to the information technology (IT) approval group. This table summarizes key decisions to consider, and the decisions made for this scenario.

Decisions to Consider In This Example

Do you want to set up an approval rule for requisitions, purchase orders or negotiations?

Set up an approval rule for purchase orders.

Do you have an existing approval group for your IT organization?

Assume an approval group named IT Approvals exists.

Do you have an existing procurement category hierarchy to use?

Assume the example procurement category hierarchy is set up and available for use..

What procurement category hierarchy level do you want to use for the rule?

In this example, use the level 2 category Information Technology.

Example Procurement Category Hierarchy

The example procurement category hierarchy has the following levels:

  • No level number: Root

  • Level 1, under Root: Indirect spending.

  • Level 2, under Indirect: Marketing, IT, and Legal Services

  • Level 3 item categories, under IT: Software, Hardware, and Peripherals

This figure illustrates the structure of the example procurement category hierarchy for information technology purchases.

Example procurement category hierarchy for information
technology purchases of software, hardware and peripherals.
Note: You can create more than 10 levels under the root category of a procurement category hierarchy. You can only set up approvals based on the top 10 levels.

Prerequisites

This example assumes the following prerequisites setups are completed.

  1. A procurement category hierarchy is created, using the Manage Procurement Category Hierarchy page. Find the page in the Setup and Maintenance work area, Procurement offering, Procurement Foundation functional area, Manage Procurement Category Hierarchy task.

  2. An IT approval group is created, using the Manage Approval Groups task. Find this task in the Setup and Maintenance work area, Procurement offering, Approval Management functional area.

Creating the Approval Rule

  1. In the Setup and Maintenance work area, select the Procurement offering.

  2. On the Setup: Procurement page, click the Approval Management functional area, then click the Manage Purchasing Document Approvals task.

  3. On the Manage Purchasing Document Approvals page, select an approval stage for your rule. For example, select the stage Post Approval First Responder Wins. This table lists the attributes for the stage.

    Field Value

    Routing

    Parallel

    Voting Regime

    First Responder Wins

  4. Click the Edit Rules button to open the Edit Approval Rules page.

  5. In the Rules section, Actions list, select Create. Give the rule a name such as IT Approvals.

  6. In the IT Approvals Details section add a condition stating "Procurement Category Hierarchy Level 2 Equals Information Technology." Complete the fields as shown in this table.

    Field Value

    Attribute

    Procurement Category Hierarchy Level 2

    Operator

    Equals

    Value

    Information Technology

  7. In the Actions section, click the Add Action button. Complete the fields as shown in this table.

    Field Value

    Action Type

    Approval Required

    Route Using

    IT Approval Group

  8. Click Save.

Managing Funds Override Approval Rules for Requisitions and Purchase Orders: Explained

You can use procurement document approval rules to manage insufficient funds override approval flows for your organization's requisitions and purchase orders.

To view the delivered procurement document approval rules for requisitions and purchase orders, respectively, use the following tasks. You can find them in the Setup and Maintenance work area, Procurement offering, Approval Management functional area:

  • Manage Requisition Approvals

  • Manage Purchasing Document Approvals

The delivered funds override approval rule for requisitions has the following attributes:

  • Stage: Header Postapproval Stage

  • Participant: Funds Override Approval

  • Routing: Parallel

  • Voting Regime: Consensus

  • Enabled: Check box is selected.

You cannot edit this rule on the Manage Requisition Approvals page. You can only enable or disable it.

You can define a funds override approval rule different from what is delivered. You can add conditions based on these attributes:

  • Funds Override Approver

  • Funds Override Approver User Name

For example, you might define a condition where a certain approver can route the document to another approver.

The delivered funds override approval rule for purchase orders has the following attributes:

  • Stage: Postapproval Stage

  • Participant: Funds Override Approval

  • Routing: Parallel

  • Voting Regime: Consensus

  • Enabled: Check box is selected.

You cannot edit this rule on the Manage Purchasing Document Approvals page. You can only enable or disable it.

You can define a funds override approval rule different from what is delivered. For example, you might want to have funds override approval for purchase orders occur at the preapproval stage rather than the postapproval stage. To define the rule set the attribute values as follows:

  • Stage: Preapproval Stage.

  • Participant, Routing, Voting Regime, Enabled: Same values as for the delivered rule for purchase orders.

  • Conditions: Funds override approver is not blank.

  • Action Type: Approval Required.

  • Route Using: Single Approver.

  • User Type: Funds override approver.

Setting Up Approval Rules for Purchasing Documents with Outside Processing Items: Explained

You can set up approval rules for purchase orders and blanket purchase agreements that have at least one outside processing item.

To do this use the Manage Purchasing Document Approvals task. You can find it in the Setup and Maintenance work area, Procurement offering, Approval Management functional area. On the Edit Approval Rules page, use the Includes Outside Processing Items attribute to define a condition for purchasing documents having outside processing items. The attribute is available to use in a condition at the document line or header level.

Nested Approval Rule Conditions: Explained

You can setup rule conditions that include AND or OR operators. Conditions can be nested within another condition.

Example of a Nested Condition

An approved policy has a condition that says if destination type is Expense, and Cost Center is 111 or 112, then approval is required from Pat Stock.

This condition would be configured as follows:

CONDITION
    Destination Type equals Expense
   AND
      Cost Center equals 111
     OR
      Cost Center equals 112
ACTIONS
Action Type: Approval required
Route Using: Single approver
User Type: Worker
Worker: Pat Stock

Setting Up the Worklist Region on My Dashboard: Points to Consider

Worklist: Notifications and Approvals is one of the predefined regions users can add to My Dashboard (Navigator > My Dashboard), which is blank by default. This region contains workflow tasks. To set up this Worklist region, select a value for the Welcome Dashboard Worklist Timeout Interval (ATK_HOME_PAGE_WORKLIST_TIMEOUT) profile option. In the Setup and Maintenance work area, use the Manage Application Toolkit Administrator Profile Values or Manage Administrator Profile Values task to set this profile option.

Profile Value Considerations

When users open My Dashboard and it contains the Worklist: Notifications and Approvals region, data for the region is retrieved. The profile option determines how long to continue retrieving before timing out and displaying no data.

  • If you don't set a value for this profile option, which is blank by default, then the region doesn't time out.

  • Retrieving data for the Worklist region affects the performance of My Dashboard as a whole. So, select a value for this profile option if your users have the Worklist region on My Dashboard and notice performance issues.

After the timeout, users can refresh the region to try retrieving the data again.

Managing User-Defined Attributes in Approvals: Explained

User-defined attributes can be of two types: currency based, or summation.

Currency Based

You can define currency-based attributes to convert transaction amounts into a common currency, then define approval rules for only that specific currency.

For example, requesters in your organization may be creating requisitions in multiple currencies. But, your organization's approval policy requires requisitions with amounts over 500 USD be approved by the requester manager. You can set up this approval routing rule by defining an attribute, Requisition Amount in USD, and using it in a rule condition.

Define the attribute as follows:

  • User-Defined Attribute: Requisition Amount in USD

  • Type: Currency based

  • Attribute to Convert Type: Approval task attribute

  • Attribute to Convert: Requisition Amount

  • Convert To: USD

  • Conversion Rate Type: Corporate

Once you have defined the attribute, then it can be used in the rule condition as follows: Requisition Amount in USD greater than 500

Summation

Summation allows you to use values computed based on specific attributes across lines, schedules, and distributions within a document. You can specify a rule condition to use a value based on summation data. For example, you can set up a procurement category hierarchy through the setup task: Manage Procurement Category Hierarchy where you can define a hierarchy of groupings of purchasing categories.

This figure shows an example of a procurement category hierarchy. The top-level category, Information Technology (IT), includes the next lower-level category Components for Information Technology. The Components for Information Technology category includes two lower-level categories: System Cards, and Computers. Included under each of those two lowest-level categories are, respectively, specific memory module cards and computer servers.

This figure shows an example category hierarchy
for Computers and System Cards. The two categories roll up to the
Components for Information Technology category, which rolls up to
the top-level Information Technology category.

If the approval policy is: If the requisition contains lines from IT where the lines total is greater than 500, then route the requisition to the IT group for approval.

To achieve this, create a user-defined attribute for IT Spend as follows:

  • User-Defined Attribute: IT Spend

  • Type: Summation

  • Attribute: Distribution Amount

  • Match Using: Hierarchy

  • Category Name Rolls up To: IT

When defining summation attribute, you can use distribution amount or the distribution approval amount. You can also apply up to three filter criteria on the lines or distributions of the transaction using attribute or hierarchy. For match using hierarchy, the following hierarchies can be used:

  • Balancing Segment

  • Category Name

  • Cost Center

  • Management Segment

  • Natural Account

The following is a sample approval rule using the IT Spend user-defined attribute:

CONDITION
	IT Spend greater than 500
ACTION
	Action Type: Approval Required
	Route Using: Approval Group
	Approval Group: IT Spend Approvers

Manage Requisition Approvals

Setting Up Requisition Approval Task: Critical Choices

To facilitate the approvals setup process, the following preconfigured requisition approval elements are available:

  • Requisition Approval task

  • Stages

  • Participants

In the Setup and Maintenance work area, use the Manage Requisition Approvals task in the Approval Management functional area to configure requisition approval rules.

The following figure depicts the stages seeded for requisition approvals and also indicates that the stages are seeded in sequence.

This figure shows the seeded approval stages in
Oracle Fusion Self Service Procurement.

Approvals are routed through the seeded stages in the following sequence:

  1. Header Preapproval Stage

    The following figure shows seeded participants in the header preapproval stage.

    This figure shows the seeded participants in the
header preapproval stage.
  2. Header Stage

    The following figure shows seeded participants in the header stage.

    This figure shows the seeded participants in the
header stage.
  3. Header Postapproval Stage

    The following figure shows seeded participants in the header postapproval stage.

    This figure shows the seeded participants in the
header postapproval stage.
  4. Postapproval FYI Stage

    The following figure shows seeded participants in the postapproval FYI stage.

    This figure shows the seeded participants in the
postapproval FYI stage.

There are four seeded stages for requisition approvals and within each stage, there are seeded participants. The non-FYI participants are seeded as rule based, which lets you pick the list builder (Supervisory, Position, Job Level, Single User, User-Defined Routing, and Approval Groups) that is applicable for your organization.

Line and distribution level rules can be defined within the stages with header dimension.

Header Preapproval Stage

This is used to route requisitions for preapproved requisitions, such as emergency requisitions.

Seeded Participants:

  1. Requester FYI

    • The requester on every line for a requisition receives a requisition FYI notification. This allows requesters to be notified when a preparer creates a requisition on their behalf. Each requester on every requisition line is notified. The rule to notify the requester is available out of the box, hence you do not need to perform additional steps for this.

  2. Preapproval Header Consensus

    • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.

  3. Preapproval Header First Responder Wins

    • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject represents the outcome of all remaining approvers.

  4. Preapproval Header Hierarchy

    • Approvals are routed in serial for this participant.

Header Stage

The header stage is often used for fiscal approvals, based on the requisition amount.

Seeded Participants:

  1. Header Hierarchy

    • Approvals are routed in serial. This participant is generally used for supervisory or position hierarchy-based routing.

    • The approvers returned based on all rules that apply in a serial participant are notified in sequence, even if the rules are evaluated against lines or distributions.

  2. Header Hierarchy 2

    • Approvals are routed in serial.

    • If your organization has a requirement to have a second hierarchy-based routing in parallel to the Header Hierarchy participant, rules should be maintained in this participant.

  3. Header Hierarchy 3

    • Approvals are routed in serial.

    • Similar to Header Hierarchy 2, this participant allows another hierarchy-based routing in parallel to Header Hierarchy and Header Hierarchy 2 participants.

  4. Header Stage Consensus

    • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.

  5. Header Stage First Responder Wins

    • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject represents the outcome of all remaining approvers.

Overriding Approvers

If there are cases where requesters might need to change the starting approver for supervisory-based routings, approval routing rules can be created using the overriding approver attribute at the requisition header level. You can create approval and FYI rules using this attribute, as part of the rule condition or action.

Note:

If you set up the overriding approver attribute, you may also send an FYI task to the original system generated first approver notifying the original approver that they have been bypassed.

Header Postapproval Stage

This is used to route for post approvals.

Seeded Participants:

  1. Header Consensus

    • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.

  2. Header First Responder Wins

    • Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject represents the outcome of all remaining approvers.

  3. Postapproval Header Hierarchy

    • Approvals are routed in serial for this participant.

Postapproval FYI Stage

The Post Approval FYI stage is created to send the requisition preparer an FYI notification on the outcome of the requisition approvals.

This stage is not available in the BPM Worklist or Approvals UI pages for customization.

Note

You do not need to use all of the seeded stages and participant. However, if you do not need to use any of the seeded participants, you simply need to select the Enable or Disable action for the respective participant on the Manage Approval Task page.

Setting Up Self Service Procurement Task Driven Configuration: Explained

Task driven configuration is set up in the BPM Worklist Administration application. To manage task configuration, you must be a BPM Worklist administrator.

This table shows the default task configuration options for Oracle Fusion Self Service Procurement. For each configuration option the corresponding default value is listed, along with a description of the effect of the default value.

Configuration Option Default Value Effect of Default Value

Task Aggregation

Once per task

Within the same task, if a participant is returned multiple times based on the approvals rules, then the participant will only receive one worklist task for action or review.

Allow all participants to invite other participants

Yes (checked)

Participants can add other approval or FYI participants in the approval list.

Allow participants to edit future participants

Yes (checked)

Participants can update or remove participants remaining in the approval list who were not assigned the approval task.

Allow initiator to add participants

Yes (checked)

A requisition preparer can insert ad-hoc approval or FYI participants.

Enable automatic claim

Yes (checked)

Enabled when a task is assigned to a position, role or a LDAP group. Since there can be multiple users in a position, role, or group, a user has to first claim the task to prevent multiple users from updating the task. This does not include approvals based on approval groups. Enabling auto claim will not require a participant to first claim before performing an action, hence reducing the number of steps.

Complete task when participant chooses

Reject

The entire requisition approval task will be completed when a Reject action is performed by a participant.

Enable early completion of parallel subtasks

Yes (checked)

The entire requisition approval task will be completed when a Reject action is performed by a participant.

Complete parent tasks of early completing subtasks

Yes (checked)

The entire requisition approval task will be completed when a Reject action is performed by a participant.

Approval Rules for Internal Material Transfer Requisitions: Explained

You can use approval rules to route and manage requisitions with internal material transfer line items.

Approval rules to route and manage requisitions with internal material transfer line items can be configured just as they can for purchase requisition line items. You can also use the Source Organization as a parameter in approval rules.

You can configure approval rules taking into consideration your internal material transfer requests. The 'Internal Transfer Requisition' approval attribute indicates whether all lines of the requisition are for internal material transfer or not. This allows you to decide on the approval routing for your internal transfer requisitions. In addition, you can define rule conditions based on the requisition line attributes source organization and source type.

If your organization does not require approvals for internally sourced items, you can configure a rule to bypass approvals when all lines in the requisition are sourced internally.

Manage Supplier Registration Approvals

Supplier Registration Approval: Explained

To support separate approval routing for the external supplier registration and internal supplier registration flows, there are two distinct approval tasks in AMX:

  • Manage Supplier Registration Approvals

  • Manage Internal Supplier Registration Approvals

Both the tasks are predefined with two stages:

  • First Stage Approvals

  • Second Stage Approvals

These stages are modeled as serial stages. All first stage approvals must be completed before the second stage approvals routing rules are executed.

Each stage includes three participants:

  • Parallel Approval First Responder Wins

  • Parallel Approval

  • Serial Approval

First Stage Approvals

The parallel approval first responder wins participant is predefined with two approval rule policies:

  • Route registration for prospective supplier to supplier administrator.

  • Route registration for spend authorized supplier to supplier manager.

Second Stage Approvals

The second stage allows for additional approval rules to be run as a distinct set after the first stage approvals are completed.

Setting up Supplier Registration Approvals Task: Critical Choices

The following preconfigured components facilitate the supplier registration approvals setup:

  • Registration Approvals task

  • Stages

  • Participants

  • Seeded approval policy

To access the supplier registration approvals tasks, navigate toSetup and Maintenance work area > Approval Management functional area.

Use the Manage Supplier Registration Approvals task to configure approval routing rules for registrations submitted by external users of companies interested in becoming a supplier.

Use the Manage Internal Supplier Registration Approvals tasks to configure approval routing rules for registrations submitted by internal users on the company's behalf.

The following figure shows the seeded supplier registration approval stages that are executed in Oracle Fusion Supplier Portal.

This figure shows the seeded supplier registration
approval stages. First stage approvals, and second stage approvals.

Approval rules configured in the seeded stages are executed in the following sequence:

  1. First stage approvals

  2. Second stage approvals (Only executed after all first stage approvals are completed.)

The following figure shows the first stage approvals.

This figure shows the first stage approvals.

The following figure shows the second stage approvals that are executed after all first stage approvals are completed.

This figure shows the second stage approvals.

Approval Stages

Approvals to review supplier registration requests happen in a flexible two-stage process.

Within each stage, there are three seeded rule-based participants. You can pick a routing type (Supervisory, Position, Job Level, Single User, and User-Defined Approval Groups) to configure the list of approvers entitled to receive the document for approval.

You do not need to use all of the seeded stages and participants. You can disable unused participants by selecting the unused participant on the Manage Approvals Task page and clicking the Disable button.

First Stage Approvals

Based on your supplier registration approval requirements, choose which seeded participants should have approval rules configured since each participant has a different approval routing behavior.

The three seeded participants are:

  • Parallel Approval First Responder Wins

    All identified approvers receive a notification for approval in parallel. The first responder to approve or reject the request defines the outcome of all remaining approvers.

  • Parallel Approval

    All identified approvers receive a notification for approval in parallel. Approval is required from all approvers.

  • Serial Approval

    Approvals are routed in serial. The approval is completed sequentially from approver to approver.

Second Stage Approvals

Seeded participants are similar to those in the first stage with similar routing properties:

  • Parallel Approval First Responder Wins

    All identified approvers receive a notification for approval in parallel. The first responder to approve or reject the request defines the outcome of all remaining approvers.

  • Parallel Approval

    All identified approvers receive a notification for approval in parallel. Approval is required from all approvers.

  • Serial Approval

    Approvals are routed in Serial. The approval is completed sequentially from approver to approver.

Seeded Approval Policy

The following approval rules are seeded.

Approval rules are seeded in the first stage participant: Parallel Approval First Responder Wins. You can modify or delete the seeded rules.

  • If supplier registration has business relationship of Prospective, then route to supplier administrator.

  • If supplier registration has business relationship of Spend Authorized, then route to supplier managers.

Supplier Managers are derived from the users defined in procurement agents. All procurement agents with Manage Suppliers function for the BU that the registration was created will receive the approval notification.

Even if new rules are not configured, the seeded rule will execute unless it is deleted.

Note: You can, at any point of time, modify or delete the seeded rule.

Configuring Supplier Registration and Supplier Profile Change Request: Points to Consider

Use the Configure Supplier Registration and Profile Change Request page to configure the supplier registration and self service supplier profile change request approval requirements.

Supplier Registration

You can configure the supplier registration process based on the expected supplier business relationship of a supplier.

You can define two separate registration flows based on the intended business relationship.

  • Spend Authorized Supplier requests: Companies already identified for a procurement need are directed by the buying organization to the spend authorized registration flow. The flow captures more rigorous profile information needed before agreements, orders, and invoices can be transacted. For example, a spend authorized company registering can be required to provide bank account information.

  • Prospective Supplier requests: Unknown companies are presented with the prospective supplier flow. They must only provide minimal profile information to participate in the sourcing and supplier qualification activities.

Possible profile components that you can include during a registration flow include:

  • Organization Details: Basic supplier information including the supplier name.

  • Contacts: Supplier contact information.

  • Contact User Account: User accounts control privileges for Supplier Portal contacts.

  • Addresses: Company addresses including associated contacts.

  • Business Classifications: Supplier certifications important to the buying organization such as supplier diversity programs.

  • Bank Accounts: Supplier banking information.

  • Products and Services: Identifies what categories of products and services are provided by the supplier.

  • Qualifications Questionnaire: Additional questions for suppliers.

When you configure the two supplier registration flows you identify which profile attributes the supplier sees. Also you can specify whether the supplier must enter a value for the attribute.

  • Enabled: The attribute is displayed to the supplier, but the supplier is not required to enter information.

  • Required: The supplier must supply information for this attribute.

Note: Your supplier registration configuration applies to suppliers from all registration sources.

Default Business Relationship for Registration Sources

A supplier registration can come from one of the following three sources:

  • Internal Sourcing Invitation: Supplier can be invited to register from a sourcing negotiation.

  • Internal Supplier Request: Supplier can be invited to register by a supplier administrator during the course of defining the supplier..

  • External request from the supplier when self-registering using your organization's external supplier registration website.

In the Default Business Relationship for Registration Sources region, you identify the default business relationship for each registration flow. The default business relationship determines what profile information is included as configured for the registration page.

Post Approval Options

Once a new supplier's registration is approved, or its status promoted to spend authorized, the application automatically creates site assignments for any new sites defined for that supplier. However, you can retain control over how the supplier's site assignments are created by deselecting the check box Autocreate site assignments for spend authorized suppliers. If you deselect this check box, site assignments for a supplier are no longer created automatically. You must create them manually.

Registration URL Encryption

When a prospective supplier saves the registration for later completion, the application sends an email to the prospective supplier containing the registration URL. The URL contains an identifier which is encrypted using an encryption key. This prevents users from altering the URL to view registrations submitted by other companies.

If you suspected that registrations have been tampered with, you can regenerate the encryption key. After the registration key is regenerated, registrations saved for later are no longer accessible to their prospective suppliers.

Supplier Registration URLs

You use different supplier registration URLs for each business relationship type (prospective and spend authorized). Your suppliers can then use the appropriate URL to register with your company. Each URL contains a parameter for the business relationship type that navigates your supplier to a registration page.

You can set the registration URL for each business relationship type on the Configure Procurement Business Function page. You can set URLs for both prospective supplier registration and spend authorized registration.

Supplier Profile Change Request

Use the Supplier Profile Change Request tab to configure the approval requirement settings for changes to supplier profile attributes through a change request. The settings apply to supplier initiated profile change requests and to change requests resulting from Supplier Qualification or Sourcing questionnaires. The values you set here apply to supplier profile change requests from any source: Suppliers, Supplier Qualification, and Supplier Negotiation.

You can specify approval requirements for prospective and spend authorized suppliers for the following entities:

  • Organization Details: Basic supplier information including the supplier name and supplier profile level descriptive flexfields.

  • Contacts: Supplier contact information including supplier contact descriptive flexfields.

  • Contact User Account: User accounts that control account privileges for supplier contacts to use Supplier Portal.

  • Addresses: Company addresses including associated contacts including supplier address descriptive flexfields.

  • Business Classifications: Supplier certifications important to the buying organization such as supplier diversity programs.

  • Bank Accounts: Supplier banking information.

  • Payment Methods The method used to pay the supplier.

  • Products and Services: Identifies what categories of products and services are provided by the supplier.

  • Tax Identifiers: Tax organization, tax country, and taxpayer ID to identify the supplier for tax purposes.

  • Site Details: Site information such as the address and site purpose (spend authorized suppliers only).

For each profile attribute, you can specify:

  • No Approval Required: Change request is approved.

  • Approval Required: Change request is routed for approval.

Configuration of the Site Details attribute for prospective suppliers is not available.

Approval Task: Explained

In many end-to-end business processes human intervention is required such as for approving documents, managing exceptions, or performing activities required to advance the business process. The document approval request tasks allow you to send approval requests to approvers enabling them to make decisions and thus advancing the request-to-pay business process.

A different approval task is created for each approval need based on the business it serves. For example, purchase requisitions approvals; expense reports approvals, and so on.

From the setup task manager, you can pick the corresponding task to setup approvals for procurement document objects. For example:

  • Manage Requisition Approvals

  • Managing Purchasing Document Approvals

    • Note: Purchasing uses one task for both agreements and purchase orders.

Based on your unique business requirements, administrators can choose to send the approval request to approvers in parallel or in sequence. Approvals can be sought using single approver, supervisory chain, position, job level hierarchy, or using a list of approvers.

This figure shows the structural hierarchy of the components used in setting up an approval request task: Stage, Participant and Rule.

  • A stage includes a dimension, participant and rule.

  • The participant includes a routing type, voting regime and rule.

  • The rule includes a condition and action.

The key components of approval request task: Stage,
Participant and Rule.

Stage

A stage allows you to organize approval routing rules into logical groupings. Each stage is associated with a dimension. A dimension contains a set of attributes at a specific purchasing document level, such as header or lines, which can be used to author routing rules. Approval actions within each stage must be completed before entering the next stage.

Participant

There can be many participants within a stage. Properties set on the participants determine whether approvals would be routed in serial or in parallel.

Oracle Fusion Procurement is seeded with one or more participants within each stage to enable flexibility in document approvals routing.

The following are two properties defined on a participant:

  • Routing Type: The supported routing types are: Serial, Parallel and FYI. FYI participants cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.

  • Voting Regime: The supported voting regimes are: Serial, Consensus, and First Responder Wins.

Rule

Approval rules are routing policies or rules that determine the approvers or FYI recipients for a business transaction.

  • Condition: The IF clauses in an approval rule and evaluated to either true or false. For the rule to apply to a transaction, all of its conditions must be true. An example of a condition is: If requisition approval amount is less than 500 USD, or if requisition approval amount is between 500 USD and 10000 USD.

  • Action: Instruction to include a given set of approvers within an approval rule.

Other Workflow Setup

Disabling and Enabling Workflow Notifications: Procedure

When a workflow task is assigned to users, they get notifications through email and, depending on setup, through other channels also, such as instant messaging. Workflow tasks are managed in the Worklist: Notifications and Approvals work area and configured in the Setup and Maintenance work area using the Manage Task Configurations task. If you have the BPM Workflow System Admin Role (BPMWorkflowAdmin) role, you can disable or enable these notifications for all users. For example, you can disable notifications during testing, to avoid sending test notifications to users, and then enable notifications when ready.

When you disable notifications:

  • Email notifications that are not for workflow are still sent to users.

  • New workflow notifications won't appear in the global header.

  • Users can still find their workflow tasks in the Worklist: Notifications and Approvals work area.

Setting Notification Mode

To disable or enable workflow notifications:

  1. Click the Notifications icon on the global header.

  2. Click More Details.

  3. In BPM Worklist, click your user name and select Administration.

  4. On the Administration tab, under Application Preferences, select a value from the Notification Mode list:

    • All: Email and any other configured notification channels are enabled. This is the default value.

    • None: All notifications are disabled, including email.

    • Email: Only email notifications are enabled.

  5. Click Save.

Can I define what appears in the From field for workflow e-mail notifications?

By default, the From field in workflow emails displays an email address without a sender name. You can't change the email address, but you can specify the sender name.

  1. Click the Notifications icon in the global header.

  2. Click More Details.

  3. Click your user name and select Administration.

  4. On the Administration tab, under Application Preferences, enter a value in the Sender's Name field.

  5. Click Save.

For example, if you enter Company Name, then the From field displays: Company Name <<your pod>.fa.sender@workflow.mail.<your data center>.cloud.oracle.com>.

Synchronizing Notifications in the Global Header with Workflow Tasks: Points to Consider

When a workflow task is assigned to users, they get an email as well as a notification in the global header. They can also find all of their workflow tasks in the Worklist: Notifications and Approvals work area. The notifications in the global header don't immediately reflect changes to the task status due to actions taken elsewhere, for example through email. Use the Synchronize Notifications in Global Header scheduled process to update the notifications with the latest task statuses, which are always reflected in the Worklist: Notifications and Approvals work area.

Scheduling the Process

In the Scheduled Processes work area, submit the Synchronize Notifications in Global Header process with a defined schedule. For example, schedule the process to run every two hours.

Effects of the Synchronization

After the scheduled process runs, notifications in the global header might move from the Pending Notifications list to the All Notifications list. For example:

  1. A notification is pending a user's approval.

  2. The user approves the task using the Worklist: Notifications and Approvals work area. The task status changes, but the notification in the global header is still in the Pending Notifications list.

  3. After synchronization, the notification moves to the All Notifications list because the user has changed the task status to Approved, and the notification is no longer pending action.

The scheduled process doesn't update the title of notifications in the global header. Similar to email subjects, the notification titles are static.

Determining When Workflow Tasks Are Automatically Dismissed or Withdrawn: Points to Consider

Only workflow tasks with a final status, such as Completed or Withdrawn, can be purged and removed from users' worklists. Tasks go from the Assigned status to the Completed status when the final assignee approves or rejects the tasks, or, with for your information (FYI) tasks, when assignees explicitly dismiss the tasks. If assignees don't take actions that result in a final task status, within a certain period of time, then the tasks are automatically dismissed (FYI tasks) or withdrawn (all other tasks).

When Tasks are Eligible for Automatic Dismissal or Withdrawal

The FYI Notifications Expiration Period profile option determines when FYI tasks are eligible for automatic dismissal. In the Setup and Maintenance work area, use the Manage Applications Core Administrator Profile Values or Manage Administrator Profile Values task to set the profile option.

  • Leave the profile option with the default value of 7, or replace it with a different number.

  • The profile value represents the number of days after the FYI task is created.

When assignees don't read or dismiss an FYI task within the specified number of days after the task was created, the task is then eligible to be automatically dismissed.

All other tasks are eligible for automatic withdrawal when assignees don't take action to send the task to a final status within six months after the task was created.

When Eligible Tasks Are Automatically Dismissed or Withdrawn

Different processes run to automatically dismiss eligible FYI tasks or withdraw all other eligible tasks.

  • FYI Tasks: The process runs every three days, starting the first day of each month. For example, it runs on May 1, 4, 7, and so on, and again on June 1 and every three days after. So, if you leave the FYI Notifications Expiration Period profile value at 7, then depending on when the process runs, an FYI task can be automatically dismissed within seven to ten days after it's created. The process changes the FYI task status from Assigned to Completed.

  • All Other Tasks: The process runs every three days, starting the second day of each month. For example, it runs on May 2, 5, 8, and so on, and again on June 2 and every three days after. The process changes the status of eligible tasks to Withdrawn.

Archiving and Purging Workflow Tasks: Explained

Workflow tasks with a final status, such as Completed and Expired, can be archived and purged. Archiving keeps a copy of the task data for audit, data retention or analysis, and other purposes. Purging removes the completed tasks from users' worklists and permanently deletes the original data.

Archive

Tasks are automatically archived without you doing any setup. You can also run the Archive Workflow Tasks scheduled process as needed; for example, you need the latest data archived immediately for reporting purposes. The process includes all eligible tasks that aren't yet archived.

Archived data includes task details, approval history, comments, and attachments. How you view or use the archived data depends on the products you're using. For example, the data might be displayed in a table on a page, or available through a business intelligence subject area that you can select to create an analysis.

Purge

Tasks are automatically purged after archive, without you doing any setup.

Setting Up the Worklist Region on My Dashboard: Points to Consider

Worklist: Notifications and Approvals is one of the predefined regions users can add to My Dashboard (Navigator > My Dashboard), which is blank by default. This region contains workflow tasks. To set up this Worklist region, select a value for the Welcome Dashboard Worklist Timeout Interval (ATK_HOME_PAGE_WORKLIST_TIMEOUT) profile option. In the Setup and Maintenance work area, use the Manage Application Toolkit Administrator Profile Values or Manage Administrator Profile Values task to set this profile option.

Profile Value Considerations

When users open My Dashboard and it contains the Worklist: Notifications and Approvals region, data for the region is retrieved. The profile option determines how long to continue retrieving before timing out and displaying no data.

  • If you don't set a value for this profile option, which is blank by default, then the region doesn't time out.

  • Retrieving data for the Worklist region affects the performance of My Dashboard as a whole. So, select a value for this profile option if your users have the Worklist region on My Dashboard and notice performance issues.

After the timeout, users can refresh the region to try retrieving the data again.

Electronic Signature

Configuring Electronic Signature for Purchasing Documents: Procedure

Before your organization can use electronic signature functionality for purchasing documents, you must enable the feature and perform some setup. Once the setup is complete, authorized users in your organization can use the electronic signature functionality with purchase agreements, purchase orders and change orders.

To set up electronic signature for purchasing documents, you must complete following tasks:

  • Obtain a license from and register with the supported third-party electronic signature service provider.

  • Enable the feature in the Procurement offering.

  • Set up the Manage Electronic Signature page.

Registering with a Service Provider

Your organization must first obtain a license directly from DocuSign, the supported third-party electronic signature service provider. After the license is obtained, you must set up an account for your organization on the DocuSign web site. You must add individual users in your organization as members to the account. These are users, such as buyers, who require the ability to send purchasing documents for electronic signature.

Enabling the Feature

Sign in to Oracle Applications Cloud as Procurement Application Administrator, and follow these steps to enable the electronic signature for purchasing documents feature:

  1. In the Setup and Maintenance work area, select the Procurement offering.

  2. On the Setup: Procurement page, click the Procurement Contracts functional area, then click the Actions drop-down list and select the View Feature Selection option.

  3. On the Edit Features: Procurement Contracts page, select the Enable Electronic Signature for Procurement Documents check box.

  4. Click Done.

Note: When you enable the feature, the Require Signature option is available to users on the create order, agreement and change order pages.

Setting up the Manage Electronic Signature Page

While signed in as Procurement Application Administrator, follow these steps to set up electronic signature for purchasing documents:

  1. In the Setup and Maintenance work area, select the Procurement offering.

  2. On the Setup: Procurement page, click the Procurement Contracts functional area, and then click the Configure Electronic Signature for Procurement Documents task.

  3. On the Manage Electronic Signature page, enter the administrative account information for your organization, from the setup on the DocuSign web site.

  4. Click Validate.

  5. Click Save.

Note: If you have already set up this page for the Contracts offering, you don't have to set it up again for the Procurement offering.