Introduction:

Purpose of this document is to cater basic functional & Technical knowledge on Procure to Pay Cycle and providing brief details on Subject Areas under BIApps Procurement and Spend module. Currently this document has P2P basic functional details and BIApps Purchase Requisition Subject Area basics. As we progress further more SA’s will be added and also content will be enhanced.Before we get in to functionality lets understand few basic ERP term’s like Item, UOM, & Item Categories.

Item: An Item is a physical entity which is used for buying and selling and enables us differentiate one from the other. Item description identifies the item.

MTL_SYSTEM_ITEMS_B It is the definition table for items. This table holds the definitions for inventory items, engineering items, and purchasing items. You can specify item-related information in fields such as: Bill of Material, Costing, Purchasing, Receiving, Inventory, Physical attributes, General Planning, MPS/MRP Planning, Lead times, Work in Process, Order Management, and Invoicing

Units of Measure:

The primary unit of measure is the stocking unit of measure for an item. The primary unit of measure is an item attribute specified when defining each item.E.g. Each, Piece, Liter, Kilogram etc.

Item Categories:

Code used to group items with similar characteristics, such as plastics, metals, or glass items.

Underlying table:

MTL_ITEM_CATEGORIES:

This table stores inventory item assignments to categories within a category set. For each

category assignment, this table stores the item, the category set, and the category. Items

always may be assigned to multiple category sets. However, depending on the Multiple

Assignments Allowed attribute value in a given category set definition, an item can be

assigned to either many or only one category in that category set.

MTL_CATEGORIES_B:

This is the code combinations table for item categories. Items are grouped into categories

within the context of a category set to provide flexible grouping schemes. Item categories

now support multilingual category description. MLS is implemented with a pair of tables:

MTL_CATEGORIES_B and MTL_CATEGORIES_TL. MTL_CATEGORIES_TL table holds translated

Description for Categories.

MTL_CATEGORY_SETS_B:

It contains the entity definition for category sets. A category set is a categorization scheme

for a group of items. Items may be assigned to different categories in different category sets

to represent the different groupings of items used for different purposes. An item may be

assigned to only one category within a category set, however. STRUCTURE_ID identifies the

flex field structure associated with the category set. Category Sets now support multilingual

category set name and description. MLS is implemented with a pair of tables:

MTL_CATEGORY_SETS_B and MTL_CATEGORY_SETS_TL. MTL_CATEGORY_SETS_TL table holds

translated Name and Description for Category Sets.

Procure to pay cycle:

Requisition

It is a request for purchasing goods or services, especially a formal written request on a pre-

printed form.

It refers to demand the use or supply of services or goods by official order.

Types of Requisition

1) Internal Requisition:

Internal Requisitions provide the mechanism for requesting and transferring material from

inventory to other inventory or expense locations.

2) Purchase Requisition

Purchase Request is a precise document generated by an internal or external organization

to notify the purchasing department of items it needs to order, their quantity, and the time

frame that will be given in the future. It may also contain the authorization to proceed with

the purchase. It is also called Purchase Order Request.

The status of the requisition after creation will be “Incomplete”. The requisition needs to be

approved first before proceeding further by the concerned authority. The status will now be

updated to “In Process” .The workflow then will send an Approval notification to the

concerned person using which he can Approve or Reject the requisition.

Requisition line information is stored in PO_REQUISITION_LINES_ALL, a column

REQS_IN_POOL_FLG which is by default set to “N”, and changed into “Y” when the

requisition is approved and sent to Buyers Work Bench.

Underlying Tables:

1) PO_REQUISITION_HEADERS_ALL

Important columns:

REQUISITION_HEADER_ID: Requisition header unique identifier

PREPARER_ID: Unique identifier of the employee who prepared the requisition

SEGMENT1: Requisition number

AUTHORIZATION_STATUS: Authorization status type

NOTE_TO_AUTHORIZER: Note to approver (Unused since release 8.0) TYPE_LOOKUP_CODE:

Requisition type

TRANSFERRED_TO_OE_FLAG: Indicates whether an internal requisition has been transferred

to Order Management.

INTERFACE_SOURCE_CODE: Source of requisition from Requisition Import

CLOSED_CODE: Close status

ORG_ID: Operating unit unique identifier

Description:

PO_REQUISITION_HEADERS_ALL stores information about requisition headers. You need one

row for each requisition header you create.

Each row contains the requisition number, preparer, status, and description.

REQUISITION_HEADER_ID is the unique system-generated requisition number.

REQUISITION_HEADER_ID is invisible to the user. SEGMENT1 is the number you use to

identify the requisition in forms and reports. Oracle Purchasing generates SEGMENT1 using

the PO_UNIQUE_IDENTIFIER_CONTROL table if you choose to let Oracle Purchasing generate

requisition numbers for you.

2) PO_REQUISITION_LINES_ALL

Important columns:

REQUISITION_HEADER_ID: Requisition header unique identifier

LINE_NUM NUMBER: Line number

LINE_TYPE_ID: Line type

CATEGORY_ID: Item category unique identifier ITEM_DESCRIPTION: Item description

QUANTITY NUMBER: Quantity ordered

DELIVER_TO_LOCATION_ID: Deliver-to location unique identifier

Description:

PO_REQUISITION_LINES stores information about requisition lines. You need one row for each

requisition line you create. Each row contains the line number, item number, item category,

item description, need-by date, deliver-to location, item quantities, units, prices, requestor,

notes, and suggested supplier information for the requisition line.

Destination Type: It may be Inventory (to store bulk of items) or Expense (if the item is

expense and supposed to be shipped to the location or requester directly bypassing the

inventory).

3) PO_REQ_DISTRIBUTIONS_ALL

Important columns:

DISTRIBUTION_ID: Requisition distribution unique identifier

LAST_UPDATE_DATE: Standard who column

LAST_UPDATED_BY: Standard who column

REQUISITION_LINE_ID: Requisition line unique identifier

SET_OF_BOOKS_ID: Set of Books unique identifier

CODE_COMBINATION_ID: Unique identifier for the General Ledger charge account

DISTRIBUTION_NUM: Distribution number

ALLOCATION_TYPE: Method of allocation across distributions. Can be PERCENT

Description:

PO_REQ_DISTRIBUTIONS_ALL stores information about the accounting distributions

associated with each requisition line. Each requisition line must have at least one accounting

distribution. You need one row for each requisition distribution you create. Each row includes

the Accounting Flex field ID and requisition line quantity.

Non-Catalog Requests (Requisition’s on which Item reference will not be there)

Requesters can request items and services not found in the catalog or shopping lists by

creating non-catalog requests. Using catalog administration, you can create non-catalog

request templates, also known as smart forms.

Purchase Orders

A purchase order (PO) is a commercial document and first official offer issued by a buyer to

a seller, indicating types, quantities, and agreed prices for products or services. Acceptance

of a purchase order by a seller forms a contract between the buyer and seller, so no contract

exists until the purchase order is accepted. It is used to control the purchasing of products

and services from external suppliers.

Types of Purchase Orders:

1. Standard PO: A Standard PO is created for one–time purchase of various items.

2. Planned PO: A Planned PO is a long–term agreement committing to buy items or services

from a single source. You must specify tentative delivery schedules and all details for goods

or services that you want to buy, including charge account, quantities, and estimated cost.

3. Blanket agreement: A Blanket PO is created when you know the detail of the goods or

services you plan to buy from a specific supplier in a period, but you do not know the detail

of your delivery schedules.

4. Contract agreement: Contract purchase agreements are created with your suppliers to

agree on specific terms and conditions without indicating the goods and services that you

will be purchasing.

Choose type as Standard Purchase Order. Enter the Supplier, Buyer. In the Lines tab, specify

the line number, line type, Item, quantity, price etc.

Click Terms to enter terms, conditions, and control information for purchase orders.

Click Currency button to enter and change currency information for purchase orders, RFQs,

and quotations.

Click Shipments button to enter multiple shipments for standard and planned purchase

order lines Purchase order shipment specifies the quantity, ship–to organization and

location, date you want your supplier to deliver the items on a purchase order line, and

country of origin for the items. When you save, Purchasing creates distributions depending

on the default information available.

To enter more shipment information, select the More tab.

Enter the Receipt Close Tolerance percent, Invoice Close Tolerance percent to set the

receiving and invoice close point.

Select one of the following options for Match Approval Level:

Two–Way: Purchase order and invoice quantities must match within tolerance before the

corresponding invoice can be paid.

Three–Way: Purchase order, receipt, and invoice quantities must match within tolerance

before the corresponding invoice can be paid.

Four–Way: Purchase order, receipt, accepted, and invoice quantities must match within

tolerance before the corresponding invoice can be paid.

Required Matches 2_Way_PO 3_Way_PO 4_Way_PO

Ordered Quantity Yes Yes Yes

Receipt Quantity Yes Yes Yes

Receiving Quantity - Yes Yes

Accepted Quantity - - Yes

In PO_Line_Locations table using below conditions we can find 2-way, 3-way & 4-way PO’s

Inspection_Req_Flag

Receipt_Req_Flag

2 Way N N3 Way N Y4 Way Y Y

Underlying Tables

1) PO_HEADERS_ALL

This table stores header information of a Purchasing Document. You need one row for each

document you create.

Important columns of this table: PO_HEADER_ID, SEGMENT1, TYPE_LOOKUP_CODE,

VENDOR_ID, VENDOR_SITE_ID, CLOSED_CODE

PO_HEADER_ID is a unique system generated primary key and is invisible to the users.

SEGMENT1 is the document number

You can uniquely identify a row in PO_HEADERS_ALL using ORG_ID, SEGMENT1, and

TYPE_LOOKUP_CODE, or using PO_HEADER_ID.

2) PO_LINES_ALL

This table stores the line information of a Purchasing Document.

Important columns of this table:

PO_LINE_ID:                       Unique identifier of the Document Line

PO_HEADER_ID:               Unique identifier of the Document Header (with reference to

PO_HEADERS_ALL, PO_LINE_ID)

LINE_TYPE_ID:                 Unique identifier of Line_Type (with reference to PO_HEADERS_ALL,

PO_LINE_ID and PO_HEADER_ID)

LINE_NUMBER:                 Line Number

ITEM_ID:                             Unique Item Identifier

ORG_ID:                              Unique Identifier of the Operating Unit

CLOSED_CODE:                 Status of the Document

3) PO_LINE_LOCATION_ALL

This table contains the information related to purchase order shipment schedules and

blanket agreement price breaks. You need one row for each schedule or price break you

attach to a document line.

The following are the important columns of this table:

LINE_LOCATION_ID:                  Unique Identifier of Document shipment schedule

PO_HEADER_ID:                         Unique Identifier of Document header. (with reference to

PO_HEADERS_ALL.po_header_id.)

PO_LINE_ID:                                Unique Identifier of Document line (with reference to

PO_LINES_ALL.po_line_id)

QUANTITY:                                    Quantity ordered for Purchase Orders, RFQs and

Quotations

QUANTITY_RECEIVED:                Quantity received until today

QUANTITY_ACCEPTED:               Quantity accepted after inspection

QUANTITY_REJECTED:               Quantity rejected after inspection

QUANTITY_BILLED:                     Quantity invoiced by Oracle Payables

QUANTITY_CANCELLED:             Quantity cancelled

TAXABLE_FLAG:                           indicates whether the shipment is taxable

ORG_ID:                                        Operating unit unique identifier

SHIP_TO_ORGANIZATION_ID:     Unique identifier of Ship-to organization

4) PO_DISTRIBUTIONS_ALL

This table contains the information related to accounting distribution of a purchase order

shipment line. You need one row for each distribution line you attach to a purchase order

shipment.

Important columns of this table:

PO_DISTRIBUTION_ID:               This is the primary key for this table. It is a unique Document

Distribution identifier.

PO_HEADER_ID, PO_LINE_ID

LINE_LOCATION_ID:                  Unique Identifier of the Document Shipment Schedule (with

reference to PO_LINE_LOCATIONS_ALL, LINE_LOCATION_ID)

CODE_COMBINATION_ID:        Unique Identifier of General Ledger Charge Account (with

reference to GL_CODE_COMBINATIONS.CODE_COMBINATION_ID)

REQ_DISTRIBUTION_ID:            Unique Identifier of a Requisition distribution (with Reference

to PO_REQ_DISTRIBUTIONS_ALL.DISTRIBUTION_ID)

Exercises:1. Write a Query to get the requester name , item, requisition

number ,amount and Operating Unit in a standard Oracle BI Apps Module for a particular purchase order request whose requisition has been approved.

Soln. select ou.name AS OU,RHA.SEGMENT1 AS REQ#,PAP.full_name AS REQUESTER,MSB.SEGMENT1 AS ITEM,RLA.UNIT_PRICE * RLA.QUANTITY AS AMOUNT from apps.PO_REQUISITION_LINES_ALL RLA ,apps.hr_all_organization_units OU,apps.PO_REQUISITION_HEADERS_ALL RHA,per_all_people_f PAP,apps.mtl_system_items_b MSB where OU.type='OU' and RLA.org_id=OU.organization_id AND RHA.REQUISITION_HEADER_ID = RLA.REQUISITION_HEADER_ID and RLA.TO_PERSON_ID=PAP.person_id and RLA.ITEM_ID=MSB.INVENTORY_ITEM_ID AND rha.AUTHORIZATION_STATUS='APPROVED';Notes: We have joined REQUISITION_HEADERS_ALL and REQUISITION_LINES_ALL by REQUISITION_HEADER_IDs. Item name is from the table mtl_system_items_b.

Requester full name is from the table per_all_people_f. OU name is from hr_all_organization.

2. Write a query to get the number of requisitions in buyers workbench.

Soln. select count(RHA.segment1) from apps.PO_REQUISITION_HEADERS_ALL RHA,apps.PO_REQUISITION_LINES_ALL RLA where RHA.REQUISITION_HEADER_ID = RLA.REQUISITION_HEADER_ID and RLA.REQS_IN_POOL_FLAG='Y'.

Notes: We have joined REQUISITION_HEADERS_ALL and REQUISITION_LINES_ALL by REQUISITION_HEADER_IDs. REQS_IN_POOL_FLAG has been checked.

3. Write a query to get operating unit name, requisition number, item name, requisition line number, buyer name and purchase order

Soln. select ou.name AS OPERATING_UNIT,RHA.SEGMENT1 AS REQ#,MSB.SEGMENT1 AS ITEM,RLA.LINE_NUM AS REQ_LINE#,PAP.full_name AS BUYER,POH.SEGMENT1 AS PO# from apps.PO_REQUISITION_LINES_ALL RLA ,apps.hr_all_organization_units OU,apps.PO_REQUISITION_HEADERS_ALL RHA,apps.mtl_system_items_b MSB ,apps.PO_AGENTS PA,APPS.PO_LINE_LOCATIONS_ALL PLLA,APPS.per_all_people_f PAP,APPS.PO_HEADERS_ALL POH where OU.type='OU' and RLA.org_id=OU.organization_id AND RHA.REQUISITION_HEADER_ID = RLA.REQUISITION_HEADER_ID and RLA.ITEM_ID=MSB.INVENTORY_ITEM_ID AND RLA.TO_PERSON_ID=PAP.person_id and POH.AGENT_ID=PA agent_id and RLA.LINE_LOCATION_ID=PLLA.LINE_LOCATION_ID AND PLLA.po_header_id = POH.po_header_id

Notes: To join purchase order requision and a purchase order we have used LINE_LOCATION_IDs of PO_LINE_LOCATIONS_ALL and PO_REQUISITION_LINES_ALL. Then we have joined PO_HEADERS_ALL and PO_LINE_LOCATIONS_ALL by header_ids.

Overview of Procurement and Spend Analytics:

Oracle Procurement and Spend Analytics allows companies to more effectively manage their expenditures and improve business performance byProviding timely direct and indirect spending data to all departments. Enhance Insight into Supplier Performance—you can monitor price, delivery, and product quality to determine best - and worst - performing suppliers. Improve contract usage and compliance.Identifying cost savings across business units, geographic locations, products, and procurement organizations.Improving performance by identifying suppliers that price inconsistently or do not adhere to price schedulesControl Employee Spend —Understand how the money related to travel and expenses is being spent by gaining a complete picture of Employee ExpensesWith complete, end-to-end insight into spend patterns and supplier performance, organizations can significantly reduce costs, enhance profitability, increase customer satisfaction, and gain competitive advantage.In Procurement and Spend we have the following Subject Areas:

Procure to Pay: This is a summary Subject Area that provides the ability to do comparative analysis and report on requested spend, committed spend and actual spend and receipts across business units, buying locations, suppliers, products, item categories and associated hierarchies for both direct and indirect spend (indirect spend being MRO and employee expenses) in detail to allow complete visibility of spending across your organization.

Purchase Requisitions: This is a detailed Subject Area that provides the ability to report on requested spend and purchase requisitions (including cyclic requisitions) of the suppliers of an organization across suppliers, company, products, item categories and associated hierarchies at purchase requisition line level.

Purchase Requisition Status: This is a summary Subject Area that provides the ability to report on requisition status along the approval cycle of purchase requisitions of the suppliers of an organization. This Subject Area is only populated by the Universal adapter.

Purchase Orders: This is a detailed Subject Area that combines the information from Purchase Order Costs and Purchase Schedules with the ability to report on committed spend, contract compliance and Purchase orders of the suppliers of an organization across suppliers, company, products, item categories and associated hierarchies at purchase order line level.

Purchase Cycle Lines: This is a summary Subject Area that provides the ability to report cycle time performance, such as requisition to purchase order lead time, purchase order to receipt lead time, P2P lead time of the suppliers of an organization.

Purchase Receipts: This is a detailed Subject Area that provides the ability to report on actual spend and purchase receipts of the suppliers of an organization across suppliers, company, location, products, item categories and associated hierarchies at purchase receipt line level, including reporting based on receiving time.

Employee Expenses: This is a detailed Subject Area that provides the ability to report on employee spend of an organization across employees, company, cost center and associated hierarchies, including Approvers and cycle time measurements related to Approval, and Employee Expenses by various expense types. This Subject Area is only applicable for Oracle EBS 11.5.10 (family Pack M) and R12, PeopleSoft 8.9 and 9.0, and the Universal adapter.

Invoice Lines: This is a detailed Subject Area that provides the ability to report on total spend of an organization across suppliers, products, item categories, business units, cost centers, buying locations, supplier locations and associated hierarchy. In addition, this Subject Area also provides detailed information at invoice distribution level.

Supplier Performance: The Suppliers functional area (available with Supplier Performance Analytics) contains targeted reports and metrics that allow you to analyze the timeliness, reliability, cost, and quality of goods provided by your suppliers. It helps you to understand how well suppliers are contributing to success of your organization, and to evaluate the price, quality, and delivery timing in procuring materials.

Supplier AP Transactions: This is a summary Subject Area (available with Supplier Performance Analytics) that provides the ability to analyze payment performance and payment due analysis of the suppliers of an organization across suppliers, company, location, products, commodities and associated hierarchies. In addition to monitoring supplier performance, it is important to monitor organization's performance of making on

time payments. This will enables organizations to maintain better relationships with their best suppliers.

Purchase Requisitions Subject Area:

W_PURCH_RQSTN_LINE_F is the warehouse fact table which collects the Requisition related information, the grain of this table is at Requisition line level.

Few Requisition measures:

Measure Descriptions

# of Requisitions No of Requisitions

Approval Cycle TimeTime taken from Requisition Submission to Requisition Approval

Unapproved Requisitions Lines No of Requisitions which are not approved

Unapproved Requisitions Amount Total Requisition Amount which are unapproved

Unprocessed Requisitions AmountTotal Requisition Amount for Requsitions which have PO not approved.

Unprocessed Requisition Lines - UrgentRequisition for which PO is not approved and Urgent (PO_REQUISITION_LINES_ALL.URGENT_FLAG='Y'

Unprocessed Requisition Lines No of Requisitions for which PO's are not approved.

Unprocessed Lines Pending Sourcing No of Requisitions for which sourcing is not completed.

Unprocessed Lines Pending PO ApprovalNo of Requisitions which have PO in Pending Approval status

Unprocessed Lines Pending Buyers Workbench

No of approved requisitions for which reqs_in_pool_flag='Y', once requisition is approved they will show in Buyer Work bench.

Unprocessed Lines Pending Buyer Submission for Approval

No Of Requisitions for which buyer created the PO's but not submitted for approval

Unprocessed Amount Pending SourcingTotal Requisition amount for which sourcing is not completed.

Unprocessed Amount Pending PO Approval

Total Requisition amount which have PO's in Pending Approval Status

Unprocessed Amount Pending Buyers Workbench

Total approved requisition Amount for which reqs_in_pool_flag='Y', once requisition is approved they will show in Buyer Work bench.

Unprocessed Amount Pending Buyer Submission for Approval

Total Requisition amount for which buyer created the PO's but not submitted for approval

Unfulfilled Requisitions Amount

Unprocessed Requisition Amount+ Processed Requistion Amount(considers only Requisitions for which PO's are approved but not received or invoiced).

Unfulfilled Requisition Lines

Unprocessed Requisition Lines+ Processed Requistion Lines (considers only Requisitions for which PO's are approved but not received or invoiced).

Processed Requisition Lines No of Requisition lines for which PO's are approved.

Processed Amount Total Requisition Amount for which PO's are approved.

Processed Requisition Lines Past Expected Date

No of Requisition lines for which PO's are approved but due date is past the current date.

Fulfilled Lines

Fulfilled Requisitions lines means : Requisition lines which have a 2 PO invoiced + Requisition Lines having 3 way PO received+Requisition lines having 4 way PO Received or Received+Invoiced.