Oracle Purchasing allows requisitions, purchase orders, quotations, and receipts etc to be

processed and integrated with modules such as General Ledger, Inventory, Order
Management etc. The Oracle Purchasing design consists of various technical components
like interfaces, workflows, profile options, tables etc which are summarized in this
article.
Main Business Components in Oracle Purchasing are
Employee/Buyers
Vendor/Suppliers
Requisitions
Purchase Orders
Receipts
Employees
You must to be setup as an employee in order to create a requisition or a PO. If Oracle
HR is installed then you have to use the form defined in Oracle HRMS to define an
employee. If Oracle HR is not installed then you can use a form under Setup->Personnel>Employees to setup employees.
Main tables are HR_EMPLOYEES, PER_PEOPLE_F
Important Note: The view HR_EMPLOYEES_CURRENT_V gives one record per active
employee. PER_PEOPLE_F/PER_ALL_PEOPLE_F store multiple records per employee
with specific start and end dates
Vendors
PO_VENDORS, PO_VENDOR_SITES_ALL and PO_VENDOR_CONTACTS are the
main tables for this entity. Vendors are global i.e. a vendor, once defined, can be used
across operating units (OU). Vendor sites are OU specific. Most of the PO tables store the
VENDOR_ID and VENDOR_SITE_ID columns. VENDOR_SITE_ID is unique (not
unique within a VENDOR_ID) in 11i. It used to be unique for a vendor until
11.0.PO_VENDORS
PO_VENDORS stores information about your suppliers. You need one row for each
supplier you define. Each row includes the supplier name as well as purchasing,
receiving, payment, accounting, tax, classification, and general information.
Oracle Purchasing uses this information to determine active suppliers. VENDOR_ID is
the unique systemgenerated receipt header number invisible to the user.

Page 1 of 21

SEGMENT1 is the systemgenerated or manually assigned number you use to identify

the supplier in forms and reports. Oracle Purchasing generates SEGMENT1 using the
PO_UNIQUE_IDENTIFIER_CONTROL table if you choose to let Oracle Purchasing
generate supplier numbers for you.
This table is one of three tables that store supplier information. PO_VENDORS
corresponds to the Suppliers window.
PO_VENDOR_SITES_ALL
PO_VENDOR_SITES_ALL stores information about your supplier sites. You need a row
for each supplier site you define. Each row includes the site address, supplier reference,
purchasing, payment, bank, and general information. Oracle Purchasing uses this
information to store supplier address information.
This table is one of three tables that store supplier information.
PO_VENDOR_SITES_ALL corresponds to the Sites region of the Suppliers window.

PO_VENDOR_CONTACTS
PO_VENDOR_CONTACTS stores information about contacts for a supplier site. You
need one row for each supplier contact you define.
Each row includes the contact name and site.
This table is one of three tables that store supplier information.
PO_VENDOR_CONTACTS corresponds to the Contacts region of the Supplier Sites
window
Requisition
This entity is the starting point of data flow in the PO module. Requisitions can be
created by various means Enter Reqs form, Requisition Interface tables or using Self
Service Purchasing.
All requisitions need to be approved before being considered for future processing. An
unapproved requisition has a value of Incomplete for the column
AUTHORIZATION_STATUS in the table PO_REQUISITION_HEADERS. After the
requisition is completed it should be submitted for Approval. Approval is a separate piece
of code that is reused in both Reqs as well as PO approval. It is a combination of
Workflow, PL/SQL and Pro*C code.

Page 2 of 21

There are 3 main tables for Reqs:

PO_REQUISITION_HEADERS:
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 systemgenerated 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.
PO_REQUISITION_HEADERS_ALL corresponds to the Header region of the
Requisitions window.
SEGMENT1 provides unique values for each row in the table in addition to
REQUISITION_HEADER_ID.

PO_REQUISITION_LINES:
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, deliverto location, item quantities, units, prices, requestor, notes, and suggested
supplier information for the requisition line.
LINE_LOCATION_ID identifies the purchase order shipment line on which you placed
the requisition. LINE_LOCATION_ID is null if you have not placed the requisition line
on a purchase order.
BLANKET_PO_HEADER_ID and BLANKET_PO_LINE_NUM store the suggested
blanket purchase agreement or catalog quotation line information for the requisition line.
PARENT_REQ_LINE_ID contains the REQUISITION_LINE_ID from the original
requisition line if you exploded or multi-sourced this requisition line.
This table corresponds to the Lines region of the Requisitions window.
PO_REQ_DISTRIBUTIONS:
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 Flexfield ID and requisition line quantity.
PO_REQ_DISTRIBUTIONS_ALL is one of three tables storing your requisition
information. This table corresponds to the requisition Distributions window, accessible
through the Requisitions window
Page 3 of 21

Purchase Order
This is the pivotal entity of Oracle Purchasing. All other entities function for or because
of this entity. There are four main tables for this entity:
PO_HEADERS_ALL:
There are six types of documents that use PO_HEADERS_ALL:
RFQs
Quotations
Standard purchase orders
Planned purchase orders
Blanket purchase orders
Contracts
Each row contains buyer information, supplier information, brief notes, foreign currency
information, terms and conditions information, and the status of the document. Oracle
Purchasing uses this information to record information that is related to a complete
document. PO_HEADER_ID is the unique systemgenerated primary key and is
invisible to the user. SEGMENT1 is the systemassigned number you use to identify the
document in forms and reports. Oracle Purchasing generates SEGMENT1 using the
PO_UNIQUE_IDENTIFIER_CONT_ALL table if you choose to let Oracle Purchasing
generate document numbers for you. SEGMENT1 is not unique for the entire table.
Different document types can share the same numbers. You can uniquely identify a row
in PO_HEADERS_ALL using SEGMENT1 and TYPE_LOOKUP_CODE or using
PO_HEADER_ID.
If APPROVED_FLAG is Y, the purchase order is approved. If your document type is a
blanket purchase order, contract purchase order, RFQ, or quotation, Oracle Purchasing
uses START_DATE and END_DATE to store the valid date range for the document.
Oracle Purchasing only uses BLANKET_TOTAL_AMOUNT for blanket
PO_LINES_ALL:
Is a detail of headers table.
Each row includes the line number, the item number and category, unit, price, tax
information, matching information, and quantity ordered for the line. Oracle Purchasing
uses this information to record and update item and price information for purchase orders,
quotations, and RFQs. PO_LINE_ID is the unique systemgenerated line number
invisible to the user. LINE_NUM is the number of the line on the purchase order.

Page 4 of 21

Oracle Purchasing uses CONTRACT_NUM to reference a contract purchase order from

a standard purchase order line. Oracle Purchasing uses
ALLOW_PRICE_OVERRIDE_FLAG, COMMITTED_AMOUNT,
QUANTITY_COMMITTED, MIN_RELEASE_AMOUNT only for blanket and planned
purchase order lines.
The QUANTITY field stores the total quantity of all purchase order shipment lines
(found in PO_LINE_LOCATIONS_ALL).
PO_LINE_LOCATIONS_ALL:
Also known as Shipments is a detail of lines. PO_LINE_LOCATIONS_ALL contains
information about 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.
Each row includes the location, quantity, and dates for each shipment schedule. Oracle
Purchasing uses this information to record delivery schedule information for purchase
orders, and price break information for blanket purchase orders, quotations and RFQs.
PO_RELEASE_ID applies only to blanket purchase order release shipments.
PO_RELEASE_ID identifies the release on which you placed this shipment.
SOURCE_SHIPMENT_ID applies only to planned purchase order release shipments. It
identifies the planned purchase order shipment you chose to release from.
PRICE_OVERRIDE always equals the purchase order line price for standard purchase
order shipments. For blanket and planned purchase orders, PRICE_OVERRIDE depends
on the values of the ALLOW_PRICE_OVERRIDE_FLAG and
NOT_TO_EXCEED_PRICE in the corresponding row in PO_LINES_ALL:
If ALLOW_PRICE_OVERRIDE_FLAG is N, then PRICE_OVERRIDE equals
UNIT_PRICE in PO_LINES_ALL.
If ALLOW_PRICE_OVERRIDE_FLAG is Y, then PRICE_OVERRIDE can take any
value that is smaller than NOT_TO_EXCEED_PRICE in PO_LINES_ALL.
The QUANTITY field corresponds to the total quantity ordered on all purchase order
distribution lines (found in PO_DISTRIBUTIONS_ALL).

PO_DISTRIBUTIONS_ALL:
PO_DISTRIBUTIONS_ALL contains accounting distribution information for a purchase
order shipment line. You need one row for each distribution line you attach to a purchase
order shipment.
Each row includes the destination type, requestor ID, quantity ordered and deliverto
location for the distribution. Oracle Purchasing uses this information to record accounting
and requisition information for purchase orders and releases.
PO_DISTRIBUTIONS_ALL is one of five tables storing purchase order and release
information.

Page 5 of 21

Some columns in PO_DISTRIBUTIONS_ALL contain information only if certain

conditions exist:
If you autocreate this accounting distribution from a requisition,
REQ_DISTRIBUTION_ID corresponds to the ID of the requisition distribution you copy
on the purchase order.
If you use a foreign currency on your purchase order, Oracle Purchasing stores currency
conversion information in RATE and RATE_DATE.
If you use encumbrance, GL_ENCUMBERED_DATE and
GL_ENCUMBERED_PERIOD_NAME contain encumbrance information Oracle
Purchasing uses to create journal entries in Oracle General Ledger.
If you do not autocreate the purchase order from online requisitions,
REQ_LINE_REFERENCE_NUM and REQ_HEADER_REFERENCE_NUM contain
the requisition number and requisition line number of the corresponding paper
requisition. These two columns are not foreign keys to another table.
If the distribution corresponds to a blanket purchase order release, PO_RELEASE_ID
identifies this release.
If SOURCE_DISTRIBUTION_ID has a value, the distribution is part of a planned
purchase order release.
Reqs can be converted to Purchase Orders using either the Autocreate form or Create PO
workflow. If certain conditions are satisfied then multiple req lines are converted to a
single PO line or a single PO shipment.
Receipt
There are two receipt source types, Supplier (PO based) and Internal Order (Internal
Requisitions and Inter-org transfers) that you need to use when receiving against different
source document types. You use a receipt source type of Supplier when receiving items
that you ordered from an external supplier using a purchase order.
When you receive items that are part of an interorganization transfer, or when receiving
items that you request from your inventory using an internal requisition, the receipt type
would be Internal Order. The Internal Order receipt source type populates the
ORGANIZATION_ID column.
There are three main tables in receiving:

RCV_SHIPMENT_HEADERS
RCV_SHIPMENT_HEADERS stores common information about the source of your
receipts or expected receipts. You group your receipts by the source type and the source
of the receipt. Oracle Purchasing does not allow you to group receipts from different
sources under one receipt header.

Page 6 of 21

Oracle Purchasing creates a receipt header when you are entering your receipts or when
you perform interorganization transfers using Oracle Inventory. When Oracle Inventory
creates a receipt header for an intransit shipment, the receipt number is not populated
until you receive the shipment.
RCV_SHIPMENT_LINES
RCV_SHIPMENT_LINES stores information about items that have been shipped and/or
received from a specific receipt source. RCV_SHIPMENT_LINES also stores
information about the default destination for intransit shipments.
RCV_TRANSACTIONS
RCV_TRANSACTIONS stores historical information about receiving transactions that
you have performed. When you enter a receiving transaction and the receiving transaction
processor processes your transaction, the transaction is recorded in this table.
Once a row has been inserted into this table, it will never be updated.
When you correct a transaction, the net transaction quantity is maintained in
RCV_SUPPLY. The original transaction quantity does not get updated. You can only
delete rows from this table using the Purge feature of Oracle Purchasing.
Main Interfaces
You could import requisitions, Purchase Orders and Receipts using the open interfaces
for the respective entities. The Manufacturing APIs and Open Interfaces manual is a
comprehensive guide to these interfaces.
Requisitions Interface
See ReqImport process below.
Purchasing Documents Open Interface (PDOI)
You can automatically import and update price/sales catalog information and request for
quotation (RFQ) responses from suppliers through the Purchasing Documents Open
Interface. You can also import standard purchase orders (for example, from a legacy
system) through the Purchasing Documents Open Interface.
The Purchasing Documents Open Interface uses Application Program Interfaces (APIs) to
process the data in the Oracle Applications interface tables to ensure that it is valid before
importing it into Oracle Purchasing. After validating the price/sales catalog information
or RFQ responses, the Purchasing Documents Open Interface program converts the
information, including price break information, in the interface tables into blanket
purchase agreements, or catalog quotations in Purchasing. For standard purchase orders,
the Purchasing Documents Open Interface also validates the header, line, shipment, and
distribution information before importing the purchase orders into Purchasing.
You can choose whether to import the data as standard purchase orders, blanket purchase
agreements, or catalog quotations. You can also choose to update your item master and,
for blanket purchase agreements and quotations, apply sourcing rules and release

Page 7 of 21

generation methods to the imported item. Blanket purchase agreements and quotations
can also be replaced with the latest price/sales catalog information when your supplier
sends a replacement catalog, or updated when the supplier sends an updated catalog.
Standard purchase orders can only be imported as new documents.
One way to import the blanket purchase agreements and catalog quotations is through
Electronic Data Interchange (EDI). The Purchasing Documents Open Interface supports
the EDI transmissions of the price/sales catalogs (ANSI X12 832 or EDIFACT PRICAT)
and responses to RFQs (ANSI X12 843 or EDIFACT QUOTES). Standard purchase
orders cannot be transmitted through EDI. You can import these into the interface tables
using a program that you write.
Receiving Open Interface
Within the Receiving Open Interface, receipt data is validated for compatibility with
Purchasing. There are two Receiving Open Interface tables:
RCV_HEADERS_INTERFACE
RCV_TRANSACTIONS_INTERFACE
Receipt data that is entered through the Receipts window in Purchasing is derived,
defaulted, and validated by the Receipts window. Most receipt data that is imported
through the Receiving Open Interface is derived, defaulted, and validated by the
receiving transaction pre-processor.
The pre-processor is a program that the Receiving Transaction Processor initiates for data
entered in the Receiving Open Interface. The pre-processor simulates, in Batch mode,
what the receiving windows do when you save a transaction.
After performing header- and line-level validation, the pre-processor checks the profile
option RCV: Fail All ASN Lines if One Line Fails. If the profile option is set to Yes and
any line failed validation, the pre-processor fails the entire transaction. If the profile
option is set to No (and TEST_FLAG is not Y), the Receiving Transaction Processor
takes over and, for all successfully processed records, performs the same steps that occur
when you normally save receipt information in Purchasing:
Populates the RCV_SHIPMENT_HEADERS table in Purchasing with the
receipt header information.
Populates the RCV_SHIPMENT_LINES table in Purchasing for each receipt
header entry in the RCV_SHIPMENT_HEADERS table in Purchasing.
Populates the RCV_TRANSACTIONS table in Purchasing for each row in the
RCV_SHIPMENT_HEADERS and RCV_SHIPMENT_LINES table if the
column AUTO_TRANSACT_CODE in the
RCV_TRANSACTIONS_INTERFACE table contains a value of RECEIVE or
DELIVER.
Updates supply for accepted line items in the tables MTL_SUPPLY and
RCV_SUPPLY.
Calls the Oracle Inventory module for processing DELIVER transactions.
Calls the Oracle General Ledger module for processing financial transactions,
such as receipt-based accruals.

Page 8 of 21

 Updates the corresponding purchase orders with the final received and delivered
quantities.

Major Processes
A few important processes are described below. There are several other equally important
processes in Oracle Purchasing. The users guide and Oracle Manufacturing APIs and
Open Interfaces manual is a good source for information on them.
ReqImport
Overview
This interface lets you integrate Oracle Purchasing quickly with new or existing
applications such as material requirements planning, inventory management, and
production control systems. Purchasing automatically validates your data and imports
your requisitions. You can import requisitions as often as you want. Then, you can review
these requisitions, approve or reserve funds for them if necessary, and place them on
purchase orders or internal sales orders.
Flow
You must write the program that inserts a single row into the
PO_REQUISITIONS_INTERFACE_ALL and/or the
PO_REQ_DIST_INTERFACE_ALL table for each requisition line that you want to
import. Then you use the Submit Request window to launch the Requisition Import
program for any set of rows.
You identify the set of rows you want to import by setting the
INTERFACE_SOURCE_CODE and BATCH_ID columns appropriately in the
PO_REQUISITIONS_INTERFACE_ALL table. You then pass these values as
parameters to the Requisition Import program. If you do not specify any values for these
parameters, the program imports all therequisition lines in the
PO_REQUISITIONS_INTERFACE_ALL table. You also specify the requisition
grouping and numbering criteria as parameters to the Requisition Import program.
Each run of the Requisition Import program picks up distribution information from either
the PO_REQUISITIONS_INTERFACE_ALL or the
PO_REQ_DIST_INTERFACE_ALL table. The PO_REQ_DIST_INTERFACE_ALL
table was used in Release 11, for Self-Service Purchasing (known then as Web
Requisitions). In Release 11i, you should use the PO_REQ_DIST_INTERFACE_ALL
table to create multiple distributions only for requisitions created in non-Oracle systems
that use multiple distributions. As long as the Multiple Distributions field in the
Requisition Import program is No (or blank), Requisition Import looks for distribution
information in the PO_REQUISITIONS_INTERFACE_ALL table.
The Requisition Import program operates in three phases. In the first phase, the program
validates your data and derives or defaults additional information. The program generates
Page 9 of 21

an error message for every validation that fails and creates a row in the
PO_INTERFACE_ERRORS table with detailed information about each error.
In the second phase, the program groups and numbers the validated requisition lines
according to the following criteria. If you specify a value in the
REQ_NUMBER_SEGMENT1 column of the PO_REQUISITIONS_INTERFACE_ALL
table, all lines with the same value for this column are grouped together under a
requisition header. If you provide a value in the GROUP_CODE column, all lines with
the same value in this column are grouped together under a requisition header.
If you do not provide values in either of these columns, the Requisition Import program
uses the Group By parameter to group lines together. If you do not provide a value for
this parameter, the program uses the default Group By that you set up to group requisition
lines. You can group requisition lines in one of the following ways that the Requisition
Import program supports by:
BUYER
CATEGORY
LOCATION
VENDOR
ITEM
ALL (all requisition lines grouped under one header)
If you provide a value in the REQ_NUMBER_SEGMENT1 column of the
PO_REQUISITIONS_INTERFACE_ALL table, this value becomes the requisition
number. If not, the Requisition Import program uses either the Last Requisition Number
parameter if specified or the next unique number stored in the
PO_UNIQUE_IDENTIFIER_CONTROL table, adds 1 to this number, and starts
numbering requisitions. If any of the requisition numbers generated already exists, the
program loops until it finds a unique number. For every line that is successfully imported,
a default distribution is created with the account information that you specify. (You
specify account information in any of the following columns in either the
PO_REQUISITIONS_INTERFACE_ALL or the PO_REQ_DIST_INTERFACE_ALL
table: CHARGE_ACCOUNT_ID, ACCRUAL_ACCOUNT_ID,
VARIANCE_ACCOUNT_ID, BUDGET_ACCOUNT_ID, or any of the
CHARGE_ACCOUNT_SEGMENT columns.) Requisition supply is also created for
every approved requisition that is successfully imported.
In the third phase, the program deletes all the successfully processed rows in the interface
tables, and creates a report which lists the number of interface records that were
successfully imported and the number that were not imported. This report can be viewed
by choosing View Output for the Requisition Import concurrent
Request ID in the Requests window. You can launch the Requisition Import Exceptions
Report to view the rows that were not imported by the Requisition Import program along
with the failure reason(s) for each row.

Page 10 of 21

PO Create Documents Workflow

Overview
Purchasing integrates with Oracle Workflow technology to create standard purchase
orders or blanket releases automatically from approved requisition lines. The workflow
for creating purchasing documents automatically is called PO Create Documents.
In the Workflow Builder, PO Create Documents consists of several processes. Each of
these processes is viewable in the Workflow Builder as a diagram whose objects and
properties you can modify. Each workflow process consists of individual functions.
For each document that is created successfully by the PO Create Documents workflow,
the PO Approval workflow is called to approve the document if you have allowed
automatic approval.
Flow
The PO Create Documents workflow is initiated at the end of the requisition approval
workflow for approved requisition lines. The workflow begins automatic document
creation if youve kept the item attribute Is Automatic Creation Allowed? set to Y for Yes,
if source documents are associated with the requisition lines, and you have properly set
up sourcing rules. If the source document associated with the requisition line is a
quotation, a standard purchase order is created. If the source document is a blanket
purchase agreement, a release is created.
PO Approval Workflow
Overview
Whenever you submit a purchase order or release for approval or take an action in the
Notifications Summary window, Purchasing uses Oracle Workflow technology in the
background to handle the approval process. Workflow uses the approval controls and
hierarchies you define according to the setup steps in the section to route documents for
approval. You can use the Workflow Builder interface to modify your approval process.
The purchase order approval workflow consists of processes, which are viewable in the
Workflow Builder as a diagram, some of whose objects and properties you can modify.
Each workflow process, in turn, consists of individual function activities.
The PO Approval workflow is initiated at the following points in Purchasing:
When you choose Submit for Approval (and then choose OK) in the Approve
Document window. See: Submitting a Document for Approval
When you respond to a reminder in the Notifications Summary window reminding
you to submit a document for approval that has not yet been submitted.
Flow

Page 11 of 21

The purchase order approval process is associated with an item type called PO Approval.
This item type identifies all purchase order and release approval workflow processes
available.
Refer to the Oracle Purchasing Users guide for a comprehensive explanation of the flow.

Other important tables in Oracle Purchasing

PO_SYSTEM_PARAMETERS_ALL
PO_SYSTEM_PARAMETERS_ALL stores default, control, and option information you
provide to customize Oracle Purchasing to your companys needs.
PO_SYSTEM_PARAMETERS_ALL corresponds to the Purchasing Options window.
This table has no primary key. The table should never have more than one row.
PO_UNIQUE_IDENTIFIER_CONT_ALL
PO_UNIQUE_IDENTIFIER_CONT_ALL stores information about the current, highest,
systemgenerated numbers for the Oracle Purchasing tables that require special
sequencing. You need one row for each sequentially systemgenerated number for each
organization. The table includes rows for each of the following: purchase orders,
requisitions, receipts, suppliers, quotations, and requests for quotations (RFQs).
For each organization, there are four rows for each of the following entities:
PO_HEADERS_ALL, PO_REQUISITION_HEADERS_ALL, PO_HEADERS_RFQ
and PO_HEADERS_QUOTE. There are two rows corresponding to the entities
PO_VENDORS and RCV_SHIPMENT_HEADERS.
The information for the quotation and RFQ subentities is associated with the
PO_HEADERS_ALL table entity. TABLE_NAME values for quotations and RFQs are
PO_HEADERS_QUOTE and PO_HEADERS_RFQ respectively.
PO_LINE_TYPES_B
PO_LINE_TYPES_B contains information about the line types you use in your business.
You need each row for each line type you use. Oracle Purchasing uses this information to
provide default information when you create a document line using a line type. Oracle
Purchasing also uses this information to control how you enter information on your
document lines according to the line type you choose.
ORDER_TYPE_LOOKUP_CODE is AMOUNT for an amountbased line type or
QUANTITY for a quantitybased line type.
PO_DOCUMENT_TYPES_B

Page 12 of 21

PO_DOCUMENT_TYPES_ALL_B contains information about default, control, and

option information you provide to customize Oracle Purchasing document management
for your companys needs.
PO_DOCUMENT_TYPES_ALL_B corresponds to the Document Types window.
PO_ACTION_HISTORY
PO_ACTION_HISTORY contains information about the approval and control history of
your purchasing documents. There is one record in this table for each approval or control
action an employee takes on a purchase order, purchase agreement, release, or requisition.
Each row includes references to the document itself, the employee who acted on the
document, the date of the action, the type of action taken on the document, and a note
each employee can leave when taking an action on the document.
Oracle Purchasing uses this information to display history information about documents
and to forward documents in the approval process to the appropriate employee.

Important Profile Options in Oracle Purchasing

PO: AutoCreate GL Date Option
Indicates the date used on purchase orders generated by AutoCreate: The autocreate date
is used as the purchase order date. The GL date on the requisition distribution is used as
the purchase order date.
PO: Automatic Document Sourcing
Yes means that Purchasing automatically defaults source document and pricing
information for an item from the most recently created blanket purchase agreement or
quotation. No means that this source document information comes from the Approved
Supplier List window, where you must specify which source documents to use. Note that
if an item on a requisition is associated with both a blanket purchase agreement and a
quotation, Purchasing uses the blanket purchase agreement even if the quotation was
created more recently.
PO: Display the Autocreated Document
Yes or No indicates whether Purchasing opens the appropriate transaction window
(Purchase Orders window, RFQs window, or Sourcing negotiation page) and displays the
created line(s) when you autocreate a document.
PO: Enable Sql Trace for Receiving Processor
Yes means that when you run the Receiving Transaction Processor to import data from
another system using the Receiving Open Interface, the View Log screen displays the
receiving transaction preprocessors actions, including errors, as it processed the receipt
data from start to finish. (The profile option RCV: Processing Mode must also be set to

Page 13 of 21

Immediate or Batch for the Yes option to work.) Yes also generates a database trace file;
if you need help with an error that occurs while the
Receiving Transaction Processor runs, Oracle Support Services may ask you for this trace
file. This profile option should be set to Yes only while debugging the Receiving Open
Interface or for generating a trace file.
The Receiving Open Interface validates receipt transactions from other systems and uses
the Receiving Transaction Processor to import the validated data into Purchasing.
PO: Release During ReqImport
Yes or No indicates whether Purchasing can automatically create releases during the
Requisition Import process.
PO: Restrict Requisition line modify to quantity split
Yes or No indicates whether Purchasing restricts requisition line modify in AutoCreate to
only splitting the quantity of a line. No means that the standard AutoCreate requisition
line modify logic applies.
PO: Write Server Output to File
Yes or No indicates whether log details are written to a flat file rather than to the standard
concurrent manager details log viewable through the View Log button in the Submit
Request window when running the Purchasing Documents Open Interface program.
Yes means log details are written to a flat file. No means log details are written to the
concurrent manager log screen, which can cause overflow problems for large catalogs.
Leaving this profile option blank means log details are not written at all, which improves
performance.
RCV: Processing Mode
Indicates the processing mode used after you save your work for receiving transactions:
Batch

The transaction goes to the interface table, where it will be

picked up the next time the Receiving Transaction Processor
runs.

Immediate

The transaction goes to the interface table, and the Receiving

Transaction Processor is called for the group of transactions
that you entered since you last saved your work.

Online

The Receiving Transaction Processor is called directly.

RCV: Allow routing override

Yes or No indicates whether the destination type assigned during requisition or purchase
order entry can be overridden at receipt time.

Page 14 of 21

RCV: Debug Mode

If set to Yes, and RCV: Processing Mode set to Immediate or Batch, debug messages will
be printed to the concurrent log file.
RCV: Default Include Closed PO Option
If it is set to Yes, a search in the Enter Receipts window and the Receiving Transactions
window automatically select the Include Closed POs checkbox. Your search results will
then include closed orders.
The Receiving Open Interface (including ASN) will allow a receipt against orders with
the status of Closed for Receiving if this profile is set to Yes. Any setting other than Yes
prevents receiving against orders using the Receiving Open Interface with the status of
Closed for Receiving.

Basic Purchasing Setups

The purchasing user must be set as a buyer in Oracle applications. Before setting the user
as buyer he/she must be an employee in applications.
Employee Setup
Employee should be assigned the position and job. This is useful in PO approval
workflow.
The view used is per_people_v, per_people_address_v, per_people_assigment_v to store
the employee information.
Buyer Setup
Once the user is set as buyer then he/she can create/approve/print the purchase orders.
Whether the users can create/approve/print the purchase orders is decided by how the
document types are setup.
The table which stores the buyer is PO_AGENTS and the view used for the buyer name
and other details is PO_AGENTS_V.
The important columns PO_AGENTS_V
Sr.no Column Name
1
Agent_id
Page 15 of 21

Comments
Unique agent id

2
3
4
5
6

Agent_name
Location_id
Location_code
Start_date_active
End_date_active

Agent Name
Unique location id
Location code
Start date active
End date active

Document Types
Document types there are certain attributes needs to be set. They are explained below-:
1) Owner can approve: If we check this attribute then user can approve the documents
he has created. This field is not updatable when the document type is RFQ or Requisition.
2) Approver can modify: If we check this attribute then approver the contents of the
document. This is not applicable to RFQ and requisitions.
3) Can change forward to: This indicates test that the user can change the name of
the approver in the approval window.
4) Can change forward from: This indicates that the user can change the name of
the document creator. This is available only for document type requisition.
5) Can change approval hierarchy: Preparers and approvers can change the
approval hierarchy in the approval document window.
6) Disable: Check it to disable the Document type.
7) Access Level: How the users can access the document type.
a. Full: Full access to the user
b. Modify: Can modify the document type
c. View Only: Can only view the document type
8) Archive On: When the archival of document type will take place.
a. On approval: On approval of the document
b. On Printing: On printing of the document.
9) Approval workflow: Which workflow the purchasing will use to approve the
document type in question. One can define a custom workflow and also mention
the name of the workflow.

Page 16 of 21

10) Default Hierarchy: What hierarchy the approval process will follow is to be
mentioned here.

Table Used
The table where the information is stored is PO_DOCUMENT_TYPES_V

Supplier Setup
The table where the information is stored is PO_VENDORS
Sr.no
1
2
3
4
5

Column Name
Vendor_id
Vendor_name
Segment1
Start_date_active
End date active

Comments
Unique vendor id
Vendor or supplier name
Vendor Number
Start date active
End date active

Another important table associated with this screen is PO_VENDORS_SITES_ALL.

This stores the important information of vendor sites.
Sr.no
1
2
3

Column Name
Vendor_site_id
Vendor_id
Vendor_site_code

Comments
Unique vendor site Id
Unique vendor site id refers PO_VENDORS
Vendor site code

Purchase Orders
Creation Of Standard Purchase Orders
Creation of purchase orders has three parts. First is the header information second is
the line information and the third is the shipments and distributions information. This
applies for the standard purchase order.
Sr.no
1
2
3
4
5
6

Column Name
Po_header_id
Agent_id
Segment1
Revision_num
Vendor_id
Vendor_site_id

Page 17 of 21

Comments
Unique Po Header Id
Agent id refers PO_AGENTS_V
PO Number
Revision Number for PO
Unique vendor id refers PO_VENDOR_ID
Unique
vendor
site
id
refers

7
8
9

Vendor_contact_id
Ship_to_location_id
Bill_to_location_id

10
11

Currency_code
Authorization_status

12

Type_look_up_code

13

Org_id

PO_VENDOR_SITES_ALL
Vendor contact id
Where the material will be shipped by supplier
Where the Bill/Invoice will be sent by the
supplier
Currency code
Authorization
status
for
the
PO
Open/Closed/Approved/Incomplete
What
is
the
type
of
PO
Standard/Blanket/Planned
Operating Unit

The second type of information stored is line level information.

Its is stored in the table PO_LINES_ALL
Sr.no
1
2
3

Column Name
Po_line_id
Po_header_id
Line_type_id

4
5

Line_num
Item_id

Item_rev

7
8
9
10
11

Item_description
Quantity
Unit_price
List_price
Org_id

12
13

Promise_date
Need_by_date

Comments
Line identification number
PO header id refers PO_HEADERS_ALL
Line type_id such as Goods/Services/Expense
etc
Unique line num for each line item
Item
to
purchased
refers
MTL_SYSTEMS_ITEMS
Revision
of
the
item
refers
MTL_SYSTEM_ITEMS
Description of item
Quantity to be entered
Price of one unit
Unit price from price list
Operating unit from where purchasing will take
place
Promise date by supplier
Date by which the material is required

The third type of information is the shipment

The information is stored in PO_LINE_LOCATIONS_ALL
Sr.no Column Name
1
LINE_LOCATION_ID
2
PO_HEADER_ID

Page 18 of 21

Comments
Unique identifier LINE_LOCATION_ID
Refers PO_HEADERS_ALL

3
4
5
6
7

PO_LINE_ID
QUANTITY
SHIP_TO_LOCATION_ID
SHIPMENT_TYPE
ORG_ID

Refers PO_LINE_ALL
Quantity to be shipped
Unique Identifier for the quantity to be shipped
Price break, Blanket ,Standard
Operating Unit

The distribution information is stored in PO_DISTRIBUTIONS_ALL

Sr.no Column Name
1
Po_Distribution_Id
2
Po_Header_Id
3
4
5
6
7
8
9
10
11
12
13

Comments
Unique Distribution Id
PO Header Identification number referring
PO_HEADERS_ALL
Po_Line_Id
PO Line identification number referring
PO_LINES_ALL
Line_Location_Id
Refers PO_LINE_LOCATIONS_ALL
Set_Of_Books_Id
Set of Books
Code_Combination_Id
GL Code combination id for charge account
Quantity_Ordered
Quantity Ordered
Distribution_Num
Unique distribution number
Destinition_Type_Code
Destination type Code for e.g. Inventory
Destination_Organization_Id Destination organization id
Destination_Subinventory
Destination Sub-inventory
Org_Id
Operating unit
Po_Release_Id
PO Release identification number if the PO
type is blanket PO

Thus to summarize the information for Standard, Planned is stored in the following
tables.
1) PO_HEADERS_ALL
2) PO_LINES_ALL
3) PO_LINE_LOCATIONS_ALL
4) PO_DISTRIBUTIONS_ALL
Creation of Blanket Purchase Order
When the purchase order type information is of the type blanket then the header and
line level information is stored in same table as that of standard PO. For a blanket one
more transaction named a Release transaction is made. This release transaction then
creates the shipment information and the distribution information. Therefore for a
blanket transactions following tables are used.

Page 19 of 21

1) PO_HEADERS_ALL
2) PO_LINES_ALL
3) PO_RELEASE_ALL
4) PO_LINE_LOCATIONS_ALL
5) PO_DISTRIBUTIONS_ALL
Thus a blanket PO is same as Standard PO with the help of extra transaction call
Releases. The table for releases is PO_RELEASE_ALL
Sr.no
1
2
3
4
5
6

Column Name
PO_RELEASE_ID
PO_HEADER_ID
RELEASE_NUM
AGENT_ID
RELEASE_DATE
REVISION_NUM

7
8
9
10
11

APPROVED_FLAG
APPROVED_DATE
PRINT_COUNT
PRINT_DATE
AUTHORIZATION_STATUS

12

ORG_ID

Comments
PO Release identification Number
Refers PO_HEADERS_ALL
Unique release num
Buyer ID refers PO_AGENTS_V
The date on which release is created
Revision number is generated when any
changes are done to release information
Y if the release in question is approved
Date on release is approved
No of times the release is printed
Last printed date of the release
Different status of the releases such as
Open/Closed/Approved/Incomplete
Operating unit

Concept of Multi Organization in Purchasing

In Oracle purchasing can be done across multiple organizations also called as
operating units. So to accommodate this oracle has provided multi org views for the
base tables of purchasing. For instance the table PO_HEADERS_ALL stores the
header information of all the orgs. For using multi org view we need to set ORG_ID
context variable using the AOL built in package. The syntax is given below.
FND_CLIENT_INFO.SET_ORG_CONTEXT(<ORG_ID Value>)
Once this is set then one can get rows in from all multi org views. Table below
illustrates the base tables and there multi org views.
Base Table
PO_HEADERS_ALL
PO_LINES_ALL

Page 20 of 21

Multi Org View

PO_HEADERS
PO_LINES

PO_LINE_LOCATIONS_ALL
PO_RELEASES_ALL
PO_DISTRIBUTIONS_ALL
PO_VENDOR_SITES_ALL

Page 21 of 21

PO_LINE_LOCATIONS
PO_RELEASES
PO_DISTRIBUTIONS
PO_VENDOR_SITES