9Define Approval Management for Procurement

This chapter contains the following:

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 transactions 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 at the offering level so that relevant setup tasks are available.

  • In the Setup and Maintenance work area, use the following setup tasks in the Application Extensions or another 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.

Assignments and Routing

Prevent Assigning Approvals to Specific Users

In rare cases, just based on how approval rules are set up, workflow tasks get routed to the person who created the task. Or, to someone else who should not be approving due to a conflict of interest. To make sure that such things don't happen, you can configure tasks so that they skip certain users in the approval chain. Those users can still get FYI notifications about the tasks, but not notifications they can act on.

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Click the Configuration subtab.

  5. In the Prohibit User Self-Approval section, select the Prohibit self-approval by users named in these payload attributes check box.

  6. In the Payload Attributes subsection, add one or more attributes:

    1. Click the Add icon.

    2. Click the Expression Builder icon.

    3. In the Expression Builder, expand Variables > Task > task:task.

    4. Select an attribute that represents the users to skip, for example task:creator for the task creator. Or, open the task:payload node and select an attribute from there instead.

      Note: Make sure you select an attribute that gives you user IDs at runtime, the IDs that users enter to sign in to the application.
    5. Click Insert into Expression and then OK.

  7. Select the Reassign approvals to those users' managers check box if you want to reroute tasks to the manager of the skipped user. Otherwise, the task goes to the next assignee in the approval chain.

  8. In the Tasks to be configured toolbar, click the Commit task icon when you're ready to roll out your changes.

You can also do this setup for specific participants in the task, if it's not an FYI task. In the Assignees subtab, select the participant, click Advanced, and find the same Prohibit User Self-Approval section.

  • If you have settings at both the participant and task level, both would apply.

  • If there's any conflict, for example with the setting of the Reassign approvals to those users' managers check box, the participant level setting takes precedence.

How You Can Regularly Reassign Pending Approvals for Workers That Become Inactive

A manager assignment can become inactive due to the end of an assignment or work term, termination, or global transfer. If the manager has any pending approval notifications, you must reassign them.

Run this process: Run Reassign Pending Approvals for Terminations and Correct Invalid Supervisor Assignments Process in the Scheduled Processes work area. You can set a schedule to run it at least once a day. You can run it more frequently if you want things updated faster.

Here's what the process does:

  • It reassigns the direct reports of a terminated manager to that person's line manager and also assigns any pending notifications to the line manager. Only actionable notifications will be reassigned.

  • It reassigns pending approval notifications based on the number of days you specify using the Past Period in Days Considered for Reassigning Pending Approvals parameter.

Workflow Email Notification Setup

Define the Due Date and Expiration Policies for Workflow Tasks

For workflow tasks that should be completed within a general time frame, you can set a due date, expiration policies, or both. The current assignee will get notified before the due date to take action. Even after the due date passes, the task doesn't expire and the assignee, as well as any subsequent approvers, can still act on it. But if you set expiration policies, the task can expire based on your settings. Expired tasks are in a final state and no one can make any more updates to them. To set due dates and expiration policies, use the Manage Task Configurations or other approval setup task in the Setup and Maintenance work area.

Overall Process

To set the due date, expiration policies, or both:

  1. In the Setup and Maintenance work area, go to the following:

    • Functional Area: Application Extensions or another functional area

    • Task: Manage Task Configurations or another approval setup task

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task to configure and click the Edit task icon in the Tasks to be configured toolbar.

  3. Open the Deadlines subtab and make your changes.

  4. Click the Commit task icon in the Tasks to be configured toolbar when you're ready to deploy your changes.

This figure shows the Deadlines subtab.

Deadlines subtab where you set due date and expiration
policies

Specify a Due Date

On the Deadlines subtab, specify the time frame that all approvers should complete the task in. For example, if you enter 14 days for the Due Date fields, that means the task is due 14 days after it's created.

Indicate How Tasks Expire

Follow these steps:

  1. On the Deadlines subtab, expand the Expiration Settings section.

  2. Indicate how the task would expire, based on what's not done during a specified time frame.

    • Task Level: If all approvals aren't done.

    • Assignee Level: If the assignee doesn't act on the task.

Define Policies with Assignee Level Expiration

To set expiration policies, including any escalations or renewals, with Assignee Level selected:

  1. In the Expiration Settings section of the Deadlines subtab, specify a duration and optionally select the Exclude Saturday and Sunday check box. For example, if you enter 30 days and select the check box, then:

    • For sequential routing, the task expires if the last assignee doesn't act on the task within 30 weekdays after the task is routed to that assignee. If the first assignee doesn't act in 30 weekdays, the task is passed to the next assignee, who gets another 30 weekdays. And so on, until the last assignee.

    • For parallel routing, the task expires if the current assignees don't act on the task within 30 weekdays after the task is assigned.

  2. If you want tasks to get escalated or renewed after they expire, select the Escalate or Renew option. Otherwise, leave the Expire only option selected.

  3. To escalate, indicate how many times the approval escalates up the management chain. For example, you enter 2 in the Maximum Escalation Levels field. When the task expires:

    • For sequential routing, the task is routed to the manager (User 2) of the last assignee (User 1).

    • For parallel routing, the task is routed to the managers (User 2) of all current assignees (User 1).

    When User 2 doesn't act within 30 weekdays, then the task is escalated to the manager of User 2, who has another 30 weekdays before the task goes into a final Expired status.

  4. To renew, indicate how many times the task can get renewed. For example, you enter 2 in the Maximum Renewals field. When the task expires:

    • For sequential routing, the last assignee gets another 30 weekdays.

    • For parallel routing, the current assignees get another 30 weekdays.

Define Policies for Task Level Expiration

To set expiration policies, including any escalations or renewals, with Task Level selected:

  1. In the Expiration Settings section of the Deadlines subtab, specify a duration and optionally select the Exclude Saturday and Sunday check box. For example, if you enter 30 days and select the check box, then the task expires if not all approvals are done 30 weekdays after the task is routed to the first assignee. If there are three assignees and the first two take 25 weekdays to act, then the last assignee only gets 5 weekdays.

  2. If you want tasks to get escalated or renewed after they expire, select the Escalate or Renew option. Otherwise, leave the Expire only option selected.

  3. To escalate, indicate how many times the approval escalates up the management chain.

    For example, you enter 2 in the Maximum Escalation Levels field and select Director in the Highest Approver Title field. When the task expires, it's routed to the manager (User 2) of the current assignee (User 1). When User 2 doesn't act within 30 weekdays, then:

    • If User 2 isn't a director, the task is escalated to the manager of User 2, who has another 30 weekdays before the task goes into a final Expired status.

    • If User 2 is a director, then the task goes into a final Expired status.

  4. To renew, indicate how many times the task can get renewed. For example, you enter 2 in the Maximum Renewals field. When the task expires, all pending assignees get another collective 30 weekdays to act. If they don't all act within that period, then the task is renewed for another 30 weekdays. If the task still isn't complete in that time, then it goes into a final Expired status.

Disable or Enable Workflow Notifications

When workflow tasks are assigned to users, they get notifications through email and the Notifications icon in the global header. 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 or other approval setup 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 workflow notifications:

  • The setting applies only to email notifications that are sent as part of workflow tasks, not to all emails in general.

  • 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 Application Preferences page that's on the Administration tab, select a value from the Notification Mode list:

    • All: Email notifications are enabled. Workflow notifications are included in the global header. This is the default value.

    • None: Email notifications and workflow notifications in the global header are disabled.

    • Email: Only email notifications are enabled. New workflow notifications won't appear in the global header.

    • In-app: Workflow notifications in the global header are enabled. Email notifications are no longer sent.

    Note: If you or another administrator has selected news feed as the default home page layout, then users also get notifications in the Things to Finish section on the home page, as well as the Notifications page. The same mode setting that applies to the notifications in the global header also applies to the Things to Finish section and the Notifications page.
  5. Click Save.

Synchronize Notifications in the Global Header with Workflow Tasks

When workflow tasks are 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 through email, the Worklist: Notifications and Approvals work area, or BPM Worklist. 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.

Note: If you or another administrator has selected news feed as the default home page layout, then users also get notifications in the Things to Finish section on the home page, as well as the Notifications page. The scheduled process also applies to notifications in these UIs. For example, the Things to Finish section automatically reflects changes made in the global header, but not changes made through email until the scheduled process runs.

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.

    If the news feed home page layout is selected, then after synchronization, the notification:

    • Is removed from the list in the global header

    • Is no longer a card in the Things to Finish section

    • Moves from the Assigned to Me tab on the Notifications page to the All tab

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

More Setup for Workflow Email Notifications

You can click the Expand More icon on the Notifications subtab to open the More section and see other setup options for email notifications. In general, leave the default settings in this section for every workflow task. Settings in this section include the following check boxes, which, if selected, would:

  • Make notification secure (exclude details): Exclude business transaction details in email notifications.

  • Hide End User Web URL in notifications: Remove the default first line in the email body: Access this task in the Workspace Application or take direct action using the links in this email. This line includes a link that opens BPM Worklist. It is recommended to select this check box.

  • Make notification actionable: Include links in email notifications that users can click to directly take action, for example to approve or reject.

  • Send task attachments with email notifications: Include files attached to the task as attachments in the email notifications.

Define When to Send Workflow Notifications

When notifications are enabled, each workflow task is set up by default to send notifications as part of the approval process. For example, to notify assignees whenever they're assigned a task. For any workflow task, you can change the predefined setup to determine when notifications are sent, and to whom. This setup applies to email or in-app notifications, or both, depending on what's enabled.

Set Up Notification Scenarios

To define the scenarios for sending notifications:

  1. Navigate to the Notifications subtab in BPM Worklist for the task you want to edit.

  2. Click the Add Notification icon to enable additional notification scenarios, or edit existing rows directly.

    1. In the Task Status column, select when to send the notification, for example when the task has expired. Aside from the actions or statuses available to end users, you can also select any of the following:

      • Alerted: Usually, an error condition that can be fixed. The task is assigned to the error assignee, or someone else if the task doesn't have error assignees.

      • Update: Whenever the task is updated, for example by adding a comment or attachment, without affecting the approval status or routing.

      • Update Outcome: Whenever the outcome of the task is updated, for example approved or rejected.

      • All other actions: Any action that's not already in the list of values.

    2. In the Recipient column, select whom to notify.

      • Assignees: The users or groups whom the task is currently assigned to.

      • Initiator: The user who created the task.

      • Approvers: The users who already approved the task as part of a sequential approval chain.

      • Owner: The task owner, who's responsible for the business process that the task is related to.

      • Reviewer: The user who can only add comments and attachments to a task.

  3. To disable specific notification scenarios, select a row and click the Delete Notification icon.

  4. Click the Save icon in the Tasks to be configured toolbar.

The following figure shows the table on the Notifications subtab with predefined scenarios for a workflow task. In this example, notifications are sent to assignees whenever the task is assigned to them. The task initiator also gets a notification when the task is complete, and administrators are notified if the task results in error.

Table on Notifications subtab to define when and
to whom notifications are sent for the workflow task

Set Up Reminders

To send reminders in addition to the defined notification scenarios:

  1. Select the Enable Reminder check box.

  2. From the Repeat list, select the number of reminders to send, for example 2.

  3. From the Initiating Action list, specify if the reminder is sent based on when the task is assigned to a user or when the task expires.

  4. Define a frequency for the time between reminders, for example 3 days.

  5. Click the Save icon in the Tasks to be configured toolbar.

The following figure shows the reminder setup with the given sample settings, along with After Assignment selected as the initiating action. For this example, a reminder is sent three days after the user is assigned the task. One more reminder is sent three days after that, if the user still hasn't acted on the assigned task.

Section on Notifications subtab to set up reminders
for workflow tasks

Add Header Content to Workflow Email Notifications

Each workflow task is configured with scenarios for sending email notifications as part of the approval process. For each notification scenario in the Notifications subtab, the Notification Header column determines what's in the email header, a region that appears before the email body.

  • By default, all predefined notification scenarios have emails with blank headers.

  • Any notification scenarios you add in the Notifications subtab would have the following header value: concat(string('Task '), /task:task/task:title, string(' requires your attention.')). It is recommended to change that value to null.

For some workflow tasks, you can enable configurable email notifications based on report layouts to be used instead of the standard email notifications. The Notification Header setting doesn't apply to those configurable email notifications.

Adding Company Name or Logo

If you do want to add, for example, your company name or logo to the email header:

  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Open the Notifications subtab.

  5. For the specific notification scenario on the Notifications subtab, click the icon in the Notification Header column.

  6. In the Edit Notification Message dialog box, delete any existing content and enter the following in the Notification Message field.

    • For company name: Enter text in single quotes, for example 'Oracle'. You can also use HTML formatting, for example '<h2>Oracle</h2>'.

    • For company logo: Enter the URL to your logo, following this syntax: '<img src="https://cloud.oracle.com/res/images/header/oracle-cloud-logo.png" width="230" height="69" alt="Oracle Logo">'. Replace the URL and alternative text with your own.

  7. Click the Save icon in the Tasks to be configured toolbar.

Set Up the From Field in Workflow Email Notifications

By default, the From field in workflow email notifications shows an email address without a sender name. You can't change the email address, but you can specify the sender name. For example, if you indicate that Your Company is the text to display, then the From field shows: Your Company <<your pod>.fa.sender@workflow.mail.<your data center>.cloud.oracle.com>.

You can set up the sender name in application preferences for all workflow tasks, or have different setup for specific workflow tasks. If not specified at the task level, the sender name setting defaults from the preferences.

Setting Up for All Workflow Tasks

To define the sender name for all workflow tasks that have no other applicable setup:

Notification section on the Application Preferences
page on the Administration tab, with options to define the email sender
name for all workflow tasks
  1. Open the Administration tab. If you're not in BPM Worklist:

    1. Click the Notifications icon in the global header.

    2. Click More Details.

    3. Click your user name and select Administration.

  2. On the Application Preferences page that's on the Administration tab, select one of the Email "From:" Display Name options.

    • Select to specify the text to display. Enter your value or leave blank if you want nothing to appear in the From field.

    • Select Submitter to show the person who created the task.

    • Select Previous Approver to show the previous assignee in the approval chain. When the notification is sent to the first assignee in the approval chain, the From field shows the person who created the task.

  3. Click Save.

Setting Up for a Specific Workflow Task

To specify the sender name for a specific workflow task:

More section on the Notifications subtab on the
Task Configuration tab, with options to define the email sender name
for a workflow task
  1. In the Setup and Maintenance work area, go to the Manage Task Configurations task or another approval setup task in the Application Extensions functional area or another functional area.

  2. In BPM Worklist, on the Task Configuration tab, select the workflow task.

  3. Click the Edit task icon in the Tasks to be configured toolbar.

  4. Open the Notifications subtab.

  5. On the Notifications subtab, click the Expand More icon.

  6. Select one of the Email "From:" Display Name options.

    • Select Not Applicable so that what appears in the From field depends on the application preferences that apply to all workflow tasks.

    • Select to specify the text to display. Enter your value in quotes, for example "Oracle", or leave blank if you want nothing to appear in the From field.

    • Select Previous Approver to show the previous assignee in the approval chain. When the notification is sent to the first assignee in the approval chain, the From field shows the person who created the task.

  7. Click the Save icon in the Tasks to be configured toolbar.

Send Test Workflow Email Notifications to One Address

While you're testing workflow setup, you can send all email notifications to a single address so that your users don't receive any test emails. The test emails are still sent based on the notification scenarios defined for the particular workflow task.

Specifying the Email Address

To enter the email address to send test emails to:

  1. Click the Notifications icon in the global header.

  2. Click More Details.

  3. Click your user name and select Administration.

  4. On the Application Preferences page that's on the Administration tab, click the Test Notification Email Address icon.

  5. In the dialog box, enter an email address in the Test Notification Email Address field.

  6. Click OK and then Save.

After you're done testing, go back and delete the email address that you entered.

Configurable Email Notifications

Configure Procurement Workflow Notifications

As part of certain business flows with workflow tasks, the application automatically sends email or in-application notifications to your users, or to people your users do business with. For example, when a user submits a requisition, the approvers receive an email with the approval request. For some flows, configurable Oracle Business Intelligence (BI) Publisher reports determine the email and in-application notification content and format. For some workflow tasks, you can enable these configurable notifications to be used instead of the standard notifications.

Procurement business flows with configurable notifications include the following workflow tasks:

  • Negotiation invitation

  • Purchase order approval

  • Purchase order change order approval

  • Requisition approval

  • Requisition reapproval (change to lines by requester, change to lines by buyer)

  • Seller negotiation award decision

  • Seller negotiation bid disqualification

  • Seller negotiation change schedule

  • Seller negotiation invitation

  • External Supplier Registration Approval Decision

In addition to getting notifications in email, users can also view in-application notifications by:

  • Clicking the Notifications icon in the global header and opening a notification.

  • Going to the Worklist: Notifications and Approvals work area and opening a notification.

  • Clicking the In-App Notification link at the end of an email notification.

Process Overview

The process to generate configurable email and in-application notifications is the same as generating other types of report output. The process involves various types of objects in the business intelligence catalog, including data models, subtemplates, style templates, and reports.

This figure shows how these objects work together to generate the output used for email and in-application notifications.

BI Publisher objects, including data model, subtemplate,
style template, layout template, and report, working together to generate
HTML output for workflow notifications.
  • Data Source: Stores the attributes and attribute values for business objects and transactions in the application

  • Data Model: Determines which attributes from data sources are available to be included in the notification and how that data is retrieved

  • Subtemplate: Provides common components, for example a branding logo and buttons, that can be reused in multiple reports

  • Style Template: Provides styles, such as the type of lines and fonts to use in tables, or the font type, size, and color to use for headings

  • Report: Contains a layout template that determines:

    • Which attributes appear in the notification, from the data model used for the report

    • What the notification looks like, using components from the subtemplate and styles from the style template used for the report

  • HTML: Is the output generated from the report

  • Email Notification: Is sent to users as part of a business flow, with the HTML output embedded in the email body

  • In-Application Notification: Has the HTML output embedded in the application user interface

Each workflow task with configurable notifications has a corresponding predefined report in the BI catalog. For example, the Requisition Approval Email Report contains the Requisition Approval Email Layout and uses the Requisition Approval Email Data Model. The generated output is included in emails that are sent to users for requisition approval.

Notification Modifications

After you enable configurable workflow notifications, the predefined reports and related objects in the BI catalog work by default. The report-based notifications provide the same information as the standard notifications, but in a format optimized for mobile devices. To modify the notifications, you can edit copies of the predefined reports, data models, and subtemplate (but not the style template). You proceed as you would to edit any report, data model, or subtemplate in the catalog, for example:

  1. Find a predefined report for procurement in the BI catalog.

  2. Use the Customize option to create a copy, or copy the report and paste it within the Custom folder.

  3. Edit the copied report layout template.

Note: The configurable, report-based notifications are delivered in a format optimized for mobile devices. If your organization has approvers using mobile devices, minimize making modifications that increase the number of columns in tables, and test all such modifications thoroughly on applicable mobile devices before deploying the changes.

For more information about creating and editing reports, see the Oracle Procurement Cloud Creating and Administering Analytics and Reports guide, available on the Oracle Help Center. You should get familiar with BI Publisher in general before modifying configurable notifications. Aspects specific to configurable notifications include:

  • You use only the Template Builder for Word add-in to edit the .rtf template in Microsoft Word, not the layout editor or other tools available for creating and editing report layout.

  • You usually edit a copy of predefined layout templates, rather than create reports or layout templates.

Security

To modify reports and data models for workflow notifications, you must have the BI Administrator role.

Setup

Use the Offerings work area, Procurement offering to enable each of the applicable configurable notifications features that meet the needs of your organization. Features include:

  • Configure Purchasing Document Notifications with Business Intelligence Publisher feature, found in the Purchasing functional area

  • Configure Purchase Requisition Notifications with Business Intelligence Publisher feature, found in the Self Service Procurement functional area

  • Configure Negotiation Invitation Notification with Business Intelligence Publisher, found in the Sourcing functional area

Also. download and install the Template Builder for Word add-in.

Reports and Data Models Used for Procurement Notifications Based on Reports

You can configure Oracle Business Intelligence (BI) Publisher reports to send email and in-application notifications for some Oracle Procurement Cloud workflow tasks. Each business process area uses different Oracle BI Publisher reports and data models for configuring the email or in-application notifications.

Reports and Associated Data Models

This table shows the Oracle BI Publisher reports and associated data models that are available for configuring both email and in-application notifications for procurement business processes. The navigation to the business process folders is: Oracle BI Publisher > Catalog > Shared Folders > Procurement folder. Under this folder you can find the following business process folders having configurable notification reports and data models.

Business Process Report Data Model

Purchasing

Purchase Order Notification Report

Purchase Order Notification Data Model

Self Service Procurement

Requisition Approval Email Report

Requisition Approval Email Data Model

Sourcing

Negotiation Invitation Email Report

Sourcing Notifications Data Model

Sourcing

Seller Negotiation Award Decision Notification Report

Seller Negotiation Award Decision Notification Data Model

Sourcing

Seller Negotiation Bid Disqualification Notification Report

Seller Negotiation Bid Disqualification Data Model

Sourcing

Seller Negotiation Change Schedule Notification Report

Seller Negotiation Change Schedule Data Model

Sourcing

Seller Negotiation Invitation Notification Report

Seller Negotiation Invitation Data Model

Sourcing

Negotiation Award Decision Notification Report

Negotiation Award Decision Notification Data Model

Suppliers

External Supplier Registration Approved FYI Email Report

External Supplier Registration Approved Email Data Model

Suppliers

External Supplier Registration Rejected FYI Email Report

External Supplier Registration Rejected Email Data Model

Suppliers

External Supplier Registration Request To Resubmit Email Report

External Supplier Registration Email Data Model

Suppliers

External Supplier Registration Save for Later Email Report

External Supplier Registration Email Data Model

For each of these listed business process areas, you can use the associated reports and data models to configure both email and in-application notifications.

Best Practices for Layouts in Workflow Notifications

Predefined workflow notifications based on report layout templates all follow a general format. When you edit a copy of these layout templates in Microsoft Word, follow the predefined layout as closely as possible for consistency. Also keep in mind shared components and mobile considerations.

General Structure

In general, the workflow notifications contain a set of components that are displayed in a certain order.

The callouts in this figure identify the email notification components listed in the following table.

Example of a workflow email notification with callouts
to identify the various components

The callouts in this figure identify the in-app notification components listed in the following table. In addition to describing each component, the table also indicates if the component appears in the email notification, in-app notification, or both.

Example of a workflow in-app notification with
callouts to identify the various components
Callout Component Notification Type

1

Buttons with the primary actions to take on the task, such as Approve and Reject. These buttons aren't part of the configurable, report-based notification content.

In-app

2

Notification header listing key attributes of the workflow task and the associated transaction.

Both

3

Buttons for the primary actions to take on the task, such as Approve and Reject.

Email

4

Notification body that usually includes transaction and line level details, displayed in tables or sets of attributes with corresponding values. The data model for the report restricts the total number of rows displayed in some of the tables. If the limit is exceeded, the table footer provides a link to the transaction details page, where users can view all the rows. To change this limit, you can edit a copy of the data model.

Both

5

Approval history, including any attachments that users in the history uploaded for the task. You can't edit the approval history component, which usually appears in the body of only email notifications. For in-app notifications, you can usually view the history by clicking the Actions button and selecting History.

Email (or both, in rare cases)

6

Buttons for the primary actions again.

Email

7

A link to the corresponding transaction page, and another link to the in-app notification.

Email

When you modify notifications, try to keep to this general structure and don't remove essential elements such as the action buttons. Likewise, don't change the styles in your layout template. The predefined style template should still apply to your notification; don't edit a copy of the style template and apply that to your notification.

To add components to your notification, for example another table, consider first downloading another style template from My Oracle Support. This template contains Quick Parts content that you can use in Word when you do more advanced work on layout templates. For example, from the Quick Parts gallery, you can select and add the table that's consistent in format with predefined tables already on your notification.

By default, the components that you add in the layout template appear in both email and in-app notifications, where available. You can add conditions to explicitly make a particular element, for example a field, appear only in one type of notification and not the other.

Shared Components

A predefined subtemplate in the business intelligence (BI) catalog applies to all predefined layout templates for workflow notifications. The subtemplate contains components that are shared among the notifications, for example:

  • Branding logo, if you add one to the subtemplate, which would appear as the first component in the email body. The logo appears in email notifications only.

  • Action buttons in email notifications.

  • Links at the end of the email notification, one to the corresponding transaction page, and another to the in-app notification.

When you make a copy of a predefined layout template to edit, the copy automatically inherits the same predefined subtemplate. To edit these shared components, make a copy of the predefined subtemplate, edit the copied version, and apply it to your own layout templates.

Mobile Considerations

Because users can view the workflow notifications on mobile devices, always consider mobile first and keep the notifications as simple as possible. For example:

  • Don't put too much content horizontally, such as too many columns in tables.

  • Keep all text, including attributes and column headings, as short as possible.

  • Center align lists of attributes and their values, if they appear outside tables.

Make sure to test your email notifications on mobile devices.

Add a Branding Logo and Change Other Shared Components in Workflow Notifications

A predefined subtemplate contains common components for all workflow notifications based on predefined report layouts. For example, the subtemplate has a place for you to add a branding logo, which would appear at the beginning of email notifications. You can modify other shared components so that the same changes apply to your notifications. For example, for email notifications, you can also change the text on action buttons, or the text of the links that appear at the end of emails.

Note:
  • You must edit a copy of the subtemplate in the Custom folder of the business intelligence (BI) catalog. Don't directly update the predefined subtemplate.

  • The exact steps can vary depending on your version of Microsoft Word.

Modifying Shared Components in the Subtemplate

To edit a copy of the predefined subtemplate that contains the shared components:

  1. Click Navigator > Reports and Analytics.

  2. Click the Browse Catalog icon.

  3. In the BI catalog (the Folders pane), expand Shared Folders > Common Content > Templates.

  4. For Workflow Notification Subtemplate, click More and select Customize.

    If you're not using the Customize option:

    1. Click Copy in the toolbar with Workflow Notification Subtemplate selected.

    2. In the BI catalog, expand Shared Folders > Custom > Common Content > Templates. Create a Templates folder in this location if it doesn't exist.

    3. Click Paste in the toolbar.

    4. Click the Edit link for the copied subtemplate.

    All reports using the predefined subtemplate are automatically redirected to point to your subtemplate in the Custom folder. This applies:

    • To all reports, predefined or not

    • No matter if you copy and paste the subtemplate or use the Customize option

    • Only if your subtemplate has the same name and relative file path within Custom as the predefined subtemplate

  5. In the Templates section, click the link in the Locale column.

  6. Save the subtemplate .rtf file to your computer.

  7. Open the .rtf file with Microsoft Word.

    • To add a logo, insert your own image in the subtemplate.

    • To change button or link text, edit the text accordingly. Make the same edits wherever that button or link text appears in the subtemplate.

      Caution: To ensure that your layout templates reflect these changes without additional rework, don't edit any other text in the subtemplate .rtf file.
  8. Update Word options to ensure that existing links remain intact in the subtemplate.

    1. Click File > Options > Advanced.

    2. In the Word Options dialog box, click Web Options in the General section.

    3. In the Web Options dialog box, open the Files tab.

    4. Deselect the Update links on save check box.

  9. Save your changes in Word.

Uploading the Modified Subtemplate

To upload your subtemplate to the BI catalog:

  1. In the BI catalog, expand Shared Folders > Custom > Common Content > Templates.

  2. Click Edit for Workflow Notification Subtemplate.

  3. In the Templates section, click the Upload icon.

  4. Select your modified .rtf subtemplate and a locale, and click OK to overwrite the original subtemplate.

Use Quick Parts for Workflow Notifications

Use the Quick Parts feature in Microsoft Word to easily insert reusable pieces of formatted content. When you edit copies of predefined report layout templates for workflow notifications in Word, you can add predefined Quick Parts content to your .rtf file. For example, you can insert a table in a format that's consistent with predefined notifications. The predefined Quick Parts content is available in a style template .dotx file on My Oracle Support.

Note: The exact steps can vary depending on your version of Microsoft Word.

Prerequisites

To get the predefined Quick Parts content into your Quick Parts gallery:

  1. Open Configurable Workflow Notifications: Implementation Considerations (2215570.1) on My Oracle Support at https://support.oracle.com.

  2. Download the .dotx file and save it to your Microsoft Word template folder, for example C:\Users\<user name>\AppData\Roaming\Microsoft\Templates.

Also, to preview your layout template changes before uploading the .rtf file back to the business intelligence (BI) catalog:

  • Generate sample report data from the data model for the report that you're editing.

  • Download a local copy of the subtemplate that applies to the layout template.

Adding Quick Parts Content to Workflow Notifications

To insert content from the Quick Parts gallery into a layout template:

  1. In the BI catalog, find the predefined report with the layout template that you want to modify.

  2. For the report, click More and select Customize.

    If you're not using the Customize option:

    1. Copy the predefined report and paste it in an appropriate subfolder within the Custom folder.

    2. Click the Edit link for the copied report.

  3. Click Edit for the layout template to insert Quick Parts content into, and save the .rtf file to your computer with a new file name.

  4. Open the .rtf file with Microsoft Word.

  5. Put your cursor where you want to insert new content.

  6. From the Insert tab on the ribbon, click Quick Parts within the Text group, and select the component to insert.

  7. Edit the inserted component as needed and add any other components.

  8. Save your changes in Word.

Previewing the Layout Template Changes

To preview your edits before uploading your layout template to the BI catalog:

  1. On the ribbon, open the BI Publisher tab and click Sample XML within the Load Data group to import sample data from the data model. Skip this step if you already loaded sample data.

  2. At the beginning of the document, replace the path with the location of the downloaded subtemplate file on your computer. For example, change <?import:xdoxsl:///Common Content/Templates/Workflow Notification Subtemplate.xsb?> to <?import:file:///C:/Template_Directory/FinFunWorkflowNotificationSub.rtf?>.

  3. From the BI Publisher tab on the ribbon, click HTML in the Preview group.

  4. If the preview reflects your changes as expected, then change the path back to the original location.

  5. Save your changes in Word.

Uploading the Modified Layout Template

To upload your layout template to the BI catalog after previewing the changes:

  1. Back in the BI catalog, click Edit for the report within the Custom folder, if that page isn't still open.

  2. Click the View a list link.

  3. Click the Create icon on the table toolbar.

  4. In the Upload or Generate Layout section, click Upload.

  5. Upload your edited .rtf file with a unique layout name.

  6. Back on the page for editing the report, click Delete for the layout template that you downloaded earlier.

  7. Click the Save Report icon.

Preview Changes to Layout Templates for Workflow Notifications

To modify workflow notifications, you edit a local copy of the .rtf report layout templates in Microsoft Word. Before uploading the .rtf files to the business intelligence (BI) catalog, you should preview the output with the changes you made. You can avoid uploading a broken report that displays an error in the notifications sent to users.

Note: The exact steps can vary depending on your version of Microsoft Word.

Prerequisites

  • Generate sample report data from the data model used for the report, and save the .xml file to your computer.

  • Download a local copy of the subtemplate that applies to your own report layout template:

    1. In the BI catalog, expand Shared Folders > Custom > Common Content > Templates if you're using a modified subtemplate, or Shared Folders > Common Content > Templates for the predefined subtemplate.

    2. Click Edit for Workflow Notification Subtemplate.

    3. In the Templates section, click the link in the Locale column.

    4. Save the subtemplate .rtf file to your computer.

Previewing Output

To generate sample output from a local layout template:

  1. Open your .rtf report layout template in Microsoft Word and make your edits.

  2. On the ribbon, open the BI Publisher tab and click Sample XML within the Load Data group.

  3. Select the .xml file you downloaded to import sample data from the data model.

  4. At the beginning of your .rtf document, replace the path with the location of the downloaded subtemplate file on your computer. For example, change <?import:xdoxsl:///Common Content/Templates/Workflow Notification Subtemplate.xsb?> to <?import:file:///C:/Template_Directory/FinFunWorkflowNotificationSub.rtf?>.

  5. From the BI Publisher tab on the ribbon, click HTML in the Preview group.

  6. If the preview reflects your changes as expected, then change the path back to the original location.

  7. From the BI Publisher tab on the ribbon, click Validate Template in the Tools group.

  8. Also in the Tools group, click Check Accessibility.

  9. Save your changes in Word.

Set Up Content to Appear in Only Email or In-App Workflow Notifications

For workflow tasks that have configurable email and in-app notifications, the same .rtf report layout template is used for both types of notifications. When you edit a copy of predefined templates in Microsoft Word to modify the notifications, you can make content conditional. For example, you can add an attribute from the data models used for the report, and set the attribute to appear only in in-app notifications.

The logo, action buttons, and links at the end of email notifications are predefined to appear only in emails, based on the subtemplate. The approval history is usually predefined to also appear in the body of only email notifications. Any conditional setting you apply to these components in the .rtf template won't override the predefined setup.

Prerequisites

Generate sample report data from the data model used for the report, and save the .xml file to your computer.

Defining Conditional Regions

To define a conditional region of content that appears only in email or in-app notifications:

  1. Open your .rtf report layout template in Microsoft Word.

  2. On the ribbon, open the BI Publisher tab and click Sample XML within the Load Data group.

  3. Select the .xml file you downloaded to import sample data from the data model.

  4. In your .rtf document, select the content you want to make conditional.

  5. On the ribbon, click Conditional Region within the Insert group.

  6. In the Conditional Region dialog box, on the Properties tab, select BINDISONLINENOTIF from the Data field list in the General section. The values in this list come from the sample data you imported from the data model.

  7. Select Date/Text from the next list.

  8. In the Condition 1 section, select Equal to from the Data field list.

  9. In the corresponding text field, enter true for content to appear only in in-app notifications, or false for content to appear only in emails.

  10. Make sure that form fields containing the conditional logic are inserted around your selected content. The beginning form field, C, should be immediately before the conditional content, and the closing form field, EC, should be immediately after. Move the form fields as needed.

    Tip: To make sure you're looking at the correct form fields, double-click the C form field to open the Conditional Region dialog box and see the BINDISONLINENOTIF setting.
  11. Save your changes in Word.

Entering Conditional Code

If the data model for your report doesn't have the BINDISONLINENOTIF attribute, then:

  1. In your .rtf report layout template, put your cursor immediately before the content you want to make conditional.

  2. Enter the following code, which functions the same as the C form field:

    • <?if:BINDISONLINENOTIF='true'?> for in-app only

    • <?if:BINDISONLINENOTIF='false'?> for email only

  3. Put your cursor immediately after your conditional content.

  4. Enter <?end if?>, which functions the same as the EC form field.

  5. Save your changes in Word.

Configure Purchase Order Email Approval Notifications Using Reports

This example shows how to configure workflow email notifications for the purchase order approval business process using an Oracle Business Intelligence (BI) Publisher report. You use Microsoft Word to edit the RTF template used for notifications. You can modify the BI Publisher template only if you have the BI Administrator role.

In this scenario you want purchase order approvers to see the notes to suppliers.

The following table summarizes key decisions for this scenario.

Decisions to Consider This Example

Which report, data model and layout template do I update?

For updates to email notifications for purchase order approval:

  • Purchase Order Notification Report

  • Purchase Order Notification Data Model

  • Purchase Order Approval Layout

Do I want to add prompts and headers to the layout template?

No, not for this example.

Do I want to add data model attributes to the layout template?

Yes, the Note to Supplier attribute.

Which language do I use for the RTF template?

English (United States).

Summary of the Tasks

Configure a purchase order email approval notification to add an attribute by:

  1. Adding an attribute to the data model.

  2. Exporting the data model XML file.

  3. Downloading the report layout template.

  4. Adding data model attributes to the template.

  5. Uploading the modified report layout to the BI Publisher catalog.

Prerequisites

  1. Download and install the Oracle BI Publisher Desktop: http://www.oracle.com/technetwork/middleware/bi-publisher/downloads/index.html.

  2. Download and install the Template Builder for Word to use Microsoft Word to edit the layout templates. To download, install, and set up Template Builder for Word, see Creating RTF Templates by Using BI Publisher 11g Template Builder for Word: http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/bi/bip/tb4word/tbwordbip.htm.

  3. To preview the configured templates, download a local copy of the subtemplate that applies to your own report layout template:

    • Sign in to the Oracle Business Intelligence Publisher server with the BI Administrator Role to open the Oracle Business Intelligence Home page.

    • Click Catalog.

    • In the BI catalog, go to Shared Folders > Common Content > Templates for the predefined subtemplate.

    • Click More for the Workflow Notification Subtemplate.

    • Click the Download option.

    • Save the subtemplate file to your computer.

Add an Attribute to the Data Model

In this task, you add the Notes to Suppliers attribute to the data model.
  1. Sign in to the Oracle Business Intelligence Publisher server with the BI Administrator Role to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Procurement > Purchasing and select Data Models to display the data models in the right pane.

  4. Under Purchase Order Notification Data Model, click More, then click Copy.

  5. In the Folders section, expand Shared FoldersCustomProcurementPurchasing.

  6. Click the Paste Resource icon.

  7. Under Purchase Order Notification Data Model click Edit.

  8. On the PurchasingNotificationDM page, in the Data Model section, select PurchaseOrderDraftLineDataSet.

  9. On the Diagram tab, click the Edit Selected Data Set icon.

  10. On the Edit Data Set dialog, under SQL Query, after the line for the Category ID, add a line and enter: Line.NOTE_TO_VENDER AS NoteToSupplier.

  11. Click OK.

Export the Data Model XML File

In this task, you export the XML file that includes the data model attributes predefined for the notifications. Perform this task to enable previewing your modified template. This task is also required to add data model attributes to the template.
  1. Sign in to the Oracle Business Intelligence Publisher server with the BI Administrator Role to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Purchasing to display the data models in the right pane.

  4. Under Purchase Order Notification Data Model, click Edit to open the Diagram tab on the PurchasingNotificationDM page.

    Note: To ensure that all data sets include requested elements with undefined values in the output XML data, do the following:
    • In the Data Model section, select Properties.

    • In the Properties section, select Include Empty Tags for Null Elements.

    • In the Data Model section, select Data Sets.

    Note: To add data model attributes to the template, perform steps 5 and 6. Otherwise, skip to step 7.

  5. Click the Data tab.

  6. Enter values for the following key attributes for an existing purchase order. Key attributes enable you to pull in all the purchase order attributes:

    • Document Number

    • Sold-to Legal Entity

    • Change Order Number

  7. Click View to see the sample data in the report, and all the available attributes. Verify the Note to Supplier attribute is in the list.

  8. Click Export.

  9. In the Opening PurchasingNotificationDM dialog box, select Save File and click OK.

  10. Save the PurchasingNotificationDM_.xml file to a local drive.

Download the Report Layout Template

In this task, you create a copy of the report layout template in the Custom folder, and download a copy of the template to your local drive to modify it.
  1. Sign in to the Oracle Business Intelligence Publisher server with the BI Administrator role to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Procurement > Purchasing to display the templates in the right pane.

  4. Under Purchase Order Notification Report, click More, and then select Customize. A copy of the Purchase Order Notification Report is created automatically in the Custom folder.

  5. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Purchasing.

  6. Under Purchase Order Notification Report, click Edit.

  7. On the Purchase Order Notification Report page, next to Data Model, click the Select Data Model icon.

  8. On the Select Data Model dialog, expand Custom > Procurement > Purchasing.

  9. Select the Purchase Order Notification Data Model, and click Open.

  10. Under Purchase Order Approval Notification Layout, click Edit.

  11. On the Opening PurchaseOrderApprovalNotificationLayout.rtf dialog box, select Save File and click OK to save the document to your local drive. Save the template with the name UpdatedPurchaseOrderApprovalNotificationLayout.rtf to distinguish it from the original template.

Add Data Model Attributes to the Template

To modify the purchase order approval email notification, you edit a local copy of the RTF report layout template in Microsoft Word. In this task, you add the Note to Supplier data model attribute to the report template.
Note: The exact steps can vary depending on your version of Microsoft Word.
  1. On your local drive, open the UpdatedPurchaseOrderNotification.rtf template in Microsoft Word, with the Template Builder installed.

  2. Select the BI Publisher tab.

  3. In the Load Data section, click Sample XML.

  4. In the dialog box to select XML data that appears, browse to open the PurchasingNotificationDM_.xml file you saved in the Exporting the Data Model XML File task. Then click Open.

  5. In the Data loaded successfully dialog box, click OK.

  6. Scroll to the TSRHLines section of the notification.

  7. Place the cursor after the C UnitPriceEC line and press the Enter key.

  8. On the new line, enter Note to Supplier:, and place the cursor at the end of the text you entered.

  9. On the BI Publisher tab, in the Insert section, click the 123 Field button.

  10. On the Field dialog box, locate and select the NoteToSupplier attribute.

  11. Click Insert.

  12. Click Close to return to the UpdatedPurchaseOrderNotification.rtf template.

  13. Save and close the document.

  14. Before uploading the RTF files to the business intelligence (BI) catalog, you should preview the output with the changes you made. You can avoid uploading a broken report that displays an error in the emails sent to users.

  15. Proceed to the task Uploading the Modified Report Layout to the Oracle BI Publisher Catalog.

Upload the Modified Report Layout to the Oracle BI Publisher Catalog

You must perform this task to use the modified report layout for notifications.
  1. Sign in to the Oracle Business Intelligence Publisher server with the BI Administrator Role to open the Oracle Business Intelligence Home page.

  2. Click Catalog

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Purchasing.

  4. Under the Purchase Order Notification Report, click Edit.

  5. On the Purchase Order Notification Report page, on the right side of the page, click Add New Layout to open the page with the Create Layout and Upload or Generate Layout sections.

  6. In the Upload or Generate Layout section, click the Upload icon.

  7. In the Upload Template File dialog box, in the Layout Name field, enter Updated Purchase Order Notification Report.

  8. In the Template File field, browse for the modified UpdatedPurchaseOrderNotificationLayout.rtf template on your local drive, select the template, and click Open.

  9. In the Upload Template File dialog box, from the Type list, select RTF Template.

  10. From the Locale list, select English (United States).

  11. Click Upload to open the Processing dialog box and return to the Purchase Order Notification Report page.

  12. On the right side of the page, click View a list to open the Layout page.

  13. In the row for the Updated Purchase Order Notification Report, select the Default Layout check box.

  14. On the right side of the page, click the Save Report icon.

Configure Sourcing Notifications Using Reports

This example shows how to configure workflow email notifications for the Sourcing business process using Oracle Business Intelligence (BI) Publisher reports. You use Microsoft Word to edit the .rtf template used for notifications.

The following table summarizes key decisions for this scenario.

Decisions to Consider This Example

Which template do I update?

Negotiation Invitation Email Report

Do I want to add prompts and headers to the layout template?

Yes

Do I want to add data model attributes to the layout template?

BUYERCOMPANY

Which language do I use for the RTF template?

English

Summary of the Tasks

Configure the Negotiation Invitation Email Report by:

  1. Add an Attribute to the Data Model.

  2. Export the data model XML file.

  3. Download the report layout template.

  4. Edit email body information in the template.

  5. Add data model attributes to the template.

  6. Upload the modified report layout to the BI Publisher catalog.

Prerequisites

  1. Download and install the Oracle BI Publisher Desktop: http://www.oracle.com/technetwork/middleware/bi-publisher/downloads/index.html.

    The Template Builder for Microsoft is included in the BI Publisher.

  2. To preview the configured templates, download a local copy of the subtemplate that applies to your own report layout template:

    1. In BI Publisher, click Catalog.

    2. In the BI catalog, go to Shared Folders > Common Content > Templates for the predefined subtemplate.

    3. Click More for the Workflow Notification Subtemplate and then click Copy.

    4. In the Folders section, expand Shared Folders > Custom > Procurement > Sourcing.

    5. Click the Paste Resource icon.

    6. Click More for the Workflow Notification Subtemplate and then click Download.

    7. Save the subtemplate to the local drive on your computer.

Add an Attribute to the Data Model

In this task, you add attributes to a data model.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Procurement > Sourcing.

  4. For Negotiation Invitation Email Report, click More, and then click Customize.

  5. In the Negotiation Invitation Email Report, click the Sourcing Notifications Data Model.

  6. On the Diagram tab, select the header to which you want to add an attribute and then click the Edit Selected Data Set icon.

  7. Add the required attribute and click OK.

Export the Data Model XML File

In this task, you export the XML file that includes the data model attributes predefined for the notifications. Perform this task to enable previewing your modified template. This task is also required to add data model attributes to the template.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Sourcing.

  4. For Negotiation Invitation Email Report, click Edit.

  5. In the Negotiation Invitation Email Report, click the Sourcing Notifications Data Model to open the Diagram tab.

    Note: To ensure that all data sets include requested elements with null values in the output XML data, do the following:
    • In the Data Model section, select Properties.

    • In the Properties section, select Include Empty Tags for Null Elements.

    • In the Data Model section, select Data Sets.

  6. Click the Data tab.

  7. Click View to see the sample data in the report, and all the available attributes.

  8. Click Export and select Save File and then click OK.

  9. Save the SourcingNotificationsDM_.xml file to a local drive.

Download the Report Layout Template

In this task, from the Custom folder you download a copy of the template to your local drive to modify it.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Sourcing.

  4. Select Negotiation Invitation Email Report, click Edit.

  5. For Negotiation Invitation Email Body Layout, click Edit.

  6. In the NegotiationInvitationEMailBodyReport.rtf dialog box, select Save File and then click OK to save the file with the name UpdatedNegotiationInvitationEMailBodyLayout.rtf to distinguish it from the original template.

Edit Email Body Information in the Template

To modify email content, you edit a local copy of the .rtf report layout templates in Microsoft Word.
Note: The exact steps can vary depending on your version of Microsoft Word.
  1. Open the UpdatedNegotiationInvitationEMailBodyLayout.rtf template in Microsoft Word with the Template Builder installed, if not already open.

  2. Scroll to the buyer name.

  3. Place your curser at the end of the BUYER_NAME and press enter.

  4. Enter the attribute BUYERCOMPANY.

  5. Save the document.

Add Data Model Attributes to the Template

In this task, you add to the report template attributes that exist in the predefined data model.
Note: The exact steps can vary depending on your version of Microsoft Word.
  1. Open the UpdatedNegotiationInvitationEMailBodyLayout.rtf template in Microsoft Word with the Template Builder installed, if not already open.

  2. Select the BI Publisher tab.

  3. In the Load Data section, click Sample XML.

  4. In the dialog box to select XML data that appears, browse to open the SourcingNotificationsDm_.xml file you saved in the Exporting the Data Model XML File task. Then click Open.

  5. In the Data loaded successfully dialog box, click OK.

  6. Add the required data model attributes.

  7. Save and close the document.

  8. Proceed to the task Uploading the Modified Report Layout to the Oracle BI Publisher Catalog.

Upload the Modified Report Layout to the Oracle BI Publisher Catalog

You must perform this task to use the modified report layout for notifications.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Sourcing.

  4. For the Negotiation Invitation Email Report, click Edit.

  5. For Negotiation Invitation Email Body Layout, click Properties.

  6. For Templates, click the Upload icon.

  7. In the Template File field, browse for the modified UpdatedNegotiationInvitationEMailBodyLayout.rtf template on your local drive, select the template, and click Open.

  8. In the Upload Template File dialog box, from the Template Type list, select RTF Template.

  9. From the Locale list, select English.

  10. Click OK to open the Processing dialog box and return to the Negotiation Invitation Email Report Data Model page.

  11. Click Save.

  12. On the right side of the page, click View a list to open the Layout page.

  13. In the row for the UpdatedNegotiationInvitationEmailReport Template, select the Default Layout check box.

  14. On the right side of the page, click the Save Report icon.

Configure Supplier Registration Approval Decision Notifications Using Reports

In this example, you can configure workflow email notifications for the external suppliers' registration business process using Oracle Business Intelligence (BI) Publisher reports and use Microsoft Word to edit the .rtf template used for notifications.

Important decisions required for this scenario.

Decisions to Consider This Example

Which template do I update?

External Supplier Registration Approved FYI Email Report

Do I want to add prompts and headers to the layout template?

Yes

Do I want to add data model attributes to the layout template?

CORPORATE WEBSITE

Which language do I use for the RTF template?

English

Tasks Summary

Configure the External Supplier Registration Approved FYI Email Report:

  1. Add an attribute to the Data Model.

  2. Export the data model XML file.

  3. Download the report layout template.

  4. Edit email body information in the template.

  5. Add data model attributes to the template.

  6. Upload the modified report layout to the BI Publisher catalog.

Prerequisites

  1. Download and install the Oracle BI Publisher Desktop: http://www.oracle.com/technetwork/middleware/bi-publisher/downloads/index.html.

    The Template Builder for Microsoft is included in the BI Publisher.

  2. To preview the configured templates, download a local copy of the subtemplate that applies to your own report layout template:

    1. In BI Publisher, click Catalog.

    2. In the BI catalog, go to Shared Folders > Common Content > Templates for the predefined subtemplate.

    3. Click More for the Workflow Notification Subtemplate and then click Copy.

    4. In the Folders section, expand Shared Folders > Custom > Procurement > Suppliers.

    5. Click the Paste Resource icon.

    6. Click More for the Workflow Notification Subtemplate and then click Download.

    7. Save the subtemplate to the local drive on your computer.

Add an Attribute to the Data Model

In this task, you add attributes to a data model.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Procurement > Suppliers.

  4. For External Supplier Registration Approved FYI Email Report, click More, and then click Customize.

  5. In the External Supplier Registration Approved FYI Email Report, click the External Supplier Registration Approved Email Data Model.

  6. On the Diagram tab, select the header to which you want to add an attribute and then click the Edit Selected Data Set icon.

  7. Add the required attribute and click OK.

Export the Data Model XML File

In this task, you export the XML file that includes the data model attributes predefined for the notifications. Do this task to enable previewing your modified template. This task is also required to add data model attributes to the template.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Suppliers.

  4. For External Supplier Registration Approved FYIReport, click Edit.

  5. In the External Supplier Registration Approved FYI Report, click the Supplier Registration Approved Email Data Model to open the Diagram tab.

    Note: To ensure that all data sets include requested elements with null values in the output XML data, do the following:
    • In the Data Model section, select Properties.

    • In the Properties section, select Include Empty Tags for Null Elements.

    • In the Data Model section, select Data Sets.

  6. Click the Data tab.

  7. Click View to see the sample data in the report, and all the available attributes.

  8. Click Export and select Save File and then click OK.

  9. Save the SupplierExtRegApprovedFYIDM.xml file to a local drive.

Download the Report Layout Template

In this task, from the Custom folder you download a copy of the template to your local drive to modify it.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Suppliers.

  4. Select Supplier Registration Approved FYI Email Report, click Edit.

  5. For Supplier Registration Approved FYI Email Body Layout, click Edit.

  6. In the ExtSuppRegNotifApprovalFYIReport.rtf dialog box, select Save File and then click OK to save the file with the name UpdatedExtSuppRegNotifApprovalFYIReport.rtf to distinguish it from the original template.

Edit Email Body Information in the Template

To modify email content, you edit a local copy of the .rtf report layout templates in Microsoft Word.
Note: The exact steps can vary depending on your version of Microsoft Word.
  1. Open the UpdatedExtSuppRegNotifApprovalFYIReport.rtf template in Microsoft Word with the Template Builder installed, if not already open.

  2. Scroll to the buyer name.

  3. Place your curser at the end of the CORPORATE_WEBSITE and press enter.

  4. Enter the attribute CORPORATE WEBSITE.

  5. Save the document.

Add Data Model Attributes to the Template

In this task, you add to the report template attributes that exist in the predefined data model.
Note: The exact steps can vary depending on your version of Microsoft Word.
  1. Open the UpdatedExtSuppRegNotifApprovalFYIReport.rtf template in Microsoft Word with the Template Builder installed, if not already open.

  2. Select the BI Publisher tab.

  3. In the Load Data section, click Sample XML.

  4. In the dialog box to select XML data that appears, browse to open the SupplierExtRegApprovedFYIDM.xml file you saved in the Exporting the Data Model XML File task. Then click Open.

  5. In the Data loaded successfully dialog box, click OK.

  6. Add the required data model attributes.

  7. Save and close the document.

  8. Proceed to the task Uploading the Modified Report Layout to the Oracle BI Publisher Catalog.

Upload the Modified Report Layout to the Oracle BI Publisher Catalog

You must perform this task to use the modified report layout for notifications.
  1. Sign in to the Oracle Business Intelligence Publisher server to open the Oracle Business Intelligence Home page.

  2. Click Catalog.

  3. On the Catalog page, in the Folders section, expand Shared Folders > Custom > Procurement > Suppliers.

  4. For the Supplier Registration Approved FYI Email Report, click Edit.

  5. For Supplier Registration Approved FYI Email Body Layout, click Properties.

  6. For Templates, click the Upload icon.

  7. In the Template File field, browse for the modified UpdatedExtSuppRegNotifApprovalFYIReport.rtf template on your local drive, select the template, and click Open.

  8. In the Upload Template File dialog box, from the Template Type list, select RTF Template.

  9. From the Locale list, select English.

  10. Click OK to open the Processing dialog box and return to the Supplier Registration Approved Email Data Model page.

  11. Click Save.

  12. On the right side of the page, click View a list to open the Layout page.

  13. In the row for the UpdatedExtSuppRegNotifApprovalFYIReport Template, select the Default Layout check box.

  14. On the right side of the page, click the Save Report icon.

Manage Requisition and Purchasing Document Approvals

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

Action Types

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 Attribute

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 Attribute

The Job Level attribute let's you 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 Attribute

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 Attribute

Single let's you route the approval to a specific person on the document, or a specific worker.

Supervisory Hierarchy Attribute

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.

Purchasing Approval Stages

Oracle Fusion Purchasing has predefined stages for approvals for purchase orders, purchase agreements and change order approvals.

This figure shows the predefined stages: Preapproval, Terms, Post Approval, and Post Approval FYI.

Predefined approval stages for Purchasing.

The participants predefined within each stage are illustrated in the figures below. Note that the participant name conveys both the participant type and the voting regime. For example, Preapproval (Parallel) First Responder Wins has a participant type of Parallel and voting regime of First Responder Wins. This implies that all the approvers will be notified in parallel and the first responder decision will be final for that participant.

This figure shows the predefined participants for the Preapproval stage:

  • Preapproval FYI Participant

  • Preapproval Parallel Consensus Participant

  • Preapproval Parallel First Responder Wins Participant

  • Preapproval Serial Participant

Predefined participants for the Preapproval Stage

This figure shows the predefined participants for the Terms stage:

  • Terms Approval FYI Participant

  • Terms Approval Serial Participant

  • Terms Approval 2 Serial Participant

  • Terms Approval 3 Serial Participant

  • Terms Approval Parallel First Responder Wins Participant

  • Terms Approval Parallel Consensus Participant

Predefined participants for the Terms Stage

This figure shows the predefined participants for the Postapproval stage:

  • Postapproval Parallel Consensus Participant

  • Postapproval Parallel First Responder Wins Participant

  • Postapproval Serial Participant

Predefined participants for the Post Approval Stage

This figure shows the predefined participants for the Postapproval FYI stage:

  • Post Approval FYI Participant

Predefined participants for the Postapproval FYI
Stage

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).

How You Set Up Approvals

Use the Manage Requisition Approvals and Manage Purchasing Document Approvals tasks to set up approvals. They are located in the Setup and Maintenance work area, Approval Management functional area.

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, 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 can't 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's 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 can't 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's 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 isn't blank.

  • Action Type: Approval Required.

  • Route Using: Single Approver.

  • User Type: Funds override approver.

How You Set Up Approval Rules for Purchasing Documents with Outside Processing Items

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, Approval Management functional area. When editing a rule 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.

You can create rule conditions that include AND or OR operators. Additionally, conditions can be nested.

Example of Nested Condition

The following is an example nested approval policy condition. If the destination type is Expense, and the cost center is 111 or 112, then Pat Stock must approve.

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

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

How You Define Currency Based Attributes

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

How You Specify a Rule Condition to Use A Summation Data

Summation values are 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 using the Manage Procurement Category Hierarchy task, 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

Considerations for Setting Up Requisition Approval Task

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's 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 don't 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.

How You Use Overriding Approver Attribute

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 isn't available in the BPM Worklist or Approvals UI pages for configuration.

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.

Acme Corp has agreements in place for most facilities and IT services. In addition, they have set up a supervisory hierarchy for approvals based on requisition amount. Joe Smith is Acme's CEO and therefore has the designation of Top Worker in Hierarchy for the supervisory hierarchy.

This figure illustrates Acme's approval policies. Depending on the purchase amount, the requisition is autoapproved, or must go through one, two, or three levels of supervisory approval.

This figure shows Acme Corp approval policies for
various purchase amounts.

Rules in Header Hierarchy Participant:

  1. No approvals required, such as self approved, for requisitions less than or equal to 500 USD.

    • Rule setup scenario:

    CONDITION
    Approval Amount is less than or equal to 500
    AND Functional Currency Code equals USD
    ACTION
    Action Type: Automatic
    Set Outcome To: Approved

    Displayed in the Conditions table as:

    AND
    	Approval Amount is less than or equal to 500
    	Functional Currency Code equals USD
  2. One level of Supervisory hierarchy approval required for requisitions more than 500 USD and less than or equal to 1000 USD.

    • Rule setup scenario:

      CONDITION
      Approval Amount is greater than 500
      AND Approval Amount is less than or equal to 1000
      AND Functional Currency Code equals USD
      ACTIONS
      Action Type: Approval Required
      Route Using: Supervisory Hierarchy
      Approval Chain Of: Preparer
      Start With: Manager
      Number of Approval Levels: 1
      Top Worker in Hierarchy: Joe Smith

      Displayed in the Conditions table as:

      AND
      	Approval Amount greater than 500
      	Approval Amount less than or equal to 1000
      	Functional Currency Code equals USD
  3. Two levels of Supervisory hierarchy approval required for requisitions more than 1000 USD and less than or equal to 2000 USD.

    • Rule setup scenario:

      CONDITION
      Approval Amount is greater than 1000
      AND Approval Amount is less than or equal to 2000
      AND Functional Currency Code equals USD
      ACTIONS
      Action Type: Approval Required
      Route Using: Supervisory Hierarchy
      Approval Chain Of: Preparer
      Start With: Manager
      Number of Approval Levels: 2
      Top Worker in Hierarchy: Joe Smith

      Displayed in the Conditions table as:

      AND
      	Approval Amount greater than 1000
      	Approval Amount less than or equal to 2000
      	Functional Currency Code equals USD
  4. Three levels of supervisory approval required for requisitions more than 2000 USD.

    • Rule setup scenario:

      CONDITION
      Approval Amount is greater than 2000
      AND Functional Currency Code equals USD
      ACTIONS
      Action Type: Approval Required
      Route Using: Supervisory Hierarchy
      Approval Chain Of: Preparer
      Start With: Manager
      Number of Approval Levels: 3
      Top Worker in Hierarchy: Joe Smith

      Top Worker in Hierarchy: Joe Smith

      AND
      	Approval Amount is greater than 2000
      	Functional Currency Code equals USD

Scenario

Rules in Lines Preapproval Header Stage: Preapproval Header Hierarchy Participant:

  1. If the requisition is an emergency request, the preparer's manager's approval is required before other approvers are notified.

    • Rule setup scenario:

      IF
      Emergency Requisition equals Yes
      THEN
      Action Type = Approval Required
      Route Using = Supervisory Hierarchy
      Approval Chain Of = Requester
      Start With = Manager
      Number of Approval Levels = 1
      Top Worker in Hierarchy = Joe Smith

Considerations for Setting Up Self Service Procurement Task Driven Configuration

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 participants remaining in the approval list who weren't assigned the approval task. Note that participants can't remove approver participants pre-defined in Approval Groups or generated by the application.

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 doesn't include approvals based on approval groups. Enabling auto claim won't 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

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 lets you 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 doesn't 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

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.

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, in the Setup and Maintenance work area, go to the following:

  • Offering: Procurement

  • Functional Area: Approval Management

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

Use the Task: Manage Internal Supplier Registration Approvals 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.

Disabled Rules or Participants will not be evaluated. For example, if the participant is already disabled, then no rules within that participant will be evaluated. The same applies for disabled rules.

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.

To configure the supplier registration and self service supplier profile change request approval requirements, in the Setup and Maintenance work area, go to Offering: Procurement, Functional Area: Suppliers, and Task: Configure Supplier Registration and Profile Change Request.

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: Internal users can register and add a supplier as part of negotiation creation.

  • Internal Supplier Request: Internal Supplier Request can be raised by registering from the Suppliers work area or by requesting a new supplier from the Self Service Procurement work area.

  • 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.

Require Supplier Identifier

For Self Service Procurement, there is an option to enforce requesters to provide at least one of these attribute values: D-U-N-S Number, Taxpayer ID, or Tax Registration Number.

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. The encryption key is regenerated for the registration URLs used for spend authorization, saved for later, and returned for resubmission. However, if you regenerate the encryption key, the registration request URL for spend authorization business relationship available through the setup page Configure Procurement Business Function changes and therefore old and saved URLs will not work. Also, registrations that were saved for later or returned for resubmission will no longer be accessible to potential 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 the following sources:

  • Suppliers

  • Supplier Qualification

  • Supplier Negotiation

Supplier profiles can also be changed by internal users. Updates to bank account changes by internal users are submitted to an approval process. See Configuring Internal Supplier Bank Account Change Approvals: Explained.

The Configure Supplier Registration and Profile Change Requests task does not configure supplier profile changes made by internal users.

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

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.

You create different approval task for each approval need, based on the business it serves. For example, you might create approval tasks for purchase requisitions approvals; expense reports approvals, and so on.

In the Setup and Maintenance work area, use the following tasks to set up approvals for procurement document objects:

  • Manage Requisition Approvals, found in the Approval Management and Self Service Procurement functional areas

  • Managing Purchasing Document Approvals, found in the Approval Management functional area

    • Use the Managing Purchasing Document Approvals task to create approval rules 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

Use stages 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 can't 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.

Manage Internal Supplier Profile Change Request Approvals

Setting Up Internal Supplier Profile Change Request Approvals Task: Critical Choices

Enable the Approve Internal Changes on Supplier Bank Accounts feature to require changes made to supplier bank accounts by internal users to be reviewed and approved. Configure approval rules for these changes appropriate to your buying organization's polices. These user-defined rules determine the approvers responsible for reviewing and approving changes to bank accounts.

Configure Internal Supplier Change Request Approval Rules

In the Setup and Maintenance work area, use the Manage Internal Supplier Profile Change Approvals setup task to configure internal supplier profile change request approval rules. Find the task in the Approval Management functional area.

The setup task approval configuration does not include any seeded approval rules. You must configure at least one approval rule in one of the available stages in order to use the feature.

For information about supplier profile change request approvals, see Supplier Profile Change Request Approval: Explained.

Manage Internal Supplier Profile Change Request Approval Attributes

Use the Bank Accounts Changed attribute in rule conditions for internal supplier profile change request approvals.

Internal Supplier Profile Change Request Approval: Explained

Approval is required for internal user bank account changes made at the supplier, address, or site level.

Use the Supplier Profile Change Request page to approve changes initiated by internal users, such as bank account changes. See Supplier Profile Change Request Approval: Explained for details.

Requested changes to bank accounts are applied to the supplier profile only when the request is approved. While the request is pending approval, the rest of the profile is still available for editing, and these changes are applied immediately when submitted.

After submitting a bank account change for approval, you cannot make additional bank account changes until the approval process is complete, or the submitted changes are canceled.

Use the Supplier page to view pending change request details. Click View Change Request to display the Profile Change Request page, which shows the supplier attribute changes that have been submitted.

You can also cancel the request by clicking Cancel Change Request.

Review Internal Supplier Bank Account Changes

Internal supplier profile change requests are distributed to approvers as a notification. They also appear on the supplier Overview page in the Supplier Profile Change Requests Pending Approval section.

Use the Supplier Profile Change Request page to review and manage internal supplier bank account changes for an internal supplier profile change request. Access it by clicking the change request link in the Notifications dialog.

Changes to attributes are indicated with the Changed icon adjacent to the bank account row. To see what was changed, click the Details icon. The Change Details dialog box shows which attributes were changed, and the values before and after the proposed change.

Task Life Cycle Setup

Define When to Automatically Dismiss or Withdraw Workflow Tasks

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 following:

  • Functional Area: Application Extensions

  • Task: Manage Applications Core Administrator Profile Values

On the Manage Applications Core Administrator Profile Values page:

  • 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.

How Workflow Tasks Are Archived and Purged

Workflow tasks with a final status, such as Completed or 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 once a month without you doing any setup. You can't change or stop this automatic archive. You can, however, 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

Archived tasks that were last updated over 30 days ago are immediately purged after the monthly automatic archive, without you doing any setup. You can't change or stop this automatic purge.

You can add the Worklist: Notifications and Approvals region to My Dashboard, which is a blank dashboard by default. This region displays the workflow tasks assigned to the person using My Dashboard. After you add the Worklist region, select a value for the Welcome Dashboard Worklist Timeout Interval (ATK_HOME_PAGE_WORKLIST_TIMEOUT) profile option.

Adding the Region

To add the Worklist: Notifications and Approvals region to My Dashboard:

  1. Click Navigator > My Dashboard.

  2. Click your user image or name in the global header, and select Edit Pages in the Administration menu group.

  3. Click the Add Content button where you want to place the region.

  4. Open the Application Content folder in the Add Content dialog box.

  5. Click Add for the Worklist: Notifications and Approvals item.

  6. Click Close.

  7. Save your work, and then click the Close button.

Defining the Timeout Interval

When users open My Dashboard and it contains the Worklist: Notifications and Approvals region, data for the region is retrieved. The Welcome Dashboard Worklist Timeout Interval profile option determines how long to continue retrieving before timing out and displaying no data. In the Setup and Maintenance work area, use the following:

  • Functional Area: Application Extensions

  • Task: Manage Application Toolkit Administrator Profile Values

Note: If you don't see this task, then make sure that the Application Toolkit Component Maintenance feature is enabled at the offering level in the Offerings work area.

On the Manage Application Toolkit Administrator Profile Values page, set the Welcome Dashboard Worklist Timeout Interval profile option.

  • 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

How You Configure Electronic Signature for Purchasing Documents

Before your organization can use electronic signature functionality for purchasing documents, you must enable the feature and perform some setup steps. After 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.

How You Register 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.

How You Enable the Feature

Enable the electronic signature for purchasing documents feature signed in as a Procurement Application Administrator. In the Offerings area, enable the Enable Electronic Signature for Procurement Documents feature:

  • Offering: Procurement

  • Functional Area: Procurement Contracts

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

How You Set Up the Manage Electronic Signature Page

While signed in as Procurement Application Administrator, in the Setup and Maintenance work area, use the Configure Electronic Signature for Procurement Documents task in the Procurement Contracts functional area to set up electronic signature for purchasing documents. On the Manage Electronic Signature page, enter the administrative account information for your organization from the setup on the DocuSign web site. Validate and save the information.

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.

Transaction Console

Give People Access to Manage Self Service Procurement Transactions

You have a couple of options for giving people access to the Transaction Console work area, depending on whether you're assigning them predefined job roles, or your own configured job roles.

  • Assign the predefined Procurement Application Administrator (PO_PROCUREMENT_APPLICATION_ADMIN_JOB) job role.

Your own configured job roles must include this duty role:

  • Review Procurement Approval Transactions as Administrator (ORA_PO_REVIEW_PRC_APPROVAL_TRANSACTIONS)

    This duty role inherits data security and the function security privilege Review Approval Transactions (PER_REVIEW_APPROVAL_TRANSACTIONS_PRIV).

Limit What They Can See

By default, users who have access to the Transaction Console work area can see all transactions, from all product families. You can set things up so that they see only the transactions from specific product families, based on the roles assigned to them.

  1. In the Setup and Maintenance work area, go to the Manage Enterprise HCM Information task.

    • Offering: Procurement

    • Functional Area: Enterprise Profile

    • Task: Manage Enterprise HCM Information

  2. On the Enterprise page, click the Edit button and select Update.

  3. In the Update Enterprise dialog box, fill in your information and click OK.

  4. In the Transaction Console Information section, select the Enable Transaction Security check box.

  5. Click Submit.

Note: You just need to do this for one offering. The setting now applies to all product families. If you're also using Oracle HCM Cloud, make sure transaction security profiles are set up so that HCM administrators can see and act on HCM transactions.

Give People Access to Manage Purchasing Transactions

You have a couple of options for giving people access to the Transaction Console work area, depending on whether you're assigning them predefined job roles, or your own configured job roles.

  • Assign the predefined Procurement Application Administrator (PO_PROCUREMENT_APPLICATION_ADMIN_JOB) job role.

Your own configured job roles must include this duty role:

  • Review Procurement Approval Transactions as Administrator (ORA_PO_REVIEW_PRC_APPROVAL_TRANSACTIONS)

    This duty role inherits data security and the function security privilege Review Approval Transactions (PER_REVIEW_APPROVAL_TRANSACTIONS_PRIV).

Limit What They Can See

By default, users who have access to the Transaction Console work area can see all transactions, from all product families. You can set things up so that they see only the transactions from specific product families, based on the roles assigned to them.

  1. In the Setup and Maintenance work area, go to the Manage Enterprise HCM Information task.

    • Offering: Procurement

    • Functional Area: Enterprise Profile

    • Task: Manage Enterprise HCM Information

  2. On the Enterprise page, click the Edit button and select Update.

  3. In the Update Enterprise dialog box, fill in your information and click OK.

  4. In the Transaction Console Information section, select the Enable Transaction Security check box.

  5. Click Submit.

Note: You just need to do this for one offering. The setting now applies to all product families. If you're also using Oracle HCM Cloud, make sure transaction security profiles are set up so that HCM administrators can see and act on HCM transactions.

Transaction Security Profiles

Transaction Security Profiles can be used to restrict access to transactions in Oracle HCM Cloud. They aren't currently used outside of Oracle HCM Cloud.