Purchasing Documents Open Interface (PDOI)

Purchasing Documents Open Interface (PDOI)

Import Standard Purchase Orders

Import Price Catalogs (Blanket and Quotation) program

The Import Price Catalogs program is also available separately in the Requests window in Purchasing; it can be run only after you’ve successfully loaded the data into the interface tables. For standard purchase orders, you must use the Import Standard Purchase Orders program to import the data into Purchasing

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.

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). Standard purchase orders cannot be transmitted through EDI. You can import these into the interface tables using a program that you write. The EDI inbound program and the Import Price Catalogs program are run as a request set when you choose Submit Request in the EDI import programs window. The EDI inbound program loads the interface tables; the Import Price Catalogs program validates the data and loads the validated data into Purchasing. You can also run the Import Price Catalogs program separately in the Submit Request window in Purchasing, after the data is loaded into the interface tables. For standard purchase orders, you must use the Import Standard Purchase Orders program in Purchasing to import the data from the interface tables into Purchasing.

You can view the status of your submission by making note of the Request ID number and selecting View My Requests from the Help menu.

The PDOI programs receive the data, derive and default any missing data, and validate the data. If no errors are found in the submission process, the data in the PDOI tables is loaded into the PO_HEADERS_ALL, PO_LINES_ALL, PO_LINE_LOCATIONS_ ALL, and PO_DISTRIBUTIONS_ALL tables in Purchasing to create the standard purchase order, blanket purchase agreement, or catalog quotation, including price breaks if any. The creation of items (if you allow updating of the item master) or sourcing rules also populates the corresponding tables (such as MTL_SYSTEM_ITEMS, ASL_ITEMS, ASL_SUPPLIERS, and ASL_DOCUMENTS).If the PDOI programs find errors in the interface tables, such as incomplete information from the supplier, the record identification number and the details of the error are written to the PO_INTERFACE_ERRORS table.

Record and Error Processing (PO_INTERFACE_ERRORS table)

To detect errors, the Purchasing Documents Open Interface programs first process a record from the PO_HEADERS_INTERFACE table. Then, the program processes the child records in the PO_LINES_INTERFACE table and, for standard purchase orders, the PO_DISTRIBUTIONS_INTERFACE table, before going on to the next PO_HEADERS_INTERFACE record. If the program gets an error while processing a record, the program writes the error details to the PO_INTERFACE_ERRORS table and increments the record’s error counter. It then flags the record as "Not Processable."

For more details on interface error tables check out the following blog post.

If an error is found in a header, none of its lines are processed. The Purchasing Documents Open Interface rolls back the header, do not process its lines, and do the following:

_ sets the PROCESS_CODE column value to REJECTED in the PO_HEADERS_

INTERFACE table.

_ Writes out the record identification number and the details of the error to the

PO_INTERFACE_ERRORS table.

_ Begins processing the next header record.

It is important to check the Purchasing Interface Errors report (a report of the errors in the PO_INTERFACE_ERRORS table) after you import the documents. Because the Purchasing Documents Open Interface saves or errors out line by line, it can accept partial documents. Therefore, to see which document lines were not submitted because of errors, you must check the Purchasing Interface Errors report.

PROCESS_CODE column value in PO_HEADERS_INTERFACE table:

• If an error is found in a header PROCESS_CODE column value to REJECTED in the PO_HEADERS_INTERFACE table.

• If no processing errors are found during processing, the header record and all successfully submitted child records are loaded into Purchasing, and then flagged as processed by setting the PROCESS_CODE column to ACCEPTED.

• For blanket purchase agreements and standard purchase orders only, when the supplier sends an updated price/sales catalog, the Purchasing Documents Open Interface sets the PROCESS_CODE column to NOTIFIED for those lines with prices that exceed your price tolerance. For these price updates only, the Purchasing Documents Open Interface waits for you to accept or reject the price increase in the Exceeded Price Tolerances window before completing or rejecting the price change. 

ACTION column of the PO_HEADERS_INTERFACE table

Original, Replace, and Update Submissions

If you are using e-Commerce Gateway to import blanket purchase agreements and catalog quotations (in the form of flat files) into the Purchasing Documents Open Interface, your supplier can send you a flat file with one of three action codes (in the ACTION column of the PO_HEADERS_INTERFACE table): Original, Replace, or Update. If you’re not using e-Commerce Gateway, your import program needs to specify the action code.

Original

A file with an action code of Original is one in which all the information is new to your system.

Choose Original when you’re submitting documents for the first time.

For standard purchase orders, you can only choose Original.

For an Original submission, the PDOI first checks:

• If a document in the submission already exists in Purchasing. It checks for a document with the same supplier document number (VENDOR_DOC_NUM) and supplier (VENDOR_ID or VENDOR_NAME) that is not finally closed or canceled.
• If an active, matching document already exists, the document in the Original submission is not created and an error is logged in the Purchasing Interface Errors report. I.e. No duplicates allowed.

Replace

A file with an action code of Replace replaces already-created blanket purchase agreements or catalog quotations with new documents containing the new information.

The PDOI replaces these documents by doing the following:

• First, it looks for documents that have the same document type (DOCUMENT_TYPE_CODE), supplier (VENDOR_ID or VENDOR_NAME), and supplier document number (VENDOR_DOC_NUM) as the replacement documents. (A supplier document number is a field that is specified in the flat file that the supplier sends.

• Next, among the matching documents, it looks for documents with effectivity dates that are the same as, or within the effectivity dates of, the replacement documents.

•  Then, it invalidates the old documents by setting their expiration dates to START_DATE -1 (the start date, minus one day) and creates new documents with the new price/sales catalog information, within the original effectivity dates.

As with an Original submission, the Purchasing Documents Open Interface checks that there are no duplicate documents in Purchasing, but it does not consider finally closed or canceled documents as duplicates. That is, if two documents in Purchasing match an incoming document in the Replace submission, Purchasing replaces the one that is not canceled or finally closed. If one document in Purchasing matches an incoming document, but is canceled or finally closed, Purchasing still replaces it with the new document.

Update

A file with an action code of Update updates the following information on already-submitted blanket purchase agreements or catalog quotations without creating completely new documents:

Unit Price

If the price update exceeds the price tolerance you set, the price and price breaks are not updated until or unless the buyer accepts the price update in the Exceeded Price Tolerances window. Any other updates, however, are made to the document when the price/sales catalog is imported.

The price is updated on the document only, not in the item master. Only the item description is updated in the item master, if you’ve enabled item description updates.

Item Description

_ UOM

_ Price breaks (for blanket purchase agreements)

_ Expiration Date (for blanket purchase agreements)

_ URL descriptive flex field (if you have one)

A URL descriptive flex field provides a supplier URL for additional information about an item.

Choose Update when you want to update the fields on existing blanket purchase agreements and catalog quotations, and you want to preserve the existing documents’ sourcing rules

Expired lines in Purchasing (lines whose Expiration Date has been reached) do not get updated. An Update submission for an expired line is treated as a new line to be added to the blanket purchase agreement. Finally closed or canceled documents, or those that are no longer effective, do not get updated.

When the PDOI updates a line on a blanket purchase agreement, it does not update the open release for that line. Only future releases use the updated information.

Note: The Purchasing Documents Open Interface cannot update the UOM on an agreement line for which an open release exists. In this case, the Purchasing Documents Open Interface uses the Expiration Date field to expire the line on the agreement, and create a new line with the updated UOM, which will be used on future releases.

The Purchasing Documents Open Interface updates blanket purchase agreements and catalog quotations by doing the following:

• First, it identifies the catalog quotation or blanket purchase agreement that needs to be updated by comparing the supplier document number (VENDOR_DOC_NUM in the PO_HEADERS_INTERFACE table) with the existing supplier document number (VENDOR_ORDER_NUM for a blanket agreement, or QUOTE_VENDOR_QUOTE_NUMBER for a catalog quotation in the PO_HEADERS table). The supplier (VENDOR_ID or VENDOR_NAME) and document type (DOCUMENT_TYPE_CODE) must also match. The Purchasing Documents Open Interface matches only to currently or future-effective documents that are not canceled or finally closed.

•  Next, the Purchasing Documents Open Interface processes all the changed lines in the PO_LINES_INTERFACE table. It identifies which lines on the existing documents need to be updated by matching the following, in order:

Supplier item number

Item number used by your organization, revision number, and item category

 Item description and item category

• If it can’t match the supplier item number, it tries to match the item number used by your organization (along with the revision number and item category), and so on.

• If more than one line on the existing document matches the incoming line, the Purchasing Documents Open Interface updates the first line on the existing catalog quotation or blanket purchase agreement that matches the incoming line. This first line is also the line that is picked up for sourcing, as long as it has not expired.

• For a one-time item, the item description is updated only if a supplier item number (VENDOR_PRODUCT_NUM) is provided and can be used to find a matching line on the original document.

Sourcing

When you import blanket purchase agreements or catalog quotations into Purchasing, you have the option of choosing Yes or No in the Create Sourcing Rules field in the Parameters window to enable Purchasing to create sourcing rules out of the supplier, item, and document information that the supplier sends.

If you choose yes to create sourcing rules in an Original or Replace submission, Purchasing checks if a sourcing rule is assigned to the item at the item level and does the following:

Ø       If no sourcing rules exist for the item, Purchasing generates a sourcing rule automatically, allocating 100 percent to the supplier providing the information.

Ø       If a sourcing rule exists for the item, Purchasing compares the effectivity dates of the incoming document with those of the existing sourcing rule for the item. To ensure that only one sourcing rule is used for the item, Purchasing does the following:

       If the effectivity dates of the incoming document are the same as the existing sourcing rule’s effectivity dates, Purchasing checks if the supplier is in the sourcing rule. If not, Purchasing adds the supplier to the existing sourcing rule with an allocation of 0 percent. Later, you can query the sourcing rule and define your own percentage splits between suppliers.

        If the effectivity dates of the incoming document are different than the existing sourcing rule’s effectivity dates, but are within or overlap the existing effectivity dates, then a new sourcing rule is not created, so as not to conflict with the existing sourcing rule.

        If the effectivity dates of the incoming document are not within or match the existing sourcing rule’s effectivity dates, purchasing updates the item’s sourcing rule with the new effectivity dates, adding the supplier at an allocation of 100 percent.

        Purchasing checks for an Approved Supplier List entry for the item and supplier/site combination. If an entry exists, Purchasing adds the document to the entry. If an entry does not exist, Purchasing creates a new entry with the new source document.

If you choose yes to create sourcing rules in an Update submission, new sourcing information is created only if the Update submission results in a new line were being created.

Price Breaks 

All action codes (Original, Replace, and Update) support the importing of price breaks through the Purchasing Documents Open Interface, when the documents are imported as blanket purchase agreements or catalog quotations.

If one price break is rejected, the whole line to which the price break belongs is rejected.

Recall that the PO_LINES_INTERFACE table contains both line and shipment information, and imports data into both the PO_LINES and PO_LINE_LOCATIONS tables in Purchasing. To create two price breaks corresponding to one blanket agreement or quotation line, you would create two records in the PO_LINES_INTERFACE table. That is, one header-level record in the PO_HEADERS_INTERFACE table would have two records in the PO_LINES_INTERFACE table, and both of these line records would have the same INTERFACE_HEADER_ID:

_ one header-level record (row) in the PO_HEADERS_INTERFACE table corresponds to:

– Line 1: one line-level record (row) in the PO_LINES_INTERFACE table, with Shipment 1 information included

– Line 1: the same line-level record (another row) in the PO_LINES_

INTERFACE table, with Shipment 2 information included

When two or more lines with the same line and item number are imported into the PO_LINES_INTERFACE table, the Purchasing Document Open Interface treats the subsequent lines as price breaks belonging to the first line.

For the Update Submission

If the supplier updates an item’s price, the Purchasing Documents Open Interface deletes the item’s price breaks since they are no longer current with the new price. If the supplier sends new price breaks for an existing line, the current price breaks are deleted and the new price breaks sent by the supplier are created.

Just as with an Original or Replace submission, in an Update submission, when two or more lines with the same line and item number are imported into the PO_LINES_INTERFACE table, the Purchasing Document Open Interface treats the subsequent lines as price breaks belonging to the first line.

Attention: In an Update submission, the order of the line and its price breaks is important. If you are writing your own program to populate the interface tables, make sure that the price break lines (lines with the same line and item number, but different shipment numbers) follow the line to which they belong in the interface table. Otherwise, the Purchasing Documents Open Interface will treat them as duplicate lines (and update the previous line with the second). Use the INTERFACE_LINE_ID numbers to order price break (shipment) lines after their corresponding lines.

Adding or Deleting Lines in an Update Submission 

The Update submission enables the supplier to add or expire lines on existing blanket purchase agreements or catalog quotations.

The Purchasing Documents Open Interface handles this automatically. If it cannot find a match between the incoming line in the Update submission and an existing line in Purchasing, it adds the line. To expire a line, the supplier must send an updated Expiration Date for the line. You can expire lines on blanket purchase agreements only.

Note: Once a line has expired, the supplier cannot send more updates to it. If the supplier does send an update to an expired line, the update is treated as a new line to be added to the blanket purchase agreement.