Procure to pay (P2P) cycle with tables

SUPPLY CHAIN MANAGEMENT

1. Supply Chain Management (SCM):- SCM is defined as combination of art and

o
o

o
o

science that goes into improving the way your company find the raw components that needs to
make a product or services and deliver it to customer.
A supply chain is product specific, not company specific
Supply chain management (SCM) is a systematic approach to manage the entire flow of
information, materials, and services from raw material suppliers through factories and
warehouses to the end customer.
Moreover, SCM involves the flows of material, information and finance in a network
consisting of customers, suppliers, manufacturers, and distributors.
We should be clear with Flow that SCM can manage :
The flow of actual materials, the top middle bars
From suppliers : flows of raw materials, intermediate products, finished
goods
Reverse material flows : returns, repairs, servicing, recycling, disposal
and the information flows
From suppliers : manufacturing capacity, delivery schedules, promotions
they have going
Reverse flows : sales, orders, inventory, quality, promotions
And finally, there are financial flows:
From suppliers: Credits, consignment, payment terms, invoice
Reverse Flows : payments, consignment
Supply Chain Management is the management of the entire value-added chain,
from the supplier to manufacturer right through to the retailer and the final customer.
SCM has three primary goals: Reduce inventory, increase the transaction speed
by exchanging data in real-time, and increase sales by implementing customer requirements
more efficiently
The need for SCM is because effective Supply Chain Mgt. is the next logical step
towards increased profits and market share.
Supply Chain Management (SCM) in line manager prospective is "let's-keepthings-moving-efficiently".

What is Oracle's SCM Solution for Customer

Oracle Supply Chain Management (SCM) basically integrates and automates all key supply
chain activities starting from design, planning, and procurement to manufacturing and
fulfillment. It depends upon how the company or Line managers planning to use these
application module in their business line. For better understanding from Product point, lets

understood

on

eight

key

areas

as

per

figure:

Here are the details with underline Product which is potentially used.
1. Develop: SCM start with developing new products where Product specifications are created.
Oracle Product Life cycle Management(PLM)
Oracle Advanced product Catalog (EGO )
2. Market: Marketing and Sales generates demand for the Product by publicizing its features
and how it would address customer priorities. In the process, Marketing also gets customer
feedback and communicates to Product development group. These are application potentially can
be used.
Telesales (AST)
Trade Management (OZF)
Incentive Compensation (CN)
Order Capture (ASO)
Partners Online (POL) *
* Oracle Partners Online (POL) is also known as Oracle Partners Online (PRM).
3. Plan: Planning is the strategic portion of SCM. You need a strategy for managing all the
resources that go toward meeting customer demand for your product or service.
Advanced Supply Chain Planning (MSC)
Global Order Promising (GOP)
4. Sell & Manage Orders: Maintain and manage the customer orders, order holds, notes and
release the orders to warehouse for fulfillment based on requested date, product availability and
customer credit limit.
Order management (OM)
Advanced Pricing (QP)
Configurator (CZ)
iStore (IBE)
5. Procure: Here you normally choose the suppliers that will deliver the goods and services you
need to create your product. Develop a set of pricing, delivery and payment processes with
suppliers and create metrics for monitoring and improving the relationships.
Purchasing (PUR)
iProcurement(iPROC)
6. Manufacture: Schedule the manufacturing activities necessary for production, testing,
packaging and preparation for delivery.
Cost Management (CST)
Process Manufacturing (GMA)
Project Manufacturing (PJM)
Quality (QA)
Work in Process(WIP )

7. Fulfill & Release Management: Coordinate the receipt of orders from customers, develop a
network of warehouses, pick carriers to get products to customers and set up an invoicing system
to receive payments.
Shipping Execution (WSH)
Inventory Management (INV)
WareHouse Management System (WMS)
Transportation Execution (FTE )
8. Service & Maintain: Create a network for receiving defective and excess products back from
customers and supporting customers who have problems with delivered products.
Depot Repair (CSD)
Field Service (CSF)
Install Base (CSI)
Service Contracts (OKS)
Service Fulfillment Manager (XDP)
Spares Management(CSP )
This does not cover the financial flow with SCM.

SCM Oracle Solutions

SCM of Oracle E-Business Suite does cover each area of SCM as discussed in other post. Here is
how best can describe as involvement of all five key participants.

Within SCM these are the business Process that can be fit with this application Module.
1) Procure to Pay
Here is flow that can be best understood with Oracle Modules Involvement.
Under this Business Process Oracle module can be potentially used as
Oracle Purchasing(PUR)
iProcurement(iProc)
iSupplier Portal(isupplier)
Payables(AP)
Purchasing Intelligence(for BI)

2) Order to Cash
Here is flow that can be best understood with Oracle Modules Involvement.
Under this Business Process Oracle module can be potentially used as
Oracle Order Management (OM)
Oracle Inventory (INV)
Shipping Execution (WSH)
Advanced Pricing (QP)
Oracle Configurator (CZ)
Warehouse Management (WMS)
Receivables(AR)

3) Lead to Service
Under this Business Process Oracle module can be potentially used as

CRM Foundation (JTF)

Sales Online (ASF)
Marketing Online (AMS)
Customer Care (CSC)
Install Base (CSI)
Depot Repair (CST)
Service Contracts (OKS)
iStore (IBE)
iSupport (IBU)
Field Service (CSF )

4) Forecast to Plan
Under this Business Process Oracle module can be potentially used as
Material Planning (MRP)
Advanced Supply Chain Planning (ASCP)
Collaborative Planning

5) Demand to Build
Under this Business Process Oracle module can be potentially used as
Demand Planning (MSD)
Bills of Material (BOM)
Work in Process (WIP)
Cost Management (CST)
Flow Manufacturing (FLM )

Technical components of Oracle Purchasing

1.
2.
3.
4.
5.

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
1. 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.
The setting up of approval hierarchy for PO requires few mandatory setup , which start with
employee /Buyer information.These are the following steps required.
Define the employee and his/her superiors
Define the positions for the employee and the superiors

N --> Setup --> Personnel --> Positions

assign the employee and the superiors to a position

N -->Setup --> Personnel --> Jobs

define an approval group which allows him/her to approve PO's up to the approval limit.
Same for the superiors.
N --> Setup --> Personnel --> Position Hierarchy
Make sure the document type (e.g. PO) allows 'Owner can Approve' (checkbox)
Assign the approval groups to the correct positions
Create a position hierarchy for every org according to your wishes
Assign the hierarchies to the document type
Run the concurrent request 'Fill Employee Hierarchy'
and , finally the above can be understood in the data diagram as below.
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 stores multiple records per employee with
specific start and end dates.
2. 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) . It used to be unique for a vendor until PO_VENDORS.
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.
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.
3. 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.
A functional flow of Requisition cycle can be represented as: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.
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. It is a primary key.
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.
In short:- PO_Requisition_Headers_All
SEGMENT1 - Requisition Number
AUTHORIZATION_STATUS - Lookup code and can have values

APPROVED Document has been Approved

CANCELLED Document has been Cancelled
IN PROCESS Document is still undergoing Approval
INCOMPLETE Document is not yet Complete
PRE-APPROVED Document is Approved but not yet Accepted
REJECTED Document as been Rejected
REQUIRES REAPPROVAL Requires Reapproval
RETURNED Document has been Returned
REQUISITION_HEADER_ID Unique Requisition ID (PK)

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

In short:- PO_Requisition_Lines_ALL
REQUISITION_LINE_ID Requisition line unique identifier
REQUISITION_HEADER_ID Requisition header unique identifier
LINE_NUM Line number
QUANTITY Quantity of Line item
LINE_LOCATION_ID Document shipment schedule unique identifier
UNSPSC_CODE Standard UNSPSC CODE
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.
How we map the Main screen for Requisition with database table.
Other important tables for Requisition:1. MTL_System_Items_B: This is the definition table for items. This table holds the definitions
for inventory items, and purchasing items. The primary key is INVENTORY_ITEM,
ORGANIZATION_ID.
2. GL_CODE_Combinations: These table stores valid Accounting Flex Field segment value
combinations for each accounting flex field structure within your GL application.

GL_CODE_COMBINATIONS is populated by the system when a new accounting flex field

combination is used, either through dynamic insertion or manually.
This can be best represented as per data model as:
4.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.
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. 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.
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.
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.
PRICE_OVERRIDE always equals the purchase order line price for standard purchase order
shipments.
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.
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.
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.
5. 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.
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 in transit 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 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 receiptbased accruals.
Updates the corresponding purchase orders with the final received and delivered quantities.

Oracle API Availability -Purchasing

To get the brief idea about some available standard available Oracle Application interfaces
applicable within oracle purchasing modules and hopefully it should serve to familiarize
individuals with limited knowledge of Oracle's API functionality.

1. Open Requisition Interface

What you can do:
By this you can Automatically import requisitions from other oracle Application system or any
other system using this interface. This allows you to integrate your oracle purchasing application
with new or existing applications, such as material requirement planning, inventory
management.etc.
What tables involved
PO_REQUISITIONS_INTERFACE_ALL
PO_REQ_DIST_INTERFACE_ALL

2. Requisition Reschedule
What you can do:
This is required when you are having Oracle Master Scheduling/MRP or a non-Oracle MRP
system integrated with your oracle Purchasing, you may find that you need to reschedule
requisitions as your
Planning requirements change. This API'S lets you reschedule requisition lines according to
changes in your planned orders.
What tables involved
PO_RESCHEDULE_INTERFACE
3. Purchasing Documents Open Interface
What you can do:
You can Automatically import and update standard purchase orders, price/sales catalog
information, and responses to request for Quotations(RFQ's) from suppliers through this
interface. This interface uses the API's to process document data in the oracle applications
interface table to ensure that it is valid before importing it into oracle purchasing. After the data
is validated, the program converts the information in the interface table into the appropriate
document in purchasing.

What tables involved

PO_HEADERS_INTERFACE
PO_LINES_INTERFACE
PO_DISTRIBUTIONS_INTERFACE

4. Receiving Open Interface

What you can do:
You can automatically import receipt information from other oracle applications or other system
using the receiving open interface. This interface lets you integrate your oracle purchasing
applications with new or existing applications. E.g. you can load bar-coded and other receiving
information from scanners.
More over the good things is that you can also bring Advance Shipment Notices (ASNs) sent
from suppliers by this interface.
What tables involved
RCV_HEADERS_INTERFACE
RCV_TRANSACTIONS_INTERFACE

What you can't done by this API's

Serial numbering
Separate receive and deliver
Corrections
Returns
Movement statistics
Dynamic locators
Receiving against Internal Orders
Receiving against Inter-Organization transfers
Receiving against Drop Ship Orders
Receiving against RMAs

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.

1. 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 the requisition 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 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.

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

3. 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
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, system
generated 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
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.

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
1
2
3
4
5
6

Column Name
Agent_id
Agent_name
Location_id
Location_code
Start_date_active
End_date_active

Comments
Unique agent id
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.
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
7
8
9
10
11

Column Name
Po_header_id
Agent_id
Segment1
Revision_num
Vendor_id
Vendor_site_id
Vendor_contact_id
Ship_to_location_id
Bill_to_location_id
Currency_code
Authorization_status

12
13

Type_look_up_code
Org_id

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

PO

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

Column Name
Po_line_id
Po_header_id
Line_type_id
Line_num
Item_id
Item_rev
Item_description
Quantity
Unit_price
List_price
Org_id
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
1
2
3
4
5
6
7

Column Name
LINE_LOCATION_ID
PO_HEADER_ID
PO_LINE_ID
QUANTITY
SHIP_TO_LOCATION_ID
SHIPMENT_TYPE
ORG_ID

Comments
Unique identifier LINE_LOCATION_ID
Refers PO_HEADERS_ALL
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.
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_RELEASES_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
PO_LINE_LOCATIONS_ALL
PO_RELEASES_ALL
PO_DISTRIBUTIONS_ALL
PO_VENDOR_SITES_ALL

Multi Org View

PO_HEADERS
PO_LINES
PO_LINE_LOCATIONS
PO_RELEASES
PO_DISTRIBUTIONS
PO_VENDOR_SITES