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 empl oyee. PER_PEOPLE_F/PER_ALL_PEOPLE_F store multiple records per employee with spe cific start and end dates

Vendors PO_VENDORS, PO_VENDOR_SITES_ALL and PO_VENDOR_CONTACTS are the main tables for t his entity. Vendors are global i.e. a vendor, once defined, can be used across o perating units (OU). Vendor sites are OU specific. Most of the PO tables store t he VENDOR_ID and VENDOR_SITE_ID columns. VENDOR_SITE_ID is unique (not unique wi thin a VENDOR_ID) in 11i. It used to be unique for a vendor until 11.0.PO_VENDOR S PO_VENDORS stores information about your suppliers. You need one row for each su pplier you define. Each row includes the supplier name as well as purchasing, re ceiving, payment, accounting, tax, classification, and general information. Oracle Purchasing uses this information to determine active suppliers. VENDOR_ID is the unique system generated receipt header number invisible to the user. SEGMENT1 is the system generated or manually assigned number you use to identify t he supplier in forms and reports. Oracle Purchasing generates SEGMENT1 using the PO_UNIQUE_IDENTIFIER_CONTROL table if you choose to let Oracle Purchasing gener ate supplier numbers for you. This table is one of three tables that store supplier information. PO_VENDORS co rresponds 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 Purchasin g uses this information to store supplier address information. This table is one of three tables that store supplier information. PO_VENDOR_SIT ES_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 ne ed 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_CON TACTS 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 ca n be created by various means Enter Reqs form, Requisition Interface tables or u sing Self Service Purchasing. All requisitions need to be approved before being considered for future processi ng. An unapproved requisition has a value of Incomplete for the column AUTHORIZATI ON_STATUS in the table PO_REQUISITION_HEADERS. After the requisition is complete d 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 nee d one row for each requisition header you create. Each row contains the requisit ion number, preparer, status, and description. REQUISITION_HEADER_ID is the unique system generated requisition number. REQUISITI ON_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 tab le 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 REQUISI TION_HEADER_ID. PO_REQUISITION_LINES: PO_REQUISITION_LINES stores information about requisition lines. You need one ro w for each requisition line you create. Each row contains the line number, item number, item category, item description, need by date, deliver to location, item quantities, units, prices, requestor, notes , and suggested supplier information for the requisition line. 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 requisitio n line on a purchase order. BLANKET_PO_HEADER_ID and BLANKET_PO_LINE_NUM store the suggested blanket purchas e agreement or catalog quotation line information for the requisition line. PARENT_REQ_LINE_ID contains the REQUISITION_LINE_ID from the original requisitio n 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 a ssociated with each requisition line. Each requisition line must have at least o ne accounting distribution. You need one row for each requisition distribution y ou create. Each row includes the Accounting Flexfield ID and requisition line quantity. PO_REQ_DISTRIBUTIONS_ALL is one of three tables storing your requisition informa tion. 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 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 do cument. Oracle Purchasing uses this information to record information that is re lated to a complete document. PO_HEADER_ID is the unique system generated primary key and is invisible to the user. SEGMENT1 is the system assigned number you use t o identify the document in forms and reports. Oracle Purchasing generates SEGMEN T1 using the PO_UNIQUE_IDENTIFIER_CONT_ALL table if you choose to let Oracle Pur chasing generate document numbers for you. SEGMENT1 is not unique for the entire table. Different document types can share the same numbers. You can uniquely id entify a row in PO_HEADERS_ALL using SEGMENT1 and TYPE_LOOKUP_CODE or using PO_H EADER_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 Purch asing uses START_DATE and END_DATE to store the valid date range for the documen t. 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, ta x information, matching information, and quantity ordered for the line. Oracle P urchasing uses this information to record and update item and price information for purchase orders, quotations, and RFQs. PO_LINE_ID is the unique system generat ed 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 line s (found in PO_LINE_LOCATIONS_ALL). PO_LINE_LOCATIONS_ALL: Also known as Shipments is a detail of lines. PO_LINE_LOCATIONS_ALL contains inf ormation about purchase order shipment schedules and blanket agreement price bre aks. 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, qu otations and RFQs. PO_RELEASE_ID applies only to blanket purchase order release shipments. PO_RELEA SE_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 depend s 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 ES_ALL. N , then PRICE_OVERRIDE equals UNIT_PRICE in PO_LIN

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 ord er 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 deliv er to location for the distribution. Oracle Purchasing uses this information to re cord accounting and requisition information for purchase orders and releases. PO_DISTRIBUTIONS_ALL is one of five tables storing purchase order and release in formation. Some columns in PO_DISTRIBUTIONS_ALL contain information only if certain conditi ons exist: If you autocreate this accounting distribution from a requisition, REQ_DISTRIBUT ION_ID corresponds to the ID of the requisition distribution you copy on the pur

chase order. If you use a foreign currency on your purchase order, Oracle Purchasing stores c urrency 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_R EFERENCE_NUM and REQ_HEADER_REFERENCE_NUM contain the requisition number and req uisition line number of the corresponding paper requisition. These two columns a re 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 pur chase order release. Reqs can be converted to Purchase Orders using either the Autocreate form or Cre ate 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 (Inte rnal Requisitions and Inter-org transfers) that you need to use when receiving a gainst 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 inter organization transfer, or when re ceiving items that you request from your inventory using an internal requisition , the receipt type would be Internal Order . The Internal Order receipt source type p opulates 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 dif ferent sources under one receipt header. Oracle Purchasing creates a receipt header when you are entering your receipts o r when you perform inter organization transfers using Oracle Inventory. When Oracl e Inventory creates a receipt header for an intransit shipment, the receipt numb er 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 informat ion 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 tr ansaction processor processes your transaction, the transaction is recorded in t his 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 RC V_SUPPLY. The original transaction quantity does not get updated. You can only d elete rows from this table using the Purge feature of Oracle Purchasing.

Main Interfaces You could import requisitions, Purchase Orders and Receipts using the open inter faces for the respective entities. The Manufacturing APIs and Open Interfaces ma nual 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 requ est for quotation (RFQ) responses from suppliers through the Purchasing Document s Open Interface. You can also import standard purchase orders (for example, fro m a legacy system) through the Purchasing Documents Open Interface. The Purchasing Documents Open Interface uses Application Program Interfaces (API s) to process the data in the Oracle Applications interface tables to ensure tha t it is valid before importing it into Oracle Purchasing. After validating the p rice/sales catalog information or RFQ responses, the Purchasing Documents Open I nterface 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 Interfa ce also validates the header, line, shipment, and distribution information befor e importing the purchase orders into Purchasing. You can choose whether to import the data as standard purchase orders, blanket p urchase agreements, or catalog quotations. You can also choose to update your it em master and, for blanket purchase agreements and quotations, apply sourcing ru les and release generation methods to the imported item. Blanket purchase agreem ents and quotations can also be replaced with the latest price/sales catalog inf ormation when your supplier sends a replacement catalog, or updated when the sup plier 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 thro ugh Electronic Data Interchange (EDI). The Purchasing Documents Open Interface s

upports the EDI transmissions of the price/sales catalogs (ANSI X12 832 or EDIFA CT PRICAT) and responses to RFQs (ANSI X12 843 or EDIFACT QUOTES). Standard purc hase orders cannot be transmitted through EDI. You can import these into the int erface 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 derive d, defaulted, and validated by the Receipts window. Most receipt data that is im ported 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 initiate s 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 Receiv ing 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 i nformation. Populates the RCV_SHIPMENT_LINES table in Purchasing for each receipt header ent ry in the RCV_SHIPMENT_HEADERS table in Purchasing. Populates the RCV_TRANSACTIONS table in Purchasing for each row in the RCV_SHIPM ENT_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, su ch as receipt-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 i mportant processes in Oracle Purchasing. The user s guide and Oracle Manufacturing API s 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 imp orts your requisitions. You can import requisitions as often as you want. Then, you can review these requisitions, approve or reserve funds for them if necessar

y, 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_IN TERFACE_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 R equisition 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 tab le. 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 t herequisition lines in the PO_REQUISITIONS_INTERFACE_ALL table. You also specify the requisition grouping and numbering criteria as parameters to the Requisitio n Import program. Each run of the Requisition Import program picks up distribution information fro m either the PO_REQUISITIONS_INTERFACE_ALL or the PO_REQ_DIST_INTERFACE_ALL tabl e. 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 requis itions created in non-Oracle systems that use multiple distributions. As long as the Multiple Distributions field in the Requisition Import program is No (or bl ank), Requisition Import looks for distribution information in the PO_REQUISITIO NS_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 erro r. In the second phase, the program groups and numbers the validated requisition li nes according to the following criteria. If you specify a value in the REQ_NUMBE R_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 t his 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 provi de a value for this parameter, the program uses the default Group By that you se t up to group requisition lines. You can group requisition lines in one of the f ollowing 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 Requ isition Import program uses either the Last Requisition Number parameter if spec ified 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 requis ition numbers generated already exists, the program loops until it finds a uniqu e number. For every line that is successfully imported, a default distribution i s created with the account information that you specify. (You specify account in formation in any of the following columns in either the PO_REQUISITIONS_INTERFAC

E_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_SEGMEN T columns.) Requisition supply is also created for every approved requisition th at is successfully imported. In the third phase, the program deletes all the successfully processed rows in t he interface tables, and creates a report which lists the number of interface re cords that were successfully imported and the number that were not imported. Thi s report can be viewed by choosing View Output for the Requisition Import concur rent Request ID in the Requests window. You can launch the Requisition Import Excepti ons Report to view the rows that were not imported by the Requisition Import pro gram along with the failure reason(s) for each row. PO Create Documents Workflow OVERVIEW Purchasing integrates with Oracle Workflow technology to create standard purchas e orders or blanket releases automatically from approved requisition lines. The workflow for creating purchasing documents automatically is called PO Create Doc uments. 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 objec ts and properties you can modify. Each workflow process consists of individual f unctions. For each document that is created successfully by the PO Create Documents workfl ow, the PO Approval workflow is called to approve the document if you have allow ed automatic approval. FLOW The PO Create Documents workflow is initiated at the end of the requisition appr oval workflow for approved requisition lines. The workflow begins automatic docu ment creation if you ve kept the item attribute Is Automatic Creation Allowed? set to Y for Yes, if source documents are associated with the requisition lines, an d you have properly set up sourcing rules. If the source document associated wit h 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 i n the Notifications Summary window, Purchasing uses Oracle Workflow technology i n the background to handle the approval process. Workflow uses the approval cont rols and hierarchies you define according to the setup steps in the section to r oute documents for approval. You can use the Workflow Builder interface to modif y your approval process. The purchase order approval workflow consists of processes, which are viewable i n the Workflow Builder as a diagram, some of whose objects and properties you ca n modify. Each workflow process, in turn, consists of individual function activi ties. 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 Ap proval. This item type identifies all purchase order and release approval workfl ow processes available. Refer to the Oracle Purchasing User s 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 pro vide to customize Oracle Purchasing to your company s 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, sys tem generated numbers for the Oracle Purchasing tables that require special sequen cing. You need one row for each sequentially system generated number for each orga nization. The table includes rows for each of the following: purchase orders, re quisitions, receipts, suppliers, quotations, and requests for quotations (RFQs). For each organization, there are four rows for each of the following entities: P O_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_HEA DERS. The information for the quotation and RFQ sub entities is associated with the PO_H EADERS_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 busine ss. You need each row for each line type you use. Oracle Purchasing uses this in formation to provide default information when you create a document line using a line type. Oracle Purchasing also uses this information to control how you ente r information on your document lines according to the line type you choose. ORDER_TYPE_LOOKUP_CODE is AMOUNT ity based line type. for an amount based line type or QUANTITY for a quant

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 y our company s 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, rel ease, or requisition. Each row includes references to the document itself, the e mployee who acted on the document, the date of the action, the type of action ta ken 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 doc uments and to forward documents in the approval process to the appropriate emplo yee.

Important Profile Options in Oracle Purchasing PO: AUTOCREATE GL DATE OPTION Indicates the date used on purchase orders generated by AutoCreate: The autocrea te date is used as the purchase order date. The GL date on the requisition distr ibution is used as the purchase order date. PO: AUTOMATIC DOCUMENT SOURCING Yes means that Purchasing automatically defaults source document and pricing inf ormation for an item from the most recently created blanket purchase agreement o r quotation. No means that this source document information comes from the Appro ved 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 f rom another system using the Receiving Open Interface, the View Log screen displ ays the receiving transaction pre processor s actions, including errors, as it proce ssed 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 tr ace file; if you need help with an error that occurs while the Receiving Transaction Processor runs, Oracle Support Services may ask you for th is 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 a nd uses the Receiving Transaction Processor to import the validated data into Pu rchasing. 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 Auto Create to only splitting the quantity of a line. No means that the standard Auto Create 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 t o the standard concurrent manager details log viewable through the View Log butt on in the Submit Request window when running the Purchasing Documents Open Inter face program. Yes means log details are written to a flat file. No means log details are writt en to the concurrent manager log screen, which can cause overflow problems for l arge catalogs. Leaving this profile option blank means log details are not writt en at all, which improves performance. RCV: PROCESSING MODE Indicates the processing mode used after you save your work for receiving transa ctions: 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 Proce ssor is called for the group of transactions that you entered since you last sav ed 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. RCV: DEBUG MODE If set to Yes, and RCV: Processing Mode set to Immediate or Batch, debug message s 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 Tra nsactions window automatically select the Include Closed POs checkbox. Your sear ch 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 sett ing other than Yes prevents receiving against orders using the Receiving Open In terface with the status of Closed for Receiving.

Basic Purchasing Setups The purchasing user must be set as a buyer in Oracle applications. Before settin g 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 s tore 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 decide d by how the document types are setup. The table which stores the buyer is PO_AGENTS and the view used for the buyer na me and other details is PO_AGENTS_V. The important columns PO_AGENTS_V Sr.no Column Name Comments 1 Agent_id Unique agent id 2 Agent_name Agent Name 3 Location_id Unique location id 4 Location_code Location code 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 docum ents he has created. This field is not updatable when the document type is RFQ o r 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 approva l 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 docu ment type in question. One can define a custom workflow and also mention the nam e 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 Column Name Comments 1 Vendor_id Unique vendor id 2 Vendor_name Vendor or supplier name 3 Segment1 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. Thi s stores the important information of vendor sites. 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 Vendor site code

Purchase Orders Creation Of Standard Purchase Orders Creation of purchase orders has three parts. First is the header information sec ond is the line information and the third is the shipments and distributions inf ormation. This applies for the standard purchase order. Sr.no Column Name Comments 1 Po_header_id Unique Po Header Id 2 Agent_id Agent id refers PO_AGENTS_V 3 Segment1 PO Number 4 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 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 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. 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 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 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 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

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 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 6 SHIPMENT_TYPE Price break, Blanket ,Standard 7 ORG_ID Operating Unit

The distribution information is stored in PO_DISTRIBUTIONS_ALL Sr.no 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 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 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 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 followi ng 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 informati on. 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_RELEASE_ALL Sr.no Column Name Comments 1 PO_RELEASE_ID PO Release identification Number 2 PO_HEADER_ID 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 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 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 Concept of Multi Organization in Purchasing In Oracle purchasing can be done across multiple organizations also called as op erating units. So to accommodate this oracle has provided multi org views for th e base tables of purchasing. For instance the table PO_HEADERS_ALL stores the he ader 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 Multi Org View PO_HEADERS_ALL PO_HEADERS PO_LINES_ALL PO_LINES

PO_LINE_LOCATIONS_ALL PO_LINE_LOCATIONS PO_RELEASES_ALL PO_RELEASES PO_DISTRIBUTIONS_ALL PO_DISTRIBUTIONS PO_VENDOR_SITES_ALL PO_VENDOR_SITES http://docs.oracle.com/cd/A97501_01/html/technologyset.html