438 oracle purchasing technical

8/4/2019 438 Oracle Purchasing Technical

1/57

Technical components of Oracle Purchasing

Written by Anon

Friday, 12 February 2010 02:30

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 technicalcomponents like interfaces, workflows, profile options, tables etc which are summarized

in this article.

Main Business Components in Oracle Purchasing are

1 / 57


2/57


Written by Anon


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

2 / 57


3/57


4/57


Written by Anon


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.

4 / 57


5/57


Written by Anon


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

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.

5 / 57


6/57


Written by Anon


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.

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.

6 / 57


7/57


Written by Anon


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

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

7 / 57


8/57


Written by Anon


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 generatedocument 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 informationto record and update item and price information for purchase orders, quotations, and RFQs.

8 / 57


9/57


Written by Anon


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

9 / 57


10/57


Written by Anon


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 ordershipment 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_IDcorresponds to the ID of the requisition distribution you copy on the purchase order.

10 / 57


11/57


Written by Anon


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 POline or a single PO shipment.

11 / 57


12/57


Written by Anon


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 orexpected 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 intransit shipment, the receipt number is not populated until you receive

the shipment.

12 / 57


13/57


Written by Anon


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

13 / 57


14/57


Written by Anon


Requisitions Interface

See ReqImport process below.

Purchasing Documents Open Interface (PDOI)

You can automatically import and update price/sales catalog information and request forquotation (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 generationmethods 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

14 / 57


15/57


Written by Anon


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 R

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

15 / 57


16/57


Written by Anon


information.

Populates the RCV_SHIPMENT_LINES table in Purchasing for each receipt header entry inthe 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 asreceipt-based accruals.

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.

16 / 57


17/57


Written by Anon


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

17 / 57


18/57


Written by Anon


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)

18 / 57


19/57


Written by Anon


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

PO Create Documents Workflow Overview

Purchasing integrates with Oracle Workflow technology to create standard purchase orders orblanket 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.

19 / 57


20/57


Written by Anon


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 forapproval. 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 tosubmit a document for approval that has not yet been submitted.

20 / 57


21/57


Written by Anon


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,

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.

21 / 57


22/57


Written by Anon


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

22 / 57


23/57


Written by Anon


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

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

23 / 57


24/57


Written by Anon


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

24 / 57


25/57


Written by Anon


The transaction goes to the interface table, where it will be picked up the next time the Receiving Trans

Immediate

The transaction goes to the interface table, and the ReceivingTransaction Processor is called for the group of transactions that you entered si

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 orderentry can be overridden at receipt time.

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.

25 / 57


26/57


Written by Anon


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.

26 / 57


27/57


Written by Anon


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

Comments

1

27 / 57


28/57


Written by Anon


Agent_id

Unique agent id

2

Agent_name

Agent Name

3

Location_id

Unique location id

4

Location_code

Location code

28 / 57


29/57


Written by Anon


5

Start_date_active

Start date active

6

End_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 hehas created. This field is not updatable when the document type is RFQ or Requisition.

29 / 57


30/57


Written by Anon


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.

30 / 57


31/57


Written by Anon


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

31 / 57


32/57


Written by Anon


Sr.no

Column Name

Comments

1

Vendor_id

Unique vendor id

2

Vendor_name

Vendor or supplier name

3

Segment1

32 / 57


33/57


Written by Anon


Vendor Number

4

Start_date_active

Start date active

5

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

33 / 57


34/57


Written by Anon


Sr.no

Column Name

Comments

1

Vendor_site_id

Unique vendor site Id

2

Vendor_id

Unique vendor site id refers PO_VENDORS

3

Vendor_site_code

34 / 57


35/57


Written by Anon


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

Column Name

35 / 57


36/57


Written by Anon


Comments

1

Po_header_id

Unique Po Header Id

2

Agent_id

Agent id refers PO_AGENTS_V

3

Segment1

PO Number

4

36 / 57


37/57


Written by Anon


Revision_num

Revision Number for PO

5

Vendor_id

Unique vendor id refers PO_VENDOR_ID

6

Vendor_site_id

Unique vendor site id refers PO_VENDOR_SITES_ALL

7

Vendor_contact_id

Vendor contact id

37 / 57


38/57


Written by Anon


8

Ship_to_location_id

Where the material will be shipped by supplier

9

Bill_to_location_id

Where the Bill/Invoice will be sent by the supplier

10

Currency_code

Currency code

11

38 / 57


39/57


Written by Anon


Authorization_status

Authorization status for the PO Open/Closed/Approved/Incomplete

12

Type_look_up_code

What is the type of PO Standard/Blanket/Planned

13

Org_id

Operating Unit

The second type of information stored is line level information.

39 / 57


40/57


Written by Anon


Its is stored in the table PO_LINES_ALL

Sr.no

Column Name

Comments

1

Po_line_id

Line identification number

2

Po_header_id

PO header id refers PO_HEADERS_ALL

40 / 57


41/57


Written by Anon


3

Line_type_id

Line type_id such as Goods/Services/Expense etc

4

Line_num

Unique line num for each line item

5

Item_id

Item to purchased refers MTL_SYSTEMS_ITEMS

6

Item_rev

41 / 57


42/57


Written by Anon


Revision of the item refers MTL_SYSTEM_ITEMS

7

Item_description

Description of item

8

Quantity

Quantity to be entered

9

Unit_price

Price of one unit

10

42 / 57


43/57


Written by Anon


List_price

Unit price from price list

11

Org_id

Operating unit from where purchasing will take place

12

Promise_date

Promise date by supplier

13

Need_by_date

Date by which the material is required

43 / 57


44/57


Written by Anon


The third type of information is the shipment

The information is stored in PO_LINE_LOCATIONS_ALL

Sr.no

Column Name

Comments

1

LINE_LOCATION_ID

Unique identifier LINE_LOCATION_ID

2

44 / 57


45/57


Written by Anon


PO_HEADER_ID

Refers PO_HEADERS_ALL

3

PO_LINE_ID

Refers PO_LINE_ALL

4

QUANTITY

Quantity to be shipped

5

SHIP_TO_LOCATION_ID

Unique Identifier for the quantity to be shipped

45 / 57


46/57


Written by Anon


6

SHIPMENT_TYPE

Price break, Blanket ,Standard

7

ORG_ID

Operating Unit

The distribution information is stored in PO_DISTRIBUTIONS_ALL

Sr.no

46 / 57


47/57


Written by Anon


Column Name

Comments

1

Po_Distribution_Id

Unique Distribution Id

2

Po_Header_Id

PO Header Identification number referring PO_HEADERS_ALL

3

Po_Line_Id

PO Line identification number referring PO_LINES_ALL

47 / 57


48/57


Written by Anon


4

Line_Location_Id

Refers PO_LINE_LOCATIONS_ALL

5

Set_Of_Books_Id

Set of Books

6

Code_Combination_Id

GL Code combination id for charge account

7

48 / 57


49/57


Written by Anon


Quantity_Ordered

Quantity Ordered

8

Distribution_Num

Unique distribution number

9

Destinition_Type_Code

Destination type Code for e.g. Inventory

10

Destination_Organization_Id

Destination organization id

49 / 57


50/57


Written by Anon


11

Destination_Subinventory

Destination Sub-inventory

12

Org_Id

Operating unit

13

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.

50 / 57


51/57


Written by Anon


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

51 / 57


52/57


Written by Anon


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

Column Name

Comments

1

PO_RELEASE_ID

PO Release identification Number

2

PO_HEADER_ID

52 / 57


53/57


Written by Anon


Refers PO_HEADERS_ALL

3

RELEASE_NUM

Unique release num

4

AGENT_ID

Buyer ID refers PO_AGENTS_V

5

RELEASE_DATE

The date on which release is created

6

53 / 57


54/57


Written by Anon


REVISION_NUM

Revision number is generated when any changes are done to release information

7

APPROVED_FLAG

Y if the release in question is approved

8

APPROVED_DATE

Date on release is approved

9

PRINT_COUNT

No of times the release is printed

54 / 57


55/57


Written by Anon


10

PRINT_DATE

Last printed date of the release

11

AUTHORIZATION_STATUS

Different status of the releases such as Open/Closed/Approved/Incomplete

12

ORG_ID

Operating unit

55 / 57


56/57


Written by Anon


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

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

Multi Org View

PO_HEADERS_ALL

PO_HEADERS

PO_LINES_ALL

PO_LINES

56 / 57


57/57


Written by Anon


PO_LINE_LOCATIONS_ALL

PO_LINE_LOCATIONS

PO_RELEASES_ALL

PO_RELEASES

PO_DISTRIBUTIONS_ALL

PO_DISTRIBUTIONS

PO_VENDOR_SITES_ALL

PO_VENDOR_SITES