Complex Work Document Types and Styles

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:
a) Expanded service purchase order line types
b) Ability to transact and track complex service transactions, such as milestone billing
progress payments and work confirmation
c) Transact advance payments
d) Ability to apply retainage to complex services
e) Ability to track services deliverables
f) Integration with the Buyers Work Center in Oracle Purchasing
g) Create contracts for services with complex payment terms through integration with
Procurement Contracts
h) Integration with Oracle iProcurement, Oracle Purchasing, and Oracle Projects
i) Transact Contingent Labour 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

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
2

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 multicurrency purchasing requirements.
3

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:

1.1
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:
4

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

1.1.1 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.
6

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 Labour lines and will be detailed in the
Contingent Worker solution later in this document.

Image 10:

1.1.2 Overview of Complex Procurement Line Types and Pay Items:

Oracle Services Procurement enhances standard Oracle Purchasing by adding the following
additional Line Types.

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 Oracle 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.
In the registrations tab, parameters relating to the Organization as a whole are defined such
as Registration number of the Organization, Jurisdiction under which the organization is falling
etc., Also one important parameter which will drive the accounting on the event of service tax
credit distribution is Service tax distribution in PLA/RG. Based on the register name specified
here, Accounting and register updates will happen.

1.2

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
8

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 NonStandard 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
9

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
10

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:

1.3

Contingent Labour 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
Oracle 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 Oracle integrated solution, certain responsibilities
within the Purchasing and Projects modules are required for the end-to-end process.
11

The Contingent Labour process begins with the demand for labour 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 Labour and Fixed Price Temporary Labour lines are available to use on the
contractor request as these lines are specifically for contingent labour. 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 Labour Purchasing Category to use as a standard for all contingent
labour 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
oflabour being purchased (rate based or fixed price), the Job of the worker, the start date, and
an optional end date.

Image 16:

12

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:

13

Buyers can leverage the AutoCreate functionality to easily turn the Contractor Request into a
PO in Core Forms, or pull up the Requisition lines in the Buyers Work Center and create a
Standard PO from Rate-Based Temporary Labour 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 Labour 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 Labour 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. 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.
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 Labour 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.

14

Image 19:

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

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
15

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

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 Oracle 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 labour that does not utilize integration with
OTL is available. This solution is also applicable when temporary labour 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 Labour Line Type and any of the Pay Item Options (Milestone, Lumpsum,
or Rate). A Work Confirmation will be created when the labour has been performed to act as
the receipt against the Complex PO.
16

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 and 21.
Image 22:

17

Image 23:

Image 24:

If a company has an agreement with a staffing agency for supplying contingent labour, 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.

18