Nz en Oracle Oracle Service Procurement WhitepaperF

March 2011

Authors:

Kelly Cure

Mike Levin

David Rapavi

The future of services-driven

procurement Breaking ground with Oracle R12

Services Procurement

The future of services-driven procurement

Contents

Complex Work Document Types and Styles 2

Integration with Procurement Contracts 9

Contingent Labor and OTL 12

Key Findings during Implementation for a Large EPC Company 19

Appendix I 21

Complex Work Document Types and Styles

The future of services-driven procurement 1

Oracle Services Procurement is part of the Oracle E-Business Suite, advanced procurement suite of applications. The application is designed to enhance the level of control and oversight for procurement of services, including expanded visibility to services spend and integration with procurement-related applications.

Oracle Services Procurement offers enhanced functionality over standard Oracle Purchasing in

areas such as:

Expanded service purchase order line types

Ability to transact and track complex service transactions, such as milestone billing progress

payments and work confirmation

Transact advance payments

Ability to apply retainage to complex services

Ability to track services deliverables

Integration with the Buyers Work Center in Oracle Purchasing

Create contracts for services with complex payment terms through integration with Procurement

Contracts

Integration with Oracle iProcurement, Oracle Purchasing, and Oracle Projects

Transact Contingent Labor through integration with Oracle Time and Labor (OTL) and iSupplier

Portal

This paper will educate users and implementers of Oracle Services Procurement on the various

uses and significance of the application. Readers will gain valuable Services Procurement

implementation tips, best practices, and insight into several scenarios, including the contingent labor

process, cross-module integration, and Procurement Contract integration

A case study with a large global Engineering, Procurement, and Construction (EPC) company is

included in this document, detailing valuable lessons learned and implementation steps.



Complex Work Document Types

and Styles

Complex Services Procurement, or Complex Work as Oracle defines it, can only be transacted and

viewed within the Buyers Work Center in Oracle Purchasing; complex work is not accessible in the

core Purchasing forms. The Buyers Work Center is a dashboard view where Buyers and

Supervisors can manage and complete their daily tasks, such as creating and managing

Deliverables, Suppliers, Requisitions, POs, and Agreements. The Buyers Work Center is a central

location where all purchasing activities can be managed, including standard procurement and

complex service procurement.

Complex Purchase Orders (Complex POs) are created in the Buyers Work Center and cannot be

accessed in Core Forms. The Complex PO is a different Document Style than the Standard

Purchase Order (Standard PO) that will need to be created as a part of the Service Procurement

configuration. Document Styles are set up by accessing the Purchasing Super User Responsibility

and navigating to Setup: Purchasing Document Styles. As shown in Image 1 below, new

Document Styles can be created or existing styles can be updated by clicking on the pencil icon. For

project-centric companies, e.g., companies in the construction business, Document Styles such as

Contract PO or Subcontract PO (as show in image 1) are helpful in distinguishing between

standard POs and POs that relate directly to a Subcontract or Contract and contain contractual

terms and conditions. Although there are other ways to segregate purchasing documents in the

system, this is a simple visual clue that may assist Buyers.

Image 1.



With this Document Style comes enhanced functionality, such as Progress Payments, Retainage,

and Advancements, which are enabled independent of each other on the Complex PO Document

Style as shown in Image 2 below.

Image 2.

The Document Types enabled on the Document Style are important for Global Agreements (Global

Blanket Purchase Agreements (BPAs) and Global Contract Purchase Agreements), as POs act as

releases from Global Agreements. The Agreement number needs to be referenced in the Source

Document field in order for the PO release to be linked to the Agreement. This field is accessed by

editing the applicable PO line, and is shown in Image 3.

Image 3.

If the Document Style (In this case Complex PO) applies to Contract Purchase Agreements or

Blanket Purchase Agreements, this Enable box must be checked as shown in Image 4. Only

Agreement types Enabled on the Document Style can be referenced on the PO. For example, in

Image 4, BPAs are not enabled on the Document Style setup, therefore only Contract Purchase

Agreements will be able to be linked to this Document Style. Although all agreements will be

searchable from the PO, if the user attempts to reference an Agreement that is not setup on the POs

Document Style, an error message will appear.



Image 4.

Associating a Contract Purchase Agreement with the Complex PO is useful when purchases

referencing a single Agreement need to be made in multiple currencies. This may be a valuable

workaround for companies that have a requirement for multiple currencies on a single PO or to link

purchases made in various currencies. Using a Contract Purchase Agreement to link PO releases

with various currencies is a viable option to satisfy multi-currency purchasing requirements.

While Global Agreements can be created in both core forms and the Buyers Work Center,

Agreements created in core forms without the Global box checked will not appear in the Buyers

Work Center. Furthermore, all agreements created in the Buyers Work Center are Global

Agreements regardless of how many Operating Units are enabled on the particular Agreement. See

Image 5 below. While only one Operating Unit is enabled on the Agreement, since it is being created

in the Buyers Work Center, it is automatically a Global Agreement.

Image 5.



Complex PO Functionality: Retainage and Advancements:

After the Complex PO Document Style has been defined, purchases with retainage, advancements,

and progress payments can be made. Retainage is set at the line level and is added by editing a line

on the Complex PO and entering a percentage to be retained for the given line, as Images 6 and 7

depict.

Image 6.

Image 7.

There is also an option to define a maximum retainage amount that can be withheld from the line.

The maximum retainage amount is a not to exceed limit and is checked each time retainage is

withheld on an Invoice. While the retainage functionality is only available with Services Procurement

on Complex POs, there is no restriction for the various line types on the Complex PO that retainage

can be applied to. Retainage cannot be specified at the header level of the PO or for individual Pay

Items.

Once the Invoice has been received, the process for Invoice matching to POs with retainage is the

same as matching to any other PO. When entering the Invoice, the Invoice amount can be entered

either gross or net of the retainage amount. The Net of Retainage checkbox should be enabled if

entering the net amount to ensure the calculation is done correctly. Upon validation of the Invoice,

the retainage amount will automatically be calculated based on the retainage percentage set up on

the PO line and withheld from payment.

Once the supplier submits the Invoice for the release of the retainage amounts, a Retainage

Release Invoice type can be created and matched to the same PO number. The matching process

for the retainage release is slightly different from the standard matching process as the user will be



brought to a form to select from an available list of retained amounts related to the given PO. Once

matching is complete, the retained amounts will be released and the Invoice can be paid using

standard Invoice payment processing.

Advances are also defined by editing each applicable line on the Complex PO. The Advancement

amount is the total amount agreed in the contract that the contractor can claim via Prepayment

Invoices before work has been executed. Contractors can leverage the iSupplier Portal to submit

Prepayment Invoices.

Line Types and Pay Items:

While all Line Types in the system are available on a Standard PO, there are certain restrictions with

Line Types on the Complex PO. Lines with the Value Basis of Amount cannot be used with complex

purchasing. Amount based line types are only available on Standard POs, which will not disrupt

most business processes. Fixed Price Line Types may be used in place of Amount based Line

Types on a Complex PO and are very flexible as all Pay Item Options are available for Lines with

Fixed Price value basis.

The Rate-Based Temp Labor Line Type is also unavailable on the Complex PO. This line type is

used exclusively for billing labor hours at a certain rate for a Job that has been defined by Human

Resources (HR). Oracle has a specific process for temporary labor (also referred to as Contingent or

Contractor Labor), which uses integrated functionality between the iProcurement, Purchasing, OTL,

and Projects Modules that will be detailed later in this document. While Rate-Based Temp Labor

lines are unavailable on Complex POs, Fixed Price Temp Labor lines are available on the Complex

PO. This line type is intended for the purchase of contingent labor with a fixed fee or lump sum

amount.

With the exception of the Rate and Amount Based lines detailed above, all other lines in the system

are available on the Complex PO with associated Pay Items. Pay Items are a way to manage

progress payments by specifying the work component, associated dollar amount and due date for

completion. They are located on the Pay Item tab of the complex PO, in place of the Schedules tab

on the Standard PO.

Similar to other Services Procurement functionality, Pay Items are set up on the Complex PO

Document Style. Progress Payments must be enabled on the document style for partial payments

throughout the performance of the contract to be allowed. By enabling progress payments, at least

one Pay Item must be selected on the Complex PO Document Style. There are three types of Pay

Items available, Lumpsum, Milestone, and Rate. Depending on the Line Type selected on the PO,

all Pay Items or a subset of Pay Items will be available for use. See the Document Style setup

Image 8 below.

Image 8.



All lines with fixed price value basis have all Pay Items available, while lines with value basis of

quantity only have Milestone Pay Items available. Milestone Pay Items must be fully completed

before payment can be requested by the contractor by submitting a Work Confirmation. Unlike the

other Pay Items, there is no partial completion for Milestones and the Progress Column on the Work

Confirmation will default to 100% in a read only field as shown below in Image 9. Milestones are the

most commonly used Pay Item as Milestones may be used with all Lines Types on the complex PO.

Image 9.

The Lumpsum and Rate Pay Items are only available for Line Types with a Fixed Price value basis.

Partial progress can be reported against both Lumpsum and Rate Pay Items and the Percent

Complete field is editable on the Work Confirmation as shown in Image 10 below. Rate Pay Items

can be leveraged with Fixed Price Temp Labor lines and will be detailed in the Contingent Worker

solution later in this document.

Image 10.

Overview of Complex Procurement Line Types and Pay Items:

Oracle Services Procurement enhances standard Oracle Purchasing by adding the following

additional Line Types.

Line Type Pay Items Available

Fixed Price Services Milestone, Lumpsum, Rate

Fixed Price Temp labor Milestone, Lumpsum, Rate

Quantity Based Services Milestone Only

Quantity Based Goods Milestone Only

Quantity Based Consulting Services Milestone Only

Other Line Types: e.g. Quantity Based Rental Milestone Only

Amount Based Line Types Not available on Complex PO

Rate-Based Temp Labor Not available on Complex PO



After a Complex PO with Pay Items is submitted and approved, a Work Confirmation can be created

to process the Pay Items. Work Confirmations (as shown in Images 9 and 10) are created in

iSupplier Portal and can also be accessed from iProcurement. Depending on business processes,

Work Confirmations can be created and managed in several different ways. Work Confirmations

utilize Oracles Approvals Management Engine (AME) which can be leveraged to tailor the Work

Confirmation approval workflow.

The Contractors and Suppliers are able to log into Oracle iSupplier Portal to create Work

Confirmations which will routed to the appropriate Project Manager or Supervisor. The Supervisor is

able to approve the Work Confirmation or reject the Work Confirmation and engage in

communications with the supplier, allowing them to revise the Work Confirmation and attach

additional supporting documentation as needed. Work Confirmations do not use automatic

numbering which is intended to allow the contractor to use a naming or numbering convention

meaningful to them. Best practices would require contractors to use standardized naming or

numbering convention for the Work Confirmation. The Period of Performance date fields are not

mandatory on the Work Confirmation, but Contractors should utilize the field to provide additional

detail for the given Pay Item(s). Work Confirmations act as a receipt for the services and Pay Items

submitted.

Pay on receipt functionality can be leveraged if the Contract and Supplier Site have the Pay on

Receipt flag set to 'Receipt'. This allows the AutoInvoice Program to automatically generate Invoices

for both Contract Financing and Delivery Payments.

There is currently no option to create a standard receipt for Complex POs or utilize Inventory

Destination Types. Although this is logged as an Enhancement Request with Oracle, this

functionality may not be changed in the near future. If a business requirement exists to inventory

goods that are purchased with milestone payment functionality or require progress payments, this

will likely require an enhancement to the system.

Integration with Procurement Contracts


Integration with Procurement

Contracts

While Oracle Procurement Contracts enable Contract Specialists or Buyers to author contract terms

and conditions, there are many additional advantages to using this module in concert with other

modules such as Oracle Purchasing, Services Procurement, and Sourcing. Oracle Procurement

Contracts is essentially a contract authoring application with a library and repository for contractual

terms and conditions. Both global and local versions of contract clauses can be authored, approved

and linked in the Contract Library. The integration of Procurement Contracts with Services

Procurement provides significant benefits to companies making progress payments and managing

contractual deliverables. This section focuses on the integration between Services Procurement and

Procurement Contracts, not Sourcing and Procurement Contracts.

Contracts created in Procurement Contracts Contract Library are not stand-alone purchasing

documents and do not have lines. Contract Templates are intended to be created once in the

Contract Library and referenced on documents such as POs, Agreements, and Request for

Quotations (RFQ) within one or across multiple Operating Units. As the terms and conditions are

referenced on purchasing documents, Oracle allows Standard Contract to be modified as needed for

the specific purchase or agreement without the standard copy in the Library being altered.

The core components of the Procurement Contract are the Clauses and the Deliverables. The

contract clause is the written copy of the contract terms and conditions. Before a clause can be

added to a contract a Section, which is a heading to organize clauses under, must be added.

Sections are required for all contract templates but intended for contract templates with many

clauses. Sections allow the appearance of the printed contract, and contract terms on the printed

PO, to appear professional and structured. Sections can be leveraged for rule based contract

authoring by organizing required clauses under a section heading and making the section a

Mandatory Section.

As mentioned above, a contract clause is the legal or contractual language stating various elements

of the terms and conditions. A Standard Clause is the original master stored in the contract library.

When a clause requires modification for a specific agreement, purchase, or supplier it can be edited

right from the Purchasing Document by making the clause Non-Standard as shown in Image 11.



Image 11.

There are various options for control around who can edit the standard document. Editing access

can be restricted by user by setting up Roles in the system or by contract by leveraging functionality

such as the Protect Text option on the contract header (see Image 12).

Image 12.

If business requirements dictate certain clauses as mandatory on a contract, the contract

administrator can leverage the Contract Expert functionality to create rule based contracts. The

Contract Expert functionality is accessed from the Procurement Contract Terms Library as shown in

Image 13.

Image 13.



Deliverables are the other key component of the Procurement Contract. Deliverables are set up per

contract template but can be optionally included or excluded per purchasing document by editing

Update Contract Details. Deliverables have flexible notification functionality and can manage by the

contract administrator of project manager from the Buyers Work Center dashboard view.

Notifications can be set up to alert various supervisors and managers based on the deliverable

timeline. Recurring deliverable functionality can also be leveraged if a particular deliverable is

repeated multiple times over a set period of time. Alignment of Complex PO Pay Items with contract

deliverables is an integrated solution for managing contract deliverables and progress payments.

The Contract Administrator can set up contract deliverables within the Procurement Contract

template to align with Milestone Payments on the Complex PO. Project Managers can be alerted

that a deliverable due date is approaching and ensure progress is advancing as scheduled, or alert

the supplier to initiate the Work Confirmation request. Aligning Deliverables with Milestone payments

and managing both from the Buyers Work Center allows Project Managers and Supervisors easy

visibility into the contract schedule and a better chance of staying in compliance with the contract

deliverables.

Procurement Contracts functionality is integrated with Core Purchasing and the same functionality

can be leveraged in core forms as in the Buyers Work Center. When a contract template is created

in the Contract Library, the Contract Administrator must determine which purchasing documents will

use the terms and conditions and deliverables on the contract.

When selecting from the list of PO, BPA, Contract Purchase Agreement, Auction, Quote, Request

for Information (RFI), and RFQ, the contract administrator will also have the option to select the

template as the Default terms and conditions for one or all of the purchasing documents as shown

in Image 14 below. If the Default Template box is selected, the contract template including clause

and optionally including deliverables will be defaulted onto each document of that type created in the

system. For example, if the Default Template box was checked for POs, each time a PO is

created, the contract terms and conditions would default onto the purchasing document. At the time

of PO creation, the template terms and conditions may still be modified and additional clauses may

be added.

Image 14.

Contingent Labor and OTL



Oracle has a relatively new integrated solution designed to handle Contingent Labor, otherwise

referred to as Temporary or Contract Labor, business scenarios. The solution spans Oracles

iProcurement, Purchasing, OTL, Projects, and iSupplier modules. Companies may be accustomed

to having the Human Resources department handle contingent labor process independent of other

departments, but with Oracles integrated solution, certain responsibilities within the Purchasing and

Projects modules are required for the end-to-end process.

The Contingent Labor process begins with the demand for labor usually in the form of an HR

Requisition. If additional staff needs to be hired, HR will go through the process of hiring a new

contractor. There is an additional optional Requisition within the iProcurement module called a

Contractor Request. The Contractor Request is created by navigating to the Contractors tab in

iProcurement shown below in Image 15. The Contractors tab is a dashboard view that contractors

can be managed from. The status of Contractor Requests can be monitored from here and

contractor evaluations can be created and viewed here as well.

Image 15.

When creating the contractor request a Line Type and Job must be selected. Only Rate-Based

Temporary Labor and Fixed Price Temporary Labor lines are available to use on the contractor

request as these lines are specifically for contingent labor. In order to select a Job, a setup in Oracle

Purchasing is required called Job Category Association. This setup is necessary to systematically

link a Job to a Purchasing Category, and subsequently use the Job on the Contractor Request and

PO. A convenient method may be used to manage this setup by creating a Temporary Labor

Purchasing Category to use as a standard for all contingent labor Jobs. This task is accessed

through the Purchasing Super User responsibility by navigating to Setup: Purchasing. From here

you can search for existing associations or create a new association. Without this setup, no Jobs will

appear on the Contractor Request.

On the header of the Contractor Request (Image 16) the Requester will define the type of labor

being purchased (rate based or fixed price), the Job of the worker, the start date, and an optional

end date.



Image 16.

From here, the Requisitioner can either suggest a Supplier or accept the default setting to use a

Preferred Supplier. The Target Rate for the contractor, the unit for the rate (Hour, Day, Quarter,

etc.), and Labor Amount (total dollar amount for the PO line) are also specified on the Requisition

(Images 17 and 18). There is also a check box for Allow Rate Differential this is referring to the

Price Differentials, such as Holiday, Travel, and Overtime Rate, allowed on the PO. If the

Requisitioner does not check the Rate Differential box, the Buyer will still be able to enable various

Price Differentials on the PO.

Image 17.



Image 18.

Buyers can leverage the AutoCreate functionality to easily turn the Contractor Request into a PO in

Core Forms, or pull up the Req lines in the Buyers Work Center and create a Standard PO from

Rate-Based Temporary Labor Lines. Once the PO is created, Buyers can reference applicable

Procurement Contract terms and conditions on the header of the PO. For Rate-Based Temporary

Labor lines, the Job title is listed in the Item field on the PO along with the standard rate per unit

(dollars per Hour, Day, Month, etc.) and total amount for the line. The Buyer can drill down into the

line details by navigating to the Temporary Labor Tab in the Core forms or by clicking the edit lines

pencil in the Buyers Work Center.

The Buyer can define Price Differentials for each PO line, by selecting different types of rates that

will apply to the contingent worker as shown in Image 19. If Holiday, Overtime and/or Travel time is

to be charged at a different rate than the standard rate defined on the PO line, the Buyer will enter a

Multiplier after selecting the type of Price Differential. The Multiplier allows the Buyer to define

alternative rates from the standard rate while not having to create a separate line on the PO.

Image 19.

If a Master Agreement exists with the supplier of the contingent labor, the Buyer can reference this

agreement in the Source Document field on the PO. Upon PO Submittal and Approval, the amount

on the PO will release from that agreement tracking the total amount remaining on the Agreement.

An important aspect of Oracles current Contingent Labor solution is the Project information on the

PO. If the contingent laborer is to charge time to a Project in OTL, there must be a project on the PO

line. In some industries, such as project-centric Engineering and Construction companies,

contingent labor may need to be procured before knowing exactly which project the worker will

charge time to. In this case, an Overhead Project can be leveraged or the cost-owning Resource

Center (RC) can be referenced as the Project Task. While the commitment will go to the Project on

the PO, the contingent worker will be able to select various projects on the timecard as needed.

The Core HR and Procurement processes can be handled independently of each other but must

both be completed in order to enable a contingent worker to charge time in OTL. As previously

mentioned, in order to enable the contingent worker solution, a PO must be created with the

appropriate PO lines, rates, and project association. Without this information, the contingent worker

will not be able to charge time against a PO and corresponding project. Once the PO information is

created, the job, supplier name, supplier site, and supervisor will need to be associated on the HR

assignment record prior to the PO and line items being selected. This links the contingent worker to

the PO allowing the contingent worker to charge time. It is also important to note, in order to see the



correct PO when searching the LOV in Core HR; the contingent worker needs to be assigned to the

same job that is listed on the PO. In order for time card approvals to function properly, a supervisor

must also be entered on the contingent workers assignment record.

Image 20.

Previously in HR and OTL, a contingent worker could be associated with and charge time against

one PO and PO line. With the introduction of the Purchase Order Information task flow and Oracle

Applications Framework Web user interface in Oracle R12.1+, contingent workers can now report

time for multiple POs. This new functionality also allows multiple contingent workers to charge time

to the same PO line within a PO. Additionally, it allows contingent workers to report time against any

valid project whether or not the project is associated to a PO, as long as a project is associated with

the PO. You can navigate to this new user interface from the Supplier tab of the Assignment page of

Core HR. Currently, multiple PO information can only be added through Core HR. Oracle is

developing additional functionality to allow multiple PO and PO lines to be associated through the

Hire Contingent Worker function in Self Service Human Resources (SSHR). Single POs and

corresponding PO lines can still be successfully added through SSHR.

Image 21.



This enhancement enables the OTL Time Sheet to retrieve multiple POs in the Purchase Order list

of values. Now this LOV populates all associated POs of the contingent worker and enables the

worker to report time against multiple POs. In order for a contingent worker to enter time against a

project, a project must be added to the PO that will be used by that resource. As long as that project

is attached to the PO, the contingent worker can enter time for any available project. On the time

card, the contingent worker must select a project, project task, PO, PO line, Type (Regular,

Overtime, etc) and hours worked in order to successfully submit time for approval. Contingent

workers can charge time only to those POs and PO Lines that are attached to their HR record. If this

is not maintained, contingent workers will not be able to see the PO when they charge time, and

hence will not be able to submit the time card for approval.

Image 22.

Once the timecard is approved a concurrent process called Retrieve Time from OTL runs and

brings the timecard from OTL acting as a receipt against the PO in Purchasing. Timecards can be

viewed in the Contractors tab of iProcurement where the entire Contingent Labor process can be

monitored, as well as in the iSupplier Portal. Contractors can view the PO, including receipts and

payments against the PO, and Timecards from by logging into iSupplier. Buyers and Supervisors

can also track the Contingent Worker process from iProcurement or by utilizing the internal view of

iSupplier. Upon receipt of the Timecard into Purchasing, the Create Accounting processes will need

to be run for Projects to begin distributing labor and costs. A big advantage of this process for many

organizations is the ability to use the Pay on Receipt functionality with this process. In order to

leverage automatic payment, the Pay on Receipt concurrent process will need to be initiated. This

process can be run wide open, or ERS can be entered in the first line of the parameters.

One potential point of contention with Oracles integrated Contingent Worker solution is the

communication required across Purchasing and HR departments. Utilizing a PO to facilitate the

purchase of Contingent Labor is a change to the way that many companies handle temporary labor

today. A primary benefit, which brings measurable value, is the visibility and traceability throughout

the process. By utilizing tools such as iSupplier Portal and the iProcurement Contractors tab,

companies will be able to streamline their oftentimes fragmented Contingent Worker processes.

An additional process for purchasing temporary labor that does not utilize integration with OTL is

available. This solution is also applicable when temporary labor is purchased by a fixed amount, not

on a rate per hour basis. This process is relatively simple using a Complex PO, Fixed Price Temp

Labor Line Type and any of the Pay Item Options (Milestone, Lumpsum, or Rate). A Work

Confirmation will be created when the labor has been performed to act as the receipt against the

Complex PO.



This solution can also be applied when the users do not have a requirement to maintain Contingent

Worker records in HR, or does not desire Contingent Workers to enter time into OTL. If a high

volume of contingent workers are used with a considerable turnover rate, a company may not wish

to enter and retain each contingent worker record in the system to allow the workers to time write in

OTL. Additionally, this process can be applied when a single timekeeper tracks contingent labor

hours worked. The timekeeper can reduce effort and manual entry by entering a one-time PO and

Work Confirmation for various temporary laborers hours worked.

As mentioned above, a Complex PO and Fixed Price Services line must be used to leverage this

solution. The Buyer will enter a total dollar amount (accounting for one or many workers) on a Fixed

Price line for each Job on the PO before navigating to the Pay Items Tab. Here, the Rate Pay Item,

quantity, and unit of measure (e.g. hour, day, or month) will be selected. The Rate Pay Item Quantity

automatically defaults to one, but can be adjusted to the number of hours the workers are expected

to work. The Amount on the PO Line must be enough to cover the expected rate times quantity of

hours worked.

When the work has been performed and hours need to be accounted for, the timekeeper or project

manager will log into the iSupplier Portal Internal View Responsibility and pull up the applicable

PO. After searching for and selecting the desired PO, the user will navigate to the Actions drop-

down (located at the top or bottom of the page) and select Create Work Confirmation. This option

only appears in the Actions drop-down for POs where a Work Confirmation is applicable or can still

be created. Work Confirmations are not available for Standard POs; only the standard receipt

process is available. Similarly, if the Complex PO has been closed the user will have view only

options.

By Selecting Create Work Confirmation the user is navigated to a list of all Pay Items on the PO.

The view defaults to Pay Items Due in the Next 30 Days but can be change to default to All Pay

Items or Pay Items Due in the Last 30 Days. From this page the user will select the appropriate

Pay Item(s) and click next to navigate to the Work Confirmation page. The Work Confirmation

requires a unique name as automatic numbering is not available for Work Confirmations. Best

practices require users adhere to a standard naming or numbering convention. The Period of

performance date fields are not mandatory on the Work Confirmation, but should be used to provide

additional details to the approver. Attachments can be easily added to the Work Confirmation by

clicking the green plus sign in the Attachments column. In this case, the timekeeper could attach

information on the contractors that have been managed offline, such as spreadsheets containing

workers names and time worked. See Images 20-22 below.

Image 23.



Image 24.

Image 25.

If a company has an agreement with a staffing agency for supplying contingent labor, the supplier

can also perform the Work Confirmation process, and submit a Work Confirmation Request to the

project manager or supervisor following the same steps listed above.

Key Findings during Implementation for a Large EPC Company


Key Findings during

Implementation for a Large EPC

Company

As more of Oracles applications move toward the Self Service HTML forms, the enhanced

functionality available in the Buyers Work Center is decisively the future of Oracle Procurement. In

this case study with a large EPC Company, with approximately 60,000 users, the importance of

understanding the enhanced functionality and gaps in functionality across Core Forms Purchasing

and the HTML forms of the Buyers Work Center was critical. While tips have been integrated into

the document by topic, please see Appendix I. for a complete listing of variances in functionality

between Core Forms purchasing apps and HTML Self Service purchasing applications.

Oracles integrated Contingent Labor solution proved to be an important, yet involved process.

Implementation team members from various process areas (Procurement, HR, Projects and

Accounting) were required to design, test and demo the full end-to-end scenario. At times, the

process and functionality proved difficult for the users to grasp, and adoption of Oracles standard

solution was not immediate. Ultimately, both operational future users, business owners and the

Operating Committee members eagerly approved the solution citing the traceability, visibility and

Pay on receipt functionality as critical wins.

The ability to manage Progress Payments, synched with Contract Deliverables, within the ERP

system provided significant benefits to the EPC organization as well. Managing Work Confirmations

with AME workflow to facilitate receipt of the services was a vast improvement in functionality for the

procurement department.

The company did not implement Oracle Sourcing, opting to use a third-party sourcing tool

customized for their specific needs. As a result, the inherent integration between Services

Procurement, Sourcing, and Procurement Contracts was not fully realized.

Summary

Oracle Procurement Services is a valuable application with the advanced procurement suite

specifically designed for organizations that engage in procurement of services. The application

enhances the functionality of the Oracle Purchasing in order to enable a greater level of control and

oversight for procurement of services. Services Procurement allows services-specific transactions,

including amount based and fixed rate services purchases, complex service transactions, such as

milestone billing progress payments, retainage, advance payments, and work confirmation.

In addition, the application has built in integration with related Oracle EBS applications, such as

Procurement Contracts, iProcurement, Purchasing, Projects, Time and Labor (OTL) and iSupplier

Portal that enables a total solution for procurement within one ERP system.

Key Findings during Implementation for a Large EPC Company


References

Oracle Services Procurement Oracle Data Sheet, www.oracle.com

Oracle Purchasing User's Guide, Release 12, Vic Mitchell, Copyright 1996, 2006, Oracle.

Appendix I


Appendix I

Functionality Requisitions POs

HTML

(iProc) Core Forms

HTML

(Buyer Work

Center)

Core

View BPA/Quote Images Y

Manage Approvals Y

Change Req (not on a PO) Y

Change Req (on a PO) Y

Contractor Request Y

Information Template/Smart Form Y

Fixed Price Line Types Y

Change Price of an Item from Item

Master

Y

See Non-Priced Items in the Catalog Y

Enter a ship-to location Y

Enter a different currency for a catalog

Req

Y

View Item Master Images Y

Split Req Line to Multiple PO Lines Y

Complex POs (retainage + prog pmt) Y

Complex Agreements Y

Complex Contracts Y

View PO Revisions Y

View Deliverables Y

Detailed Preferences for POs Y

All Line Types are Available Y

Global Agreements* Y Y

Non-Global Agreements** Y

About Deloitte

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of

member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description

of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a detailed

description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the

rules and regulations of public accounting.

Copyright 2011 Deloitte Development LLC. All rights reserved.

Member of Deloitte Touche Tohmatsu Limited

Nz en Oracle Oracle Service Procurement WhitepaperF

Documents

Transcript of Nz en Oracle Oracle Service Procurement WhitepaperF