po1103b

Oracle Purchasing Documentation Update

Purchasing Documents Open Interface

Release 10.7 and 11.0

April 1999

Oracle Purchasing Documents Open Interface Documentation UpdateRelease 10.7 and 11.0

Copyright � 1998, 1999, Oracle Corporation. All Rights Reserved.

Contributing Authors: Rachel Haas

Contributors: Imran Ali, Barbara Hibino, John Houghton, Dave Stephens, Gopi Tummala,James Wang

The Programs (which include both the software and documentation) contain proprietaryinformation of Oracle Corporation; they are provided under a license agreementcontaining restrictions on use and disclosure and are also protected by copyright, patentand other intellectual and industrial property laws. Reverse engineering, disassemblyor decompilation of the Programs is prohibited.

The information contained in this document is subject to change without notice. If youfind any problems in the documentation, please report them to us in writing. OracleCorporation does not warrant that this document is error free. Except as may be expresslypermitted in your license agreement for these Programs, no part of this document may bereproduced or transmitted in any form or by any means, electronic or mechanical, for anypurpose, without the express written permission of Oracle Corporation.

If the Programs are delivered to the US Government or anyone licensing or using thePrograms on behalf of the US Government, the following notice is applicable:

Restricted Rights NoticePrograms delivered subject to the DOD FAR Supplement are ’commercial computersoftware’ and use, duplication and disclosure of the Programs including documentationshall be subject to the licensing restrictions set forth in the applicable Oracle licenseagreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulationsare ’restricted computer software’ and use, duplication and disclosure of the Programsshall be subject to the restrictions in FAR 52.227–19, Commercial Computer Software –Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, orother inherently dangerous applications. It shall be licensee’s responsibility to take allappropriate fail–safe, back–up, redundancy and other measures to ensure the safe use ofsuch applications if the Programs are used for such purposes, and Oracle disclaims liabilityfor any damages caused by such use of the Programs.

Oracle is a registered trademark, and Enabling the Information Age, Oracle Workflow,PL/SQL, and SQL*Plus are trademarks or registered trademarks of Oracle Corporation.All other company or product names mentioned are used for identification purposes only,and may be trademarks of their respective owners.

Contents

��

�2++ /5 -% �$4 �2,"1(-, *(15 ��

�2,"1(-, * �3$/3($4 ��

�$"-/# ,# �//-/ �/-"$00(,& � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�/(&(, *� �$.* "$� ,# �.# 1$ �2!+(00(-,0 ��

�-2/"(,& ��

�/("$ �/$ )0 ��

##(,& -/ �$*$1(,& �(,$0 (, , �.# 1$ �2!+(00(-, ��

�$3(0(-, �2+!$/(,& ,# /"'(3(,& ��

�$11(,& �. ��

�-,(1-/(,& �/("$ �,"/$ 0$0 ��

�2/"' 0(,& �-"2+$,10 �.$, �,1$/% "$ � !*$ �$0"/(.1(-,0 ��

�$/(3 1(-, ��

�$% 2*1(,& ��

� *(# 1(-, ��

�$0-*3(,& � (*$# �2/"' 0(,& �,1$/% "$ �-40 ��

�/("$�� *$0 � 1 *-& �-1(%(" 1(-, �-/)%*-4 � � � � � � � � � � � � � � � � � � � � � � � � �

�-/)%*-4 �201-+(6 1(-, �2(#$*(,$0 ��

1Purchasing Documents Open Interface

Purchasing Documents Open Interface

You can automatically import and update price/sales cataloginformation and request for quotation (RFQ) responses from suppliersthrough the Purchasing Documents Open Interface. The PurchasingDocuments Open Interface uses Application Program Interfaces (APIs)to process catalog data in the Oracle Applications interface tables toensure that it is valid before importing it into Oracle Purchasing. Aftervalidating the price/sales catalog information or RFQ responses, thePurchasing Documents Open Interface program converts theinformation, including price break information, in the interface tablesinto blanket purchase agreements or catalog quotations in Purchasing.

You can choose whether to import the data as blanket purchaseagreements or catalog quotations. You can also choose to update youritem master and apply sourcing rules and release generation methodsto the imported item for both blanket purchase agreements andquotations. Blanket purchase agreements or quotations can also bereplaced with the latest price/sales catalog information when yoursupplier sends a replacement catalog, or updated when the suppliersends an updated catalog.

One way to import price/sales catalog data is through Electronic DataInterchange (EDI). The Purchasing Documents Open Interfacesupports the EDI transmissions of the price/sales catalogs (ANSI X12832 or EDIFACT PRICAT) and responses to RFQs (ANSI X12 843 orEDIFACT QUOTES).

Summary of New Functionality

If you already use a previous version of the Purchasing DocumentsOpen Interface, you know your supplier can send original orreplacement price/sales catalogs in the form of blanket purchaseagreements and catalog quotations. Now, the Purchasing DocumentsOpen Interface also enables the supplier to update existing blanketpurchase agreements and catalog quotations with the price/salescatalog information, without replacing the documents entirely.

The Update submission consists of the following functionality:

• An update of the unit Price, item Description, unit of measure(UOM), Price Breaks, and Expiration Date on existingdocuments.

If your catalog quotation or blanket agreement uses a descriptiveflexfield to reference suppliers’ Web sites, the supplier URL is

2 Oracle Purchasing Documents Open Interface Documentation Update

also updated if sent. The supplier URL descriptive flexfieldcorresponds to the line–level column, ATTRIBUTE14. See: OracleApplications Flexfields Guide.

The Expiration Date is a new field on a blanket purchaseagreement, available with Release 11 only. The Expiration Datecan also be sent by the supplier in an original or replacementprice/sales catalog. See the Oracle Purchasing Expiring BlanketLines Documentation Update.

• A price tolerance feature that flags incoming prices exceeding amaximum price increase that you set.

For each document whose price is increased over the toleranceyou set, you receive a notification, and can respond with Acceptor Reject to the price increase in the new Exceeded PriceTolerances window. Notifications are generated if you entervalues in the Price Update Tolerance fields in the ApprovedSupplier List window or the blanket purchase agreements, or inthe PO: Price Tolerance (%) for Catalog Updates profile option.

If you’re using Release 10.7: The price tolerance feature is notavailable with Release 10.7.

See: Monitoring Price Increases: page 22.

• The ability to add or expire individual item lines on a document.

The Purchasing Documents Open Interface handles thisautomatically. If it cannot find a match between an incoming linein the Update submission and an existing line in Purchasing, itadds the line. To expire a line (on agreements only), the suppliermust send an updated expiration date.

If you’re using Release 10.7: The ability to expire lines on ablanket purchase agreement using the Expiration Date is notavailable with Release 10.7. Release 10.7 does not include theExpiration Date feature. Therefore, in Release 10.7 you can addlines but not delete them.

These enhancements to the Purchasing Documents Open Interface areintroduced in Maintenance Pack 11.0.3.

This document replaces the Purchasing Documents Open Interfacesection of the Oracle Manufacturing, Distribution, Sales and Service OpenInterfaces Manual, Release 11. If you’re using these enhancements to thePurchasing Documents Open Interface, you can replace that sectionwith this document.


Release 10.7

Enhancements to the Purchasing Documents Open Interface are alsoavailable in a separate patch for Release 10.7.

The following table summarizes the main differences between Release10.7 and 11 of the enhanced Purchasing Documents Open Interface.

Functionality Release 11 Release 10.7

Update of Price, itemDescription, UOM, and

price breaks

Release 11 Release 10.7

Expiration of blanket lines Release 11 –

Addition of documentlines

Release 11 Release 10.7

Price tolerance checking Release 11 –

Workflow notification ofexceeded price tolerances

Release 11 –

Update of UOM onagreement if open release

exists

Release 11 –

Table 1 Release 10.7 Summary of Features (Page 1 of 1)


Functional Overview

PurchasingDocuments

Open Interface

Oracle EDIGateway

APIs

PO_ LINES_INTERFACE

PO_ HEADERS_INTERFACE

EDITranslator

ElectronicTransmission

ServiceProvider

The importscriptsthat

populatethe

interfacetables

Value–AddedNetwork(VAN)

or Internet

Supplieror

TradingPartner

Figure 1

OraclePurchasing

The figure above shows the flow of price/sales catalog informationfrom the supplier or trading partner, to Oracle EDI Gateway, to thePurchasing Documents Open Interface, and finally into Purchasing.The PO_HEADERS_INTERFACE and PO_LINES_INTERFACE tablescan also be loaded manually, through a program you write.

If you load the interface tables through EDI Gateway, then the suppliermust provide the price/sales catalog information as a flat file using anEDI translator according to the EDI interface file definitions. Then, theEDI Catalog Inbound program (or the EDI Response to RFQ Inboundprogram) loads the information into the PO_HEADERS_INTERFACEtable and the PO_LINES_INTERFACE table, which includes line,shipment, and price break information.

In the Parameters window of the EDI Catalog Inbound program (orEDI Response to RFQ Inbound program), you specify the name of theflat file and designate how the data sent by the supplier is to beused—if blanket purchase agreements or catalog quotations are to becreated, if items are created or updated in the item master, if sourcing


rules are created or updated. (You also specify the location of the flatfile through an EDI Gateway profile option. See: Oracle EDI GatewayUser’s Guide.)

The EDI inbound program and the Purchasing Documents OpenInterface program are run as a request set when you choose SubmitRequest in the EDI import programs window. The EDI inboundprogram loads the interface tables; the Purchasing Documents OpenInterface program validates the data and loads the validated data intoPurchasing.

Note: You can also run the Purchasing Documents OpenInterface program separately in the Submit Request window inPurchasing, after the data is loaded into the interface tables.

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

The Purchasing Documents Open Interface program receives the data,derives and defaults any missing data, and validates the data. If noerrors are found in the submission process, the data in the PurchasingDocuments Open Interface tables is loaded into the PO_HEADERS,PO_LINES, and PO_LINE_LOCATIONS tables in Purchasing to createthe blanket purchase agreement or catalog quotation, including pricebreaks if any. The creation of items (if you allow updating of the itemmaster) or sourcing rules also populates the corresponding tables (suchas MTL_SYSTEM_ITEMS, ASL_ITEMS, ASL_SUPPLIERS, andASL_DOCUMENTS).

If the Purchasing Documents Open Interface program finds errors inthe interface tables, such as incomplete information from the supplier,the record identification number and the details of the error are writtento the PO_INTERFACE_ERRORS table. You can launch the PurchasingInterface Errors Report in Purchasing to view the rows that were notimported by the Purchasing Documents Open Interface along with thefailure reason(s) for each row.

Record and Error Processing

To detect errors, the Purchasing Documents Open Interface programfirst processes a record from the PO_HEADERS_INTERFACE table.Then, the program processes the child records in thePO_LINES_INTERFACE table before going on to the nextPO_HEADERS_INTERFACE record.

☞


If the program gets an error while processing a record, the programwrites the error details to the PO_INTERFACE_ERRORS table andincrements the record’s error counter. It then flags the record as ”NotProcessable.”

The Purchasing Documents Open Interface saves or errors out on aline–by–line basis. This means that if an error is found in a documentline, only that line is rolled back (not submitted to Purchasing), and youcan find the error in the PO_INTERFACE_ERRORS table. Because thePurchasing Documents Open Interface saves or errors out line by line,it can accept partial documents.

If an error is found in a header, none of its lines are processed. ThePurchasing Documents Open Interface rolls back the header, does notprocess its lines, and does the following:

• Sets the PROCESS_CODE column value to REJECTED in thePO_HEADERS_INTERFACE table.

• Writes out the record identification number and the details of theerror to the PO_INTERFACE_ERRORS table.

• Begins processing the next header record.

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

In Release 11 only, when the supplier sends an updated price/salescatalog, the Purchasing Documents Open Interface sets thePROCESS_CODE column to NOTIFIED for those lines with prices thatexceed your price tolerance. For these price updates only, thePurchasing Documents Open Interface waits for you to accept or rejectthe price increase in the Exceeded Price Tolerances window beforecompleting or rejecting the price change.

Attention: It is important to check the Purchasing InterfaceErrors report (a report of the errors in thePO_INTERFACE_ERRORS table) after you import theprice/sales catalog. Because the Purchasing Documents OpenInterface saves or errors out line by line, it can accept partialdocuments. Therefore, to see which document lines were notsubmitted because of errors, you must check the PurchasingInterface Errors report.


Original, Replace, and Update Submissions

If you are using EDI Gateway to import the data (in the form of flatfiles) into the Purchasing Documents Open Interface, your supplier cansend you a flat file with one of three action codes (in the ACTIONcolumn of the PO_HEADERS_INTERFACE table): Original, Replace,or Update. If you’re not using EDI Gateway, your import programneeds to specify the action code.

Your supplier should use the Original action code for a new price/salescatalog submission, and Replace or Update action codes for subsequentsubmissions.

Original

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

Choose Original when you’re submitting price/sales cataloginformation for the first time.

For an Original submission, the Purchasing Documents Open Interfacefirst checks if a document in the submission already exists inPurchasing. It checks for a document with the same supplier documentnumber (VENDOR_DOC_NUM) and supplier (VENDOR_ID orVENDOR_NAME) that is not finally closed or canceled. If an active,matching document already exists, the document in the Originalsubmission is not created and an error is logged in the PurchasingInterface Errors report.

Replace

A file with an action code of Replace replaces already–created blanketpurchase agreements or catalog quotations with new documentscontaining the new price/sales catalog information. The PurchasingDocuments Open Interface replaces these documents by doing thefollowing:

• First, it looks for documents that have the same document type(DOCUMENT_TYPE_CODE), supplier (VENDOR_ID orVENDOR_NAME), and supplier document number(VENDOR_DOC_NUM) as the replacement documents. (Asupplier document number is a field that is specified in the flatfile that the supplier sends.)

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


• Then, it invalidates the old documents by setting their expirationdates to START_DATE –1 (the start date, minus one day) andcreates new documents with the new price/sales cataloginformation, within the original effectivity dates.

Choose Replace when you want to replace the whole documentbecause most of its fields, header, and line information have changed orare out of date.

As with an Original submission, the Purchasing Documents OpenInterface checks that there are no duplicate documents in Purchasing,but it does not consider finally closed or canceled documents asduplicates. That is, if two documents in Purchasing match an incomingdocument in the Replace submission, Purchasing replaces the one thatis not canceled or finally closed. If one document in Purchasingmatches 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 informationon already–submitted blanket purchase agreements or catalogquotations without creating completely new documents:

• Unit Price

In Release 11 only, if the price update exceeds the price toleranceyou set, the price and price breaks are not updated until orunless the buyer accepts the price update in the Exceeded PriceTolerances window. Any other updates, however, are made tothe document when the price/sales catalog is imported.

The price is updated on the document only, not in the itemmaster. Only the item description is updated in the item master,if you’ve enabled item description updates as described inSetting Up: page 16.

• Item Description

• UOM

• Price Breaks (for blanket purchase agreements)

• Expiration Date (for blanket purchase agreements)

• URL descriptive flexfield (if you have one)


A URL descriptive flexfield provides a supplier URL foradditional information about an item.

Expired lines in Purchasing (lines whose Expiration Date has beenreached) do not get updated. An Update submission for an expiredline is treated as a new line to be added to the blanket purchaseagreement. Finally closed or canceled documents, or those that are nolonger effective, do not get updated.

Choose Update when you want to update the fields listed above onexisting documents, and you want to preserve the existing documents’sourcing rules. For example, an Update submission can be used fordaily, weekly, or even quarterly updates to existing documents, whilefor annual or bi–annual updates, a Replace submission may be betterfor your business needs.

When the Purchasing Documents Open Interface updates a line on ablanket purchase agreement, it does not update the open release forthat line. Only future releases use the updated information.

Note: The Purchasing Documents Open Interface cannot update theUOM on an agreement line for which an open release exists. Instead,the Purchasing Documents Open Interface uses the Expiration Datefield to expire the line on the agreement, and creates a new line withthe updated UOM. This is done only if the UOM is updated on anagreement line for which an open release exists.

If you are using Release 10.7: Since the Expiration Date is notavailable with Release 10.7, Purchasing cannot update theUOM on an agreement line if an open release exists against theline, and will give an error in the Purchasing Interface ErrorsReport. If an open release doesn’t exist against the line, theUOM can be updated.

The Purchasing Documents Open Interface updates documents bydoing the following:

• First, it identifies the catalog quotation or blanket purchaseagreement that needs to be updated by comparing the supplierdocument number (VENDOR_DOC_NUM in thePO_HEADERS_INTERFACE table) with the existing supplierdocument number (VENDOR_ORDER_NUM for a blanketagreement or QUOTE_VENDOR_QUOTE_NUMBER for acatalog quotation in the PO_HEADERS table). The supplier(VENDOR_ID or VENDOR_NAME) and document type(DOCUMENT_TYPE_CODE) must also match. The PurchasingDocuments Open Interface matches only to currently orfuture–effective documents that are not canceled or finallyclosed.


• Next, the Purchasing Documents Open Interface processes all thechanged lines in the PO_LINES_INTERFACE table. It identifieswhich lines on the existing documents need to be updated bymatching 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 theitem number used by your organization (along with the revisionnumber and item category), and so on.

If more than one line on the existing document matches theincoming line, the Purchasing Documents Open Interfaceupdates the first line on the existing catalog quotation or blanketpurchase agreement that matches the incoming line. This firstline is also the line that is picked up for sourcing, as long as it hasnot expired.

For a one–time item, the item description is updated only if asupplier item number (VENDOR_PRODUCT_NUM) is providedand can be used to find a matching line on the originaldocument.

The following figure shows the flow of an Update price/sales catalogsubmission to Purchasing:


Figure 2 Update Submission Process


Sourcing

When you import price/sales catalog information into Purchasing, youhave the option of choosing Yes or No in the Create Sourcing Rulesfield in the Parameters window to enable Purchasing to create sourcingrules out of the supplier, item, and document information that thesupplier sends.

For Original or Replace Submissions

If you choose Yes to create sourcing rules in an Original or Replacesubmission, Purchasing checks if a sourcing rule is assigned to the itemat the item level and does the following:

• If no sourcing rules exist for the item, Purchasing generates asourcing rule automatically, allocating 100 percent to the supplierproviding the information.

• If a sourcing rule exists for the item, Purchasing compares theeffectivity dates of the incoming document with those of theexisting sourcing rule for the item. To ensure that only onesourcing rule is used for the item, Purchasing does the following:

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

– If the effectivity dates of the incoming document aredifferent than the existing sourcing rule’s effectivity dates,but are within or overlap the existing effectivity dates, thena new sourcing rule is not created, so as not to conflict withthe existing sourcing rule.

– If the effectivity dates of the incoming document do notoverlap the existing sourcing rule’s effectivity dates,Purchasing updates the item’s sourcing rule with the neweffectivity dates, adding the supplier at an allocation of 100percent.

• Purchasing checks for an Approved Supplier List entry for theitem and supplier/site combination. If an entry exists,Purchasing adds the document to the entry. If an entry does notexist, Purchasing creates a new entry with the new sourcedocument.


For the Update Submission

If you choose Yes to create sourcing rules in an Update submission,new sourcing information is created (as described above) only if theUpdate submission results in a new line being created. See: Adding orDeleting Lines in an Update Submission: page 15.

Price Breaks

All action codes (Original, Replace, and Update) support the importingof price breaks through the Purchasing Documents Open Interface.

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

For Original or Replace Submissions

The following, additional columns are required in thePO_LINES_INTERFACE table if you want to import price breakinformation:

• LINE_NUM

• SHIPMENT_NUM

• QUANTITY

• UNIT_PRICE

If you are importing price break information through catalogquotations, you can also optionally populate the following columns inthe PO_LINES_INTERFACE table:

• MIN_ORDER_QUANTITY

• MAX_ORDER_QUANTITY

Recall that the PO_LINES_INTERFACE table contains both line andshipment information, and imports data into both the PO_LINES andPO_LINE_LOCATIONS tables in Purchasing. So if you wanted tocreate two price breaks corresponding to one blanket agreement orquotation line, you would create two records in thePO_LINES_INTERFACE table. That is, one header– level record in thePO_HEADERS_INTERFACE table would have two records in thePO_LINES_INTERFACE table, and both of these line records wouldhave the same INTERFACE_HEADER_ID:

☞


• One header– level record (row) in thePO_HEADERS_INTERFACE table corresponds to:

– Line 1: one line– level record (row) in thePO_LINES_INTERFACE table, with Shipment 1 informationincluded

– Line 1: the same line– level record (another row) in thePO_LINES_INTERFACE table, with Shipment 2 informationincluded

When two or more lines with the same line and item number areimported into the PO_LINES_INTERFACE table, the PurchasingDocument Open Interface treats the subsequent lines as price breaksbelonging to the first line.

For the Update Submission

If the supplier updates an item’s price, the Purchasing DocumentsOpen Interface deletes the item’s price breaks since they are no longercurrent with the new price. If the supplier sends new price breaks foran existing line, the current price breaks are deleted and the new pricebreaks sent by the supplier are created.

Just as with an Original or Replace submission, in an Updatesubmission, when two or more lines with the same line and itemnumber are imported into the PO_LINES_INTERFACE table, thePurchasing Document Open Interface treats the subsequent lines asprice breaks belonging to the first line.

Attention: In an Update submission, the order of the line andits price breaks is important. If you are writing your ownprogram to populate the interface tables, make sure that theprice break lines (lines with the same line and item number, butdifferent shipment numbers) follow the line to which theybelong in the interface table. Otherwise, the PurchasingDocuments Open Interface will treat them as duplicate lines(and update the previous line with the second). Use theINTERFACE_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 onexisting 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 Updatesubmission and an existing line in Purchasing, it adds the line. Toexpire a line, the supplier must send an updated Expiration Date forthe line. You can expire lines on blanket purchase agreements only, notquotations.

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

If you’re using Release 10.7: The Expiration Date feature is notavailable with Release 10.7. Therefore, the Purchasing DocumentsOpen Interface can add but not expire lines in Release 10.7.

Revision Numbering and Archiving

For the Update action code, the document revision number is increasedevery time the unit Price, item Description, UOM, or Expiration Date isupdated, or when a new line is added (unless Archive on Approval ischosen in the Document Types window and PO: Archive Catalog onApproval is set to No).

For all action codes, a document is archived upon approval or printing,depending on you which option you chose in the Document Typeswindow. When importing price/sales catalog information, you alsohave the option of choosing Approved or Incomplete in the ApprovalStatus field in the Parameters window. See the table in the sectionSetting Up: page 16.

The profile option PO: Archive Catalog on Approval enables you tochoose whether Purchasing archives blanket purchase agreements in aprice/sales catalog submission upon approval. (Quotations are notarchived in Purchasing.)

If Archive on Approval is chosen in the Document Types window inPurchasing and the document is imported as Approved, then:

• Setting PO: Archive Catalog on Approval to Yes archives theprice/sales catalog documents once they are approved— in thiscase, as soon as you import them.


• Setting PO: Archive Catalog on Approval to No does not archivethe price/sales catalog documents. This may be helpful if youreceive frequent price/sales catalog submissions and do notwant Purchasing to take up extra space archiving every change.

If the document is imported as Incomplete (see the table in the sectionSetting Up: page 16), it does not matter how the PO: Archive Catalog onApproval profile option is set. Basic Purchasing functionality archivesthe document later upon approval or later upon printing, depending onthe option chosen in the Document Types window.

If Archive on Print is chosen in the Document Types window,Purchasing archives the imported price/sales catalog documents oncethey are printed.

By default the PO: Archive Catalog on Approval profile option is set toNo. The user can update this profile option. It can also be updated atthe system administrator user, responsibility, application, and sitelevels.

In Release 11, the blanket purchase agreement is archived and itsrevision number increased only after all lines have either been acceptedor rejected in the Exceeded Price Tolerances window.

Note: You can monitor changes to blanket purchase agreements byusing the PO Change History feature. See: Purchase Order Features,Oracle Purchasing User’s Guide.

Setting Up

If you want to import supplier price/sales catalog information into thePurchasing Documents Open Interface through EDI, you need to installand set up EDI Gateway for your organization. See: Oracle EDIGateway User’s Guide.

The concurrent manager(s) that manages all processing also must be setup and running.

Purchasing Setup Requirements

The following setup steps are required before you can import theprice/sales catalog:


Allow Updating of the Item Master

Allowing updating of the item master enables item description changesto be communicated quickly to Purchasing. If you allow updating ofthe item master, the Purchasing Documents Open Interface updates theitem description not just on blanket purchase agreements or quotations,but in the item master as well. Only the item description is updated inthe item master.

To allow updating of the item master:

1. Navigate to the Purchasing Options window and, in the Controloptions region, check Allow Item Description Update. See:Defining Control Options, Oracle Purchasing User’s Guide.

This allows updating of item descriptions.

2. Navigate to the Personal Profiles window and make sure that INV:Default Item Status is set to Active.

This allows updating of item status codes at the site level.

Set Up Default Category Sets

Make sure default category sets are set up appropriately for bothPurchasing and Inventory by performing the following steps:

1. Navigate to the Default Category Sets window by choosing Setup >Items > Categories > Default Category Sets in the Purchasingresponsibility.

Make sure that both Purchasing and Inventory are listed in theFunctional Area column and each has a default Category Setdefined for it.

2. Navigate to the Category Sets window by choosing Setup > Items >Categories > Category Sets in the Purchasing responsibility.

Make sure that you have a default category set each for bothPurchasing and Inventory in the Category Sets window.

If you’ve selected the Enforce List of Valid Categories check box inthe Category Sets window, make sure that the Default Categoryalso appears in that List of Valid Categories. If not, enter it in thelist.

See: Defining Category Sets, Oracle Inventory User’s Guide.


Set the profile option PO: Archive Catalog on Approval

If you typically archive documents on approval, setting this profileoption to No means that Purchasing will not archive those changesmade through the Purchasing Documents Open Interface. See:Revision Numbering and Archiving: page 15.

Set the profile option PO: Write Server Output to File

Set this profile option when you are debugging the PurchasingDocuments Open Interface. When you import a price/sales catalogwith a large number of items (about 100 or more), the concurrentmanager details log (viewable through the View Log button in theSubmit Request window) can overflow and create errors. The profileoption PO: Write Server Output to File enables you to write these logdetails to a flat file in the $APPL_TOP/log directory to avoid thisoverflow.

If you set this profile option to Yes, the log details are written to a flatfile, which will not overflow. If you set this profile option to No, thelog details are written to the concurrent manager log screen as usual,which can cause overflow problems for large catalogs. If you leave thisprofile option blank, log details are not written at all, which improvesperformance. By default, the profile option is left blank.

The user can update this profile option. It can also be updated at thesystem administrator user, responsibility, application, and site levels.

Note: This profile option applies to the Purchasing DocumentsOpen Interface only.

To write log details to a file using Oracle Applications setup:

1. Set PO: Write Server Output to File to Yes.

2. After you run the Purchasing Documents Open Interface, look for asystem– generated log file in the $APPL_TOP/log directory.

To debug using SQL*Plus, do the following before you run thePurchasing Documents Open Interface:

1. Set PO: Write Server Output to File to Yes.

2. Make sure the directory for the log file you want to write to in thenext step is set in the environment variable APPLPTMP and that it islisted in the UTL_FILE_DIR parameter in the init.ora file.

3. Specify the file name using FND_FILE.put_names(’logfile’,’outfile’, ’directory’);

For example:


fnd_file.put_names(’mylog.log’, ’myout.out’,

’/sqlcom/out’);

This will create a file called mylog.log in the /sqlcom/outdirectory. It is better to use /sqlcom/out because of write– accessissues. If you have problems writing to the file, log into themachine where the database is installed.

Set the Price Tolerance for the Update Submission (Release 11 Only)

Define your price tolerance for price increases in an Updatesubmission. Optionally use function security to control buyers’ accessto the Exceeded Price Tolerances window. See: Monitoring PriceIncreases: page 22.

If you’re using Release 10.7: The price tolerance feature is notavailable with Release 10.7.

Set the Workflow Timeout for the Update Submission (Release 11 Only)

If you import an Update price/sales catalog, decide whether you wantto keep the default Timeout of seven days after notifying the buyer of aprice update that exceeded the price tolerance. The default Timeout ofseven days means if the buyer does not respond after seven days, thebuyer will receive the notification again. If want to change thisTimeout period, use the Workflow Builder. See: Catalog Price UpdateApproval Workflow: page NO TAG.

For the Timeout feature to work, you must also submit the WorkflowBackground Process. See: To Schedule Background Engines, OracleWorkflow Guide.

If you’re using Release 10.7: The price tolerance feature, including thisworkflow for notifying buyers of exceeded price tolerances, is notavailable with Release 10.7.

Importing the Price/Sales Catalog

The import programs window in EDI Gateway initiates both the EDICatalog Inbound program (or EDI Response to RFQ Inbound program)to import the data from the supplier, and the Purchasing DocumentsOpen Interface program to import the data into Purchasing.

☞


After you submit the information in the Parameters window, make noteof the Request ID number by selecting View My Requests from theHelp menu so that you can later view the status of your submission.

Note: The Purchasing Documents Open Interface program isalso available separately in the Requests window inPurchasing, after you’ve successfully loaded the price/salescatalog data into the PO_HEADERS_INTERFACE andPO_LINES_INTERFACE tables.

Commit Interval

The Purchasing Documents Open Interface no longer uses this field tocommit a certain number (Commit Interval) of documents at a time.Instead, it automatically commits or errors out the price/sales catalogline by line. Anything you enter in this field is ignored. See: Recordand Error Processing: page 5.

Attention: It is important to check the Purchasing InterfaceErrors report after you import the price/sales catalog. Becausethe Purchasing Documents Open Interface saves or errors outline by line, it can accept partial documents. Therefore, to seewhich document lines were not submitted because of errors,you must check the Purchasing Interface Errors report.

Create Sourcing Rules

If you choose Yes in the Create Sourcing Rules field, make sure theApproval Status field for the submitted documents is Approved.


Sourcing rules can be created only when the Purchasing documentshave a status of Approved. See also: Sourcing: page 12.

Approval Status

The following table shows the effects of the import Approval Status ona document’s current status, when you import an Update price/salescatalog.

Current Document Status Import Status

Import as Incomplete Import as Approved

Incomplete Document remainsIncomplete

Document changes toApproved

Approved Document remainsApproved

Document remainsApproved

Table 2 Document Status in Update Submission (Page 1 of 1)

Note that while a document is Incomplete, you cannot source from ituntil it is approved. Even in an Update submission, where you areupdating only certain lines on a blanket purchase agreement or catalogquotation, if you choose Incomplete, the entire document, including thelines that weren’t updated, is considered Incomplete.

Purging the Open Interface Tables after Importing the Catalog

The ability to purge the open interface tables after you import theprice/sales catalog into Purchasing is available with Release 11 only.

If you want to purge data in the open interface tables after you haveimported the data into Purchasing, use the Purge PurchasingDocuments Open Interface Processed Data program, available throughthe Submit Request window in Purchasing. (This program removesdata that has been accepted or rejected, not data that is still pending.)To remove data from the Purchasing Interface Errors table, set thePurge Data field in the Purchasing Interface Errors Report to Yes; theerrors will not reappear the next time you run the report.

See Also

Purchasing Documents Open Interface, Oracle Purchasing User’s Guide

Purchasing Interface Errors Report, Oracle Purchasing User’s Guide

Inbound Price/Sales Catalog (832/PRICAT), Oracle EDI Gateway User’s Guide


Inbound Response to Request for Quote (843/QUOTE), Oracle EDIGateway User’s Guide

Monitoring Price Increases

The ability to monitor price increases, including the Price UpdateTolerance Field and the notifications of exceeded price tolerancesdescribed in this section, is available with Release 11.0.3 only.

In Release 10.7

In Release 10.7, any price increases the supplier sends are appliedautomatically to the documents in Purchasing. If you still want tomonitor price changes, do the following:

• Make sure the imported price/sales documents are archived onapproval (see: Revision Numbering and Archiving: page 15).

• Use the PO Change History in the Purchasing menu to view alldocument changes. Or create a custom report that isolates onlyprice changes.

In Release 11

In Release 11, optionally set a price update tolerance in theSupplier–Item Attributes window, on the blanket purchase agreement,or in the PO: Price Tolerance (%) for Catalog Updates profile option.

If a price update in an Update price/sales catalog exceeds yourtolerance, the buyer receives a notification for each affected documentin the Notifications Summary window. From there, the buyer canaccess the Exceeded Price Tolerances window and accept or reject theprice increase.

The Purchasing Documents Open Interface Update submission makesall changes to documents except price changes that have exceeded yourprice tolerance. For these lines only, the Purchasing Documents OpenInterface waits for the buyer to accept or reject the price increases in theExceeded Price Tolerances window before completing or rejecting theprice change. All other line changes, however, are made.

Purchasing performs the price tolerance check against the price on thecurrent revision of the document. The price tolerance check isperformed only on Update price/sales catalog submissions and only onprice increases. If the price decreases, Purchasing does not check thedecrease against your tolerance or notify you of the decrease.


The Exceeded Price Tolerances window can also be used with functionsecurity to control buyers’ access to it.

� To limit buyers’ access to the Exceeded Price Tolerances window:

� Exclude the Accept/Reject Exceeded Price Tolerances subfunctionfrom the buyer’s responsibility.

Buyers can then only view the Exceeded Price Tolerances window.

See: Overview of Function Security, Oracle Applications SystemAdministrator’s Guide. See: Forms and Subfunctions, OracleApplications System Administrator’s Guide.

� To set the price update tolerance:

1. Specify a price update tolerance at any of the following levels:

• The Price Update Tolerance field on the original blanketpurchase agreement, in the Terms and Conditions window.

• The Price Update Tolerance field in the Supplier–Item Attributeswindow, at the item–supplier level.

Example


• The Price Update Tolerance field in the Supplier–Item Attributeswindow, at the commodity–supplier level.

• The PO: Price Tolerance (%) for Catalog Updates profile option ifyou want the price tolerance to apply to everything, not just tospecific documents, or supplier–item or supplier–commoditylevels

For blanket purchase agreements, Purchasing uses the first pricetolerance it finds to determine the price tolerance: it looks first atthe document, then the item level in the Approved Supplier List,then the category level in the Approved Supplier List, then theprofile option. For quotations, since you cannot define a pricetolerance at the document level, Purchasing looks first at the itemlevel in the Approved Supplier List, then the category level in theApproved Supplier List, then the profile option. If you set oneprice update tolerance, it does not default to the other levels. Ifyou set more than one price update tolerance, Purchasing uses thefirst one it finds in the order described here. If no Price UpdateTolerance is set at any of these levels, then Purchasing performs noprice tolerance checking.

If you set the Price Update Tolerance field to 20 at theitem–supplier level in the Supplier–Item Attributes window (andyou haven’t set the price tolerance on the agreement), a priceincrease of more than 20 percent for that item and supplier will


send the buyer a notification. If you set the Price Update Toleranceto 20 on the agreement, a price increase of more than 20 percent onthat document will issue a notification. If you set the Price UpdateTolerance to 0, and you haven’t set it to something else at a lowerlevel, then no automatic price updates are allowed. That is, youwill receive a notification of every price increase that occurs.

Note: The Price Tolerance field in the Purchasing Optionswindow has nothing to do with these Price Update Tolerancefields.

The Price Update Tolerance fields and profile option apply only todocuments in a price/sales catalog submission.

� To accept or reject price increases:

1. After the price/sales catalog is imported into Purchasing, navigateto the Exceeded Price Tolerances window.

To navigate to the Exceeded Price Tolerances window from theNavigator, choose Purchasing Orders > Exceeded Price Tolerances.

To navigate to the Exceeded Price Tolerances window from thenotification, open the Notifications Summary window and look fora notification titled Price tolerance exceeded during BLANKET updateor Price tolerance exceeded during QUOTATION update.

Select the notification and choose Open.


Choose the Open Document icon to open the Exceeded PriceTolerances window.

The updated document’s header information is displayed at thetop of the window. Its lines whose price updates exceeded theprice tolerance are displayed below. You cannot change the pricehere, but simply accept or reject it.


Document Status: Approval Status of Approved or Incompleteentered in the Parameters window when importing the price/salescatalog, for your reference. You cannot change this field.

Rev – Item revision number.

Current Price: The current price of the item in Purchasing.

New Price: The updated price in the price/sales catalogsubmission. This price has exceeded your price tolerance.

Increase (%): Percentage by which the price of the current item onthe document was exceeded.

Tolerance (%): The price tolerance that is set in Purchasing for thisitem.

Price Increase: The difference between the original price and theupdated price.

2. Choose Price Breaks to view price break changes, if any.


You cannot modify the price breaks in this window. If you do notwant to accept the price update or the new price breaks, chooseReject in the next step.

3. In the Action column, choose Accept or Reject to accept or rejecteach price update.

Accept: The price update to the document line is accepted.

Reject: The price is not updated on the document. Any otherchanges to the line—to the item Description, UOM, ExpirationDate, or URL descriptive flexfield—have already been made. Onlythe price update is not made. If you’ve customized the price/salescatalog workflow, you can enable the Reject action to send thesupplier a notification that the price update for this item has beenrejected. See: Price/Sales Catalog Notification Workflow: page 56.

4. Save your work.

Purchasing Documents Open Interface Table Descriptions

Values for the columns in the PO_HEADERS_INTERFACE andPO_LINES_INTERFACE tables can come from multiple sources. Yoursuppliers can send the data, you can enter data yourself through theParameters windows in the EDI Catalog Inbound program or EDIResponse to RFQ Inbound program, and the Purchasing DocumentsOpen Interface program in Purchasing can derive (or default) some ofthe data into the Purchasing tables. Most of the columns in these tablescorrespond to columns in the PO_HEADERS and PO_LINES tables inPurchasing.

Most of the column descriptions below that end with ID refer tointernal identifier columns that uniquely identify a row in a table in


Purchasing. The INTERFACE_HEADER_ID column in thePO_HEADERS_INTERFACE table is the primary key (or uniqueidentifier) for this table that other Purchasing tables can reference.Most other ID columns are foreign keys—or identifiers that point—toother tables in Purchasing. For example, VENDOR_SITE_ID andVENDOR_SITE_CODE point to the PO_VENDOR_SITES table.

Some columns described below are not used currently by thePurchasing Documents Open Interface, but are reserved for futurefunctionality.

The table descriptions below are based on what the PurchasingDocuments Open Interface itself requires, whether the data is importedthrough EDI Gateway or a program you write. The followingdefinitions are used:

The Purchasing Documents Open Interfacerequires these values at a minimum, whether theyare imported through a program you write orthrough EDI Gateway. For example, thePurchasing Documents Open Interface requires avalue for the column INTERFACE_HEADER_ID,but EDI Gateway provides a value automatically.

The Purchasing Documents Open Interface canderive or default columns in this category,depending on whether other values are provided.For example, the column AGENT_ID is a Derivedand/or Defaulted column if a validAGENT_NAME is provided.

You do not have to enter values for columns in thiscategory.

As of this release, the Purchasing Documents OpenInterface does not validate columns in this categorybefore passing them into Purchasing, but hasreserved these columns for future enhancements.Do not enter values in these columns.

See Also

Oracle Purchasing Applications Technical Reference Manual, Release 11

Required

Derived and/orDefaulted

Optional

Reserved forFuture Use


Purchasing Documents Headers Table Description

The following table describes the PO_HEADERS_INTERFACE table.

PO_HEADERS_INTERFACEColumn Name Type Required

Derivedand/or

Defaulted Optional

Reservedfor Future

Use

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

INTERFACE_HEADER_ID ÁÁÁÁÁÁ

NumberÁÁÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁBATCH_ID ÁÁÁ

ÁÁÁNumberÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ


INTERFACE_SOURCE_CODEÁÁÁÁÁÁÁÁÁ

Varchar2ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁÁ



�


PROCESS_CODE ÁÁÁÁÁÁ

Varchar2ÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁACTION ÁÁÁ

ÁÁÁVarchar2ÁÁÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁGROUP_CODE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ORG_IDÁÁÁÁÁÁÁÁÁ

NumberÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ


�ÁÁÁÁÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁDOCUMENT_TYPE_CODE ÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁDOCUMENT_SUBTYPE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁDOCUMENT_NUM

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ


PO_HEADER_IDÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁRELEASE_NUM ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁPO_RELEASE_ID ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


RELEASE_DATEÁÁÁÁÁÁÁÁÁ

DateÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ




�


CURRENCY_CODE ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁRATE_TYPE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁRATE_TYPE_CODE

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



RATE_DATEÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁRATE ÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁAGENT_NAME ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ



AGENT_IDÁÁÁÁÁÁÁÁÁ




�ÁÁÁÁÁÁÁÁÁÁÁÁTable 3 Purchasing Documents Open Interface (Headers) (Page 1 of 5)


Reservedfor Future

UseOptional

Derivedand/or

DefaultedRequiredTypePO_HEADERS_INTERFACEColumn Name

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

VENDOR_NAMEÁÁÁÁÁÁÁÁÁÁÁÁ

Varchar2ÁÁÁÁÁÁÁÁÁÁÁÁ



�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁVENDOR_ID ÁÁÁÁ

ÁÁÁÁNumberÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁVENDOR_SITE_CODE ÁÁÁÁ

ÁÁÁÁVarchar2ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

VENDOR_SITE_IDÁÁÁÁÁÁÁÁÁÁÁÁ

NumberÁÁÁÁÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁÁÁ

VENDOR_CONTACT ÁÁÁÁÁÁÁÁ

Varchar2ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁVENDOR_CONTACT_ID ÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁSHIP_TO_LOCATION ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ


SHIP_TO_LOCATION_IDÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁBILL_TO_LOCATION ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁBILL_TO_LOCATION_ID ÁÁÁÁ


ÁÁÁÁÁÁÁÁ




PAYMENT_TERMSÁÁÁÁÁÁÁÁÁÁÁÁ






TERMS_ID ÁÁÁÁÁÁÁÁ

NumberÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁFREIGHT_CARRIER ÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁFOB ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



FREIGHT_TERMSÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁAPPROVAL_STATUS ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁAPPROVED_DATE ÁÁÁÁ

ÁÁÁÁDate ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁREVISED_DATE

ÁÁÁÁÁÁÁÁ

DateÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

REVISION_NUMÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁNOTE_TO_VENDOR ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


NOTE_TO_RECEIVER ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

CONFIRMING_ORDER_FLAGÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁCOMMENTS ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁÁÁTable 3 Purchasing Documents Open Interface (Headers) (Page 2 of 5)


Reservedfor Future

UseOptional

Derivedand/or


ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ACCEPTANCE_REQUIRED_FLAGÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁACCEPTANCE_DUE_DATE ÁÁÁ

ÁÁÁDateÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁAMOUNT_AGREED ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ



AMOUNT_LIMITÁÁÁÁÁÁÁÁÁ





�


MIN_RELEASE_AMOUNT ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁEFFECTIVE_DATE ÁÁÁ


conditionallyÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁEXPIRATION_DATE ÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁPRINT_COUNT ÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



PRINTED_DATEÁÁÁÁÁÁÁÁÁ





�


FIRM_FLAG ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


FROZEN_FLAG ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ




CLOSED_CODEÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁ

CLOSED_DATE ÁÁÁÁÁÁ

DateÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


REPLY_DATE ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁREPLY_METHOD ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


RFQ_CLOSE_DATEÁÁÁÁÁÁÁÁÁ





�


QUOTE_WARNING_DELAY ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁVENDOR_DOC_NUM ÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁAPPROVAL_REQUIRED_FLAG ÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



VENDOR_LISTÁÁÁÁÁÁÁÁÁ





�


VENDOR_LIST_HEADER_ID ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


FROM_HEADER_ID ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ




FROM_TYPE_LOOKUP_CODEÁÁÁÁÁÁÁÁÁ




�ÁÁÁÁÁÁÁÁÁÁÁÁTable 3 Purchasing Documents Open Interface (Headers) (Page 3 of 5)


Reservedfor Future

UseOptional

Derivedand/or


ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

USSGL_TRANSACTION_CODEÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁATTRIBUTE_CATEGORY ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁATTRIBUTE1 ÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ



ATTRIBUTE2ÁÁÁÁÁÁÁÁÁÁÁÁ






ATTRIBUTE3 ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ










ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ









ATTRIBUTE10 ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ










ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁCREATION_DATE

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



CREATED_BYÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁLAST_UPDATE_DATE ÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁLAST_UPDATED_BY ÁÁÁÁ


ÁÁÁÁÁÁÁÁ




LAST_UPDATE_LOGINÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁREQUEST_ID ÁÁÁÁ


ÁÁÁÁÁÁÁÁ


� ÁÁÁÁÁÁÁÁTable 3 Purchasing Documents Open Interface (Headers) (Page 4 of 5)


Reservedfor Future

UseOptional

Derivedand/or



PROGRAM_APPLICATION_IDÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁPROGRAM_ID ÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁPROGRAM_UPDATE_DATE ÁÁÁ


ÁÁÁÁÁÁÁÁ




REFERENCE_NUMÁÁÁÁÁÁÁÁÁ






LOAD_SOURCING_RULES_FLAG ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁVENDOR_NUM ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁFROM_RFQ_NUM ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ

WF_GROUP_ID Number �

Table 3 Purchasing Documents Open Interface (Headers) (Page 5 of 5)

Following is a description of all of the required and conditionallyrequired columns in the PO_HEADERS_INTERFACE table, and someother columns. Remaining column descriptions can be found in theOracle Purchasing Applications Technical Reference Manual, Release 11.

INTERFACE_HEADER_ID Required

This column indicates an identifier for the purchase order or catalogheader. If you import price/sales catalog information through EDIGateway, this identifier is provided automatically.

BATCH_ID Optional

When you import the price/sales catalog information through EDIGateway, it provides a concurrent program grouping identifier for thesubmission.

INTERFACE_SOURCE_CODE Reserved for Future Use

This column identifies the source (for example, EDI Gateway) of theprice/sales catalog data.


PROCESS_CODE Optional

This column indicates the status of a row in the interface table. Itaccepts values of PENDING, ACCEPTED, REJECTED, or NOTIFIED.A PENDING transaction has not yet been processed. An ACCEPTEDtransaction has been successfully processed. A REJECTED transactioncontains an error which shows up in the Purchasing Interface ErrorsReport. A NOTIFIED transaction, which includes a price update thatexceeded the price tolerance, has been communicated to the buyerthrough the Notifications Summary window.

When you import price/sales catalog information through EDIGateway, EDI Gateway defaults a value of PENDING in this columnautomatically. Then, the Purchasing Documents Open Interface sets thevalue to ACCEPTED, REJECTED, or NOTIFIED.

If you’re using Release 10.7: Since price tolerance checking is notperformed in Release 10.7, this column would never have a value ofNOTIFIED in Release 10.7.

ACTION Required

This column indicates whether the price/sales catalog information is anoriginal (new), replacement, or update file. This column accepts valuesof ORIGINAL, REPLACE, or UPDATE.

GROUP_CODE Reserved for Future Use

This column indicates an identifier for the batch being imported.

DOCUMENT_TYPE_CODE Required

This column accepts values of BLANKET or QUOTATION. It isrequired to match incoming documents with existing documents.

VENDOR_NAME Optional

This column indicates the supplier for the document. Make sure thesupplier is also set up as a trading partner in the EDI Gatewayapplication, if you’re importing data through EDI Gateway. If youenter a VENDOR_ID, you do not have to enter a VENDOR_NAME.

VENDOR_ID Required

This column indicates the supplier identifier number. Make sure thesupplier is also set up as a trading partner in the EDI Gateway


application, if you’re importing data through EDI Gateway. If youenter a VENDOR_NAME, you do not have to enter a VENDOR_ID.

VENDOR_SITE_CODE Required

This column indicates the supplier site for the document. If the supplierhas more than one site, the Purchasing Documents Open Interfacecannot default a site. The site also needs to be set up in EDI Gateway, ifyou’re importing data through EDI Gateway. If you enter aVENDOR_SITE_ID, you do not have to enter a VENDOR_SITE_CODE.

VENDOR_SITE_ID Required

This column indicates the supplier site for the document. If the supplierhas more than one site, the Purchasing Documents Open Interfacecannot default a site. The site also needs to be set up in EDI Gateway, ifyou’re importing data through EDI Gateway. If you enter aVENDOR_SITE_CODE, you do not have to enter a VENDOR_SITE_ID.

EFFECTIVE_DATE Conditionally Required

This column must be populated when replacing an existing purchasingdocument. The value in this column is used to locate the oldprice/sales catalog and expire it.

EXPIRATION_DATE Conditionally Required

This column must be populated when replacing an existing purchasingdocument. The value in this column is used to locate the oldprice/sales catalog and expire it.

VENDOR_DOC_NUM Conditionally Required

This column must be populated when replacing or updating an existingpurchasing document. It is also required to make sure that documentsin an Original submission don’t already exist in Purchasing.

LOAD_SOURCING_RULES_FLAG Optional

This column indicates whether to create sourcing rules with thepurchasing document. You choose this option in the Parameterswindow when importing the price/sales catalog.


Purchasing Documents Lines Table Description

The following table describes the PO_LINES_INTERFACE table.

If you’re using Release 10.7: Since price tolerance checking is notavailable with Release 10.7, the following columns are not used inRelease 10.7: PROCESS_CODE, PRICE_CHG_ACCEPT_FLAG,PRICE_BREAK_FLAG, and PRICE_UPDATE_TOLERANCE.

PO_LINES_INTERFACEColumn Name Type Required

Derivedand/or

Defaulted Optional

Reservedfor Future

Use


INTERFACE_LINE_IDÁÁÁÁÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ


INTERFACE_HEADER_ID ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁACTION Varchar2 �

ACTION_CODE Varchar2 �ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

GROUP_CODEÁÁÁÁÁÁÁÁÁÁÁÁ





�


LINE_NUM ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁPO_LINE_ID ÁÁÁÁ

ÁÁÁÁNumberÁÁÁÁ




ÁÁÁÁÁÁÁÁÁÁÁSHIPMENT_NUM

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



LINE_LOCATION_IDÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁSHIPMENT_TYPE ÁÁÁÁ

ÁÁÁÁVarchar2ÁÁÁÁ




ÁÁÁÁÁÁÁÁÁÁÁREQUISITION_LINE_ID ÁÁÁÁ



ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�

DOCUMENT_NUM Number �


RELEASE_NUM ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


PO_HEADER_ID ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁPO_RELEASE_ID

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�

EXPIRATION_DATE Date �

PROCESS_CODEfor Release 11 only

Varchar2 for internal use only

Table 4 Purchasing Documents Open Interface (Lines) (Page 1 of 8)


Reservedfor Future

UseOptional

Derivedand/or

DefaultedRequiredTypePO_LINES_INTERFACEColumn Name

PRICE_CHG_ACCEPT_FLAGfor Release 11 only


PRICE_BREAK_FLAGfor Release 11 only


PRICE_UDATE_TOLERANCEfor Release 11 only

Number �

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

SOURCE_SHIPMENT_ID ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

CONTRACT_NUMÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

�


LINE_TYPE ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁLINE_TYPE_ID ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁITEM

ÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ


ITEM_IDÁÁÁÁÁÁÁÁÁ



�ÁÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁÁITEM_REVISION ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁCATEGORY ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



CATEGORY_IDÁÁÁÁÁÁÁÁÁ






ITEM_DESCRIPTION ÁÁÁÁÁÁ



� ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁÁÁÁÁVENDOR_PRODUCT_NUM ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁUOM_CODE Varchar2 � �

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

UNIT_OF_MEASUREÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁÁQUANTITY ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁCOMMITTED_AMOUNT ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



MIN_ORDER_QUANTITYÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ



MAX_ORDER_QUANTITY ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁUNIT_PRICE ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁLIST_PRICE_PER_UNIT ÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁ



Reservedfor Future

UseOptional

Derivedand/or



MARKET_PRICEÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁALLOW_PRICE_OVERRIDE_FLAG ÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁNOT_TO_EXCEED_PRICE ÁÁÁÁ



ÁÁÁÁÁÁÁÁ



NEGOTIATED_BY_PREPARER_FLAGÁÁÁÁÁÁÁÁÁÁÁÁ






UN_NUMBER ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁUN_NUMBER_ID ÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁHAZARD_CLASS ÁÁÁÁ



ÁÁÁÁÁÁÁÁ



HAZARD_CLASS_IDÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁNOTE_TO_VENDOR ÁÁÁÁ



ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


TRANSACTION_REASON_CODE ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ

�


TAXABLE_FLAGÁÁÁÁÁÁÁÁÁÁÁÁ






TAX_NAME ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁTYPE_1099 ÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁCAPITAL_EXPENSE_FLAG ÁÁÁÁ



�ÁÁÁÁÁÁÁÁ



INSPECTION_REQUIRED_FLAGÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁRECEIPT_REQUIRED_FLAG ÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁPAYMENT_TERMS ÁÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁTERMS_ID

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁ



PRICE_TYPEÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁMIN_RELEASE_AMOUNT ÁÁÁÁ




� ÁÁÁÁÁÁÁÁPRICE_BREAK_LOOKUP_CODE Varchar2 � �


USSGL_TRANSACTION_CODEÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁCLOSED_CODE ÁÁÁÁ




� ÁÁÁÁÁÁÁÁTable 4 Purchasing Documents Open Interface (Lines) (Page 3 of 8)


Reservedfor Future

UseOptional

Derivedand/or



CLOSED_REASONÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


�


CLOSED_DATE ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ


�


CLOSED_BY ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ


�


INVOICE_CLOSE_TOLERANCEÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


�


RECEIVE_CLOSE_TOLERANCE ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ


�


FIRM_FLAG ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ


�


DAYS_EARLY_RECEIPT_ALLOWED ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



DAYS_LATE_RECEIPT_ALLOWEDÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁENFORCE_SHIP_TO_LOCATION_CODEÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁALLOW_SUBSTITUTE_RECEIPTS_FLAGÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



RECEIVING_ROUTINGÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ



RECEIVING_ROUTING_ID ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁQTY_RCV_TOLERANCE ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁOVER_TOLERANCE_ERROR_FLAG ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



QTY_RCV_EXCEPTION_CODEÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁÁRECEIPT_DAYS_EXCEPTION_CODE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁSHIP_TO_ORGANIZATION_CODE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁSHIP_TO_ORGANIZATION_ID

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁ



SHIP_TO_LOCATIONÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁSHIP_TO_LOCATION_ID ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁNEED_BY_DATE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



PROMISED_DATEÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁACCRUE_ON_RECEIPT_FLAG ÁÁÁ


ÁÁÁÁÁÁÁÁ


�



Reservedfor Future

UseOptional

Derivedand/or



LEAD_TIMEÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁLEAD_TIME_UNIT ÁÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁPRICE_DISCOUNT ÁÁÁÁ



ÁÁÁÁÁÁÁÁ



FREIGHT_CARRIERÁÁÁÁÁÁÁÁÁÁÁÁ






FOB ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁFREIGHT_TERMS ÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁEFFECTIVE_DATE ÁÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁEXPIRATION_DATE

ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁ



FROM_HEADER_IDÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁFROM_LINE_ID ÁÁÁÁ



ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁFROM_LINE_LOCATION_ID ÁÁÁÁ



ÁÁÁÁÁÁÁÁ



LINE_ATTRIBUTE_CATEGORY_LINESÁÁÁÁÁÁÁÁÁÁÁÁ






LINE_ATTRIBUTE1 ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁLINE_ATTRIBUTE2 ÁÁÁÁ



ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ



LINE_ATTRIBUTE4ÁÁÁÁÁÁÁÁÁÁÁÁ








ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ









LINE_ATTRIBUTE8 ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ







�ÁÁÁÁÁÁÁÁÁÁÁÁTable 4 Purchasing Documents Open Interface (Lines) (Page 5 of 8)


Reservedfor Future

UseOptional

Derivedand/or



LINE_ATTRIBUTE12ÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁLINE_ATTRIBUTE13 ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁLINE_ATTRIBUTE14 ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



LINE_ATTRIBUTE15ÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ



SHIPMENT_ATTRIBUTE_CATEGORY ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁSHIPMENT_ATTRIBUTE1 ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



SHIPMENT_ATTRIBUTE3ÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ






ÁÁÁÁÁÁÁÁÁ



SHIPMENT_ATTRIBUTE7 ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ






ÁÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁSHIPMENT_ATTRIBUTE13

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ






ÁÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁLAST_UPDATE_DATE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



LAST_UPDATED_BYÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁÁLAST_UPDATE_LOGIN ÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁTable 4 Purchasing Documents Open Interface (Lines) (Page 6 of 8)


Reservedfor Future

UseOptional

Derivedand/or



CREATION_DATEÁÁÁÁÁÁÁÁÁÁÁÁ

DateÁÁÁÁÁÁÁÁÁÁÁÁ




ÁÁÁÁÁÁÁÁÁÁÁCREATED_BY ÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁREQUEST_ID ÁÁÁÁ






PROGRAM_APPLICATION_IDÁÁÁÁÁÁÁÁÁÁÁÁ






PROGRAM_ID ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁPROGRAM_UPDATE_DATE ÁÁÁÁ


ÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁÁÁORGANIZATION_ID ÁÁÁÁ



�ÁÁÁÁÁÁÁÁ



ITEM_ATTRIBUTE_CATEGORYÁÁÁÁÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁÁÁÁITEM_ATTRIBUTE1 ÁÁÁÁ



ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ



ITEM_ATTRIBUTE3ÁÁÁÁÁÁÁÁÁÁÁÁ






ITEM_ATTRIBUTE4 ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ











ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁITEM_ATTRIBUTE10

ÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁÁÁ











ÁÁÁÁÁÁÁÁ





ÁÁÁÁÁÁÁÁ











ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁÁÁTable 4 Purchasing Documents Open Interface (Lines) (Page 7 of 8)


Reservedfor Future

UseOptional

Derivedand/or



UNIT_WEIGHTÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁWEIGHT_UOM_CODE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁVOLUME_UOM_CODE ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



UNIT_VOLUMEÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ



TEMPLATE_ID ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁ

� ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁTEMPLATE_NAME ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ


ÁÁÁÁÁÁÁÁÁÁÁÁLINE_REFERENCE_NUM ÁÁÁ


ÁÁÁÁÁÁÁÁ

ÁÁÁÁÁÁ



SOURCING_RULE_NAMEÁÁÁÁÁÁÁÁÁ



ÁÁÁÁÁÁÁÁÁ

�ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁTable 4 Purchasing Documents Open Interface (Lines) (Page 8 of 8)

Following is a description of all of the required and conditionallyrequired columns in the PO_LINES_INTERFACE table, and some othercolumns. Remaining column descriptions can be found in the OraclePurchasing Applications Technical Reference Manual, Release 11.

INTERFACE_LINE_ID Required

This column indicates the unique identifier of the line record in thePO_LINES_INTERFACE table. If you import price/sales cataloginformation through EDI Gateway, this identifier is providedautomatically.

INTERFACE_HEADER_ID Required

This column indicates the unique identifier of the header record towhich this line belongs. If you import price/sales catalog informationthrough EDI Gateway, this identifier is provided automatically.

GROUP_CODE Reserved for Future Use

This column indicates an identifier for the batch being imported.


EFFECTIVE_DATE Conditionally Required

If you choose to create sourcing rules with the imported price/salescatalog information, then you need to provide a value in this column.

EXPIRATION_DATE Conditionally Required

In an Original or Replace submission: If you choose to create sourcingrules with the imported price/sales catalog information, then you needto provide a value in this column.

In an Update submission: When updating an existing line, the value inthis column is used to expire the line. When adding a new line, thevalue in this column is still required if you choose to create sourcingrules with the imported price/sales catalog information.

ITEM Conditionally Required

If you want to create items in the item master, then you need to supplythe item information.

Both an ITEM and an ITEM_DESCRIPTION are required if an item isbeing created in the item master.

ITEM_DESCRIPTION Conditionally Required

If you want to create items in the item master, then you need to supplythe item information.

Both an ITEM and an ITEM_DESCRIPTION are required if an item isbeing created in the item master. If an item is being updated, theITEM_DESCRIPTION is required.

SOURCING_RULE_NAME Optional

If sourcing rules are being used, this column indicates the name of thesourcing rule.

PROCESS_CODE Internal Use Only

Used in Release 11 only, this column indicates the status of a row in theinterface table. It is updated internally with values of null (whichmeans PENDING), ACCEPTED, or NOTIFIED. A PENDINGtransaction has not yet been processed. An ACCEPTED transactionhas been successfully processed. A NOTIFIED transaction, whichincludes a price update that exceeded the price tolerance, has beencommunicated to the buyer through the Notifications Summary


window. The Purchasing Documents Open Interface sets the value ofthis column to ACCEPTED or NOTIFIED.

This column is for internal use only. Unless you are debugging theopen interface, do not use a program or script to update this columnyourself.

If you’re using Release 10.7: Since price tolerance checking is notperformed in Release 10.7, a line is never in a NOTIFIED state inRelease 10.7. Therefore, Release 10.7 does not have the line–levelPROCESS_CODE column.

PRICE_CHG_ACCEPT_FLAG Internal Use Only

Used in Release 11 only, this column indicates internally whether aprice has changed in an Update submission. If the PROCESS_CODEvalue is NOTIFIED, NULL means that the item price update ispending—waiting for the buyer to respond with Accept or Reject in theExceeded Price Tolerances window. Y means that the price update wasaccepted. N means that it was rejected.


If you’re using Release 10.7: Since price tolerance checking is notperformed in Release 10.7, Release 10.7 does not have thePRICE_CHG_ACCEPT_FLAG column.

PRICE_BREAK_FLAG Internal Use Only

Used in Release 11 only, this column indicates internally to theExceeded Price Tolerances window whether a price change in anUpdate submission includes price breaks.


If you’re using Release 10.7: Since price tolerance checking is notperformed in Release 10.7, Release 10.7 does not have thePRICE_BREAK_FLAG column.


Derivation

In general, the same derivation and defaulting rules apply to theinterface tables as apply when you enter information in the PurchaseOrders or Quotations windows. For example, the columnITEM_DESCRIPTION is derived or defaulted only if a valid ITEM orITEM_ID is provided.

The Purchasing Documents Open Interface supports column valuepassing by user value; for example, if you provide a VENDOR_NAMEor VENDOR_NUM, the VENDOR_ID is derived. Purchasing uses thederivation source according to the following rules:

• Key (ID) columns always override value columns. If youpopulate both the key column and the corresponding valuecolumn, then the key column is always used for processing. Forexample, if VENDOR_NAME and VENDOR_ID contradict eachother, VENDOR_ID is used.

• Derivation is performed before defaulting, and generallyoverrides defaulting. (Derivation refers to deriving a full valuefrom a partial value given; defaulting refers to using a defaultvalue in Purchasing when no value is given.) For example, if youload the SHIP_TO_LOCATION value in the interface tables,Purchasing derives the SHIP_TO_LOCATION_ID from it insteadof from the default ship–to information associated with yoursupplier.

Defaulting

The Purchasing Documents Open Interface supports the samedefaulting mechanisms as the Purchasing document entry windows.Defaults can come from many sources, such as the Purchasing Options,Financial Options, Suppliers, and Master Item (or Organization Items)windows.

Defaulting rules are applied as follows:

• Defaults do not override values that you specify.

• Default values that are no longer active or valid are not used.


Validation

The Purchasing Documents Open Interface does not validate thosecolumns described as ”Reserved for Future Use” on the previouspages.

Standard Validation

Purchasing validates all required columns in the interface table. Forspecific information on the data implied by these columns, see yourOracle Purchasing Applications Technical Reference Manual, Release 11 fordetails.

Other Validation

The Purchasing Documents Open Interface performs the samevalidation as the Purchasing document entry windows before allowingthe data to be committed to the base tables.

If multiple errors are detected, each error is written to thePO_INTERFACE_ERRORS table and displayed in the PurchasingInterface Errors Report.

Not only are all required columns validated so that they are populatedwith acceptable values, but also errors are signaled for those columnsthat have values but should not. For example, if a RATE_TYPE doesnot need to be defined (because exchange rate information is notneeded) but contains a value, an error will be signaled.

Resolving Failed Purchasing Interface Rows

Error Messages

Purchasing may display specific error messages during interfaceprocessing. For more details on these messages, please see the OracleApplications Message Reference Manual, in HTML format on thedocumentation CD–ROM for Release 11.

A Note about Debugging for Release 11

If you receive an error in a document, you can fix the error andresubmit the document again by reusing a header record in thePO_HEADERS_INTERFACE table using SQL*Plus. If you do this, setthe PROCESS_CODE column in the PO_HEADERS_INTERFACE table


to PENDING and be sure to reset the following columns to NULL forall lines belonging to that header in the PO_LINES_INTERFACE table:

• PROCESS_CODE

• PRICE_CHG_ACCEPT_FLAG

• PRICE_BREAK_FLAG

If you’re using Release 10.7: These columns are not available withRelease 10.7.

Viewing Failed Transactions

You can report on all rows that failed validation by using thePurchasing Interface Errors Report. For each row in the PurchasingDocuments Open Interface tables that fails validation, the PurchasingDocuments Open Interface creates one or more rows with errorinformation in the PO_INTERFACE_ERRORS table. The PurchasingInterface Errors Report lists all the columns in thePO_INTERFACE_ERRORS table that failed validation along with thereason for the failure. This report is generated through the SubmitRequest window and processed as other standard reports inPurchasing.

The following table shows the error messages and their meaning:

Error Message Meaning


PO_PDOI_AMT_LIMIT_LT_AGREED ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Amount Limit (VALUE=&AMOUNT_LIMIT) is less than AmountAgreed (VALUE=&VALUE).

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

PO_PDOI_AMT_LIMIT_LT_RELEASE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Amount Limit (VALUE=&AMOUNT_LIMIT) is less than MinimumRelease Amount (VALUE=&VALUE).


PO_PDOI_AMT_LIMIT_LT_TOTREL ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Amount Limit (VALUE=&AMOUNT_LIMIT) is less than TotalAmount Released (VALUE=&VALUE).

PO_PDOI_CATG_ALREADY_EXISTS Catalog being created with supplierdocument number [DOC_NUMBER]already exists.


PO_PDOI_COLUMN_NOT_NULLÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Column &COLUMN_NAME should not beNULL.


PO_PDOI_COLUMN_NOT_ZERO ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Column &COLUMN_NAME should be 0.

Table 5 Purchasing Documents Open Interface Error Messages (Page 1 of 7)


MeaningError Message


PO_PDOI_COLUMN_NULL ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Column &COLUMN_NAME (VAL-UE=&VALUE) must be NULL.


PO_PDOI_DERV_ERRORÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Derivation Error: &COLUMN_NAME(VALUE= &VALUE) specified is invalid.

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

PO_PDOI_DERV_PART_NUM_ERRORÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Cannot derive ITEM_ID for the specifiedbuyer item_number or VENDOR_PROD-UCT_NUM.


PO_PDOI_DIFF_ITEM_DESC ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Pre–defined item description cannot bechanged for this item.


PO_PDOI_DOC_NUM_UNIQUEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Document Num must have a unique value.&VALUE already exists.


PO_PDOI_EFF_DATE_GT_HEADERÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Effective Date (VALUE =&VALUE) speci-fied should not be less than the effectivedate specified.


PO_PDOI_EXCEED_PRICE_NULL NOTTO EXCEED PRICE (VALUE= &VALUE)


Must be NULL if ALLOW_PRICE_OVER-RIDE_FLAG is N.


PO_PDOI_INVALID_ACTIONÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Action (VALUE= &VALUE) is invalid.


PO_PDOI_INVALID_BILL_LOC_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Bill–To Location ID (VALUE=&VALUE) isnot valid.


PO_PDOI_INVALID_BUYERÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Buyer (VALUE=&VALUE) specified is not avalid buyer.


PO_PDOI_INVALID_CATEGORY_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

CATEGORY ID (VALUE =&VALUE) speci-fied is inactive or invalid.


PO_PDOI_INVALID_CURRENCY ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Currency Code (VALUE =&VALUE) speci-fied is inactive or invalid.


PO_PDOI_INVALID_DISCOUNT ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

DISCOUNT (VALUE =&VALUE) specifiedis invalid.


PO_PDOI_INVALID_DOC_NUM ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Document Number (VALUE= &VALUE)specified is invalid.


PO_PDOI_INVALID_DOC_STATUSÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Sourcing rule can be created only if docu-ment is loaded as an approved document.


PO_PDOI_INVALID_FLAG_VALUE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME (VALUE =&VALUE) isinvalid. It can either be Y or N.


PO_PDOI_INVALID_FOB ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

FOB (VALUE=&VALUE) specified is inac-tive or invalid.





PO_PDOI_INVALID_FREIGHT_CARR ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

FREIGHT CARRIER (VALUE =&VALUE)specified is inactive or invalid.


PO_PDOI_INVALID_FREIGHT_TERMSÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

FREIGHT TERMS (VALUE =&VALUE) spe-cified is inactive or invalid.


PO_PDOI_INVALID_HAZ_IDÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

HAZARD CLASS ID (VALUE =&VALUE)specified is inactive or invalid.


PO_PDOI_INVALID_INTER_LINE_REC ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Record specified in PO_LINES_INTER-FACE is invalid. It is neither a new recordin PO_LINES nor PO_LINE_LOCATIONS.


PO_PDOI_INVALID_ITEM_FLAGÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Item Flag (VALUE= &VALUE) is invalid.


PO_PDOI_INVALID_ITEM_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ITEM ID (VALUE =&VALUE) is not a validpurchasable item.


PO_PDOI_INVALID_ITEM_REVISIONÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

REVISION NUM (VALUE =&VALUE) spe-cified is inactive or invalid.


PO_PDOI_INVALID_ITEM_UOM_CODEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ITEM UOM CODE (VALUE =&VALUE)specified is inactive or invalid.


PO_PDOI_INVALID_LEAD_TIME ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Lead Time Unit (VALUE=&VALUE) speci-fied is inactive or invalid.


PO_PDOI_INVALID_LINE_TYPE_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

LINE TYPE ID (VALUE =&VALUE) speci-fied is inactive or invalid.


PO_PDOI_INVALID_LINE_TYPE_INFO ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME (VALUE=&VALUE)must match the value from thePO_LINE_TYPES table (VAL-UE=&LINE_TYPE).


PO_PDOI_INVALID_LOCATION_REC ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Information specified in PO_LINES_IN-TERFACE table does not match the parentrecord in PO_LINES table.


PO_PDOI_INVALID_NUM_OF_LINES ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME There should be atleast one line per document.


PO_PDOI_INVALID_OP_ITEM_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ITEM ID (VALUE =&VALUE) is not a validpurchasable and outside operational item.


PO_PDOI_INVALID_ORIG_CATALOGÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&DOC_NUMBER specified is not a validoriginal catalog.


PO_PDOI_INVALID_PAY_TERMSÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

PAYMENT TERMS (VALUE =&VALUE)specified is inactive or invalid.





PO_PDOI_INVALID_PRICE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

NOT TO EXCEED PRICE. (VALUE= &VAL-UE) has to be greater or equal to UNITPRICE (VALUE=&UNIT_PRICE).


PO_PDOI_INVALID_PRICE_BREAK ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

PRICE BREAK LOOKUP CODE (VAL-UE=&VALUE) specified is inactive or in-valid.


PO_PDOI_INVALID_PRICE_TYPE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

PRICE TYPE (VALUE =&VALUE) specifiedis inactive or invalid.


PO_PDOI_INVALID_QUOTE_TYPE_CDÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Document Subtype (VALUE= &VALUE)specified is invalid.


PO_PDOI_INVALID_RATE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

The rate value (VALUE=&VALUE) speci-fied is invalid.


PO_PDOI_INVALID_RATE_TYPE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Rate Type (VALUE =&VALUE) specified isinvalid.


PO_PDOI_INVALID_RCV_EXCEP_CDÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

RCV EXCEPTION CODE (VALUE =&VAL-UE) specified is inactive or invalid.


PO_PDOI_INVALID_REPLY_METHODÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

REPLY METHOD (VALUE =&VALUE) spe-cified is inactive or invalid.


PO_PDOI_INVALID_SHIPMENT_TYPEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

SHIPMENT TYPE (VALUE= &TYPE) speci-fied is not valid for TYPE LOOKUP CODE(VALUE=&VALUE)


PO_PDOI_INVALID_SHIP_LOC_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

SHIP_TO_LOCATION_ID (VALUE=&VAL-UE) is not valid.


PO_PDOI_INVALID_SHIP_TO_LOC_IDÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

SHIP_TO_LOCATION_ID (VALUE=&VAL-UE) specified is inactive or invalid.


PO_PDOI_INVALID_SHIP_TO_ORG_IDÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

SHIP_TO_ORGANIZATION_ID (VAL-UE=&VALUE) specified is inactive or in-valid.


PO_PDOI_INVALID_START_DATE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Effective Date (VALUE =&VALUE) speci-fied should be less than the end date speci-fied.


PO_PDOI_INVALID_STATUS ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Approval Status specified is invalid.


PO_PDOI_INVALID_TAX_NAME ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

TAX NAME (VALUE =&VALUE) specifiedis inactive or invalid.


PO_PDOI_INVALID_TEMPLATE_ID ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

TEMPLATE ID (VALUE =&VALUE) speci-fied is inactive or invalid.





PO_PDOI_INVALID_TYPE_LKUP_CD ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Document Type Code (VALUE =&VALUE)specified is invalid.


PO_PDOI_INVALID_UN_NUMBER_IDÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

UN NUMBER ID (VALUE =&VALUE) spe-cified is inactive or invalid.


PO_PDOI_INVALID_UOM_CODEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

UNIT OF MEASURE (VALUE =&VALUE)specified is inactive or invalid.


PO_PDOI_INVALID_USSGL_TXN_CODEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

USSGL Transaction Code (VALUE =&VAL-UE) specified is invalid.


PO_PDOI_INVALID_VALUE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME must have a value of&VALUE.


PO_PDOI_INVALID_VDR_CNTCT ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Vendor Contact (VALUE=&VALUE) is notan active and valid contact for the specifiedvendor site.


PO_PDOI_INVALID_VENDOR ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Vendor (VALUE=&VALUE) specified is in-valid or inactive.


PO_PDOI_INVALID_VENDOR_SITE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Vendor Site (VALUE=&VALUE) is not anactive and valid purchasing vendor site.


PO_PDOI_INVAL_MULT_ORIG_CATG ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Multiple catalogs can be found with thesame document number (&DOC_NUM-BER).


PO_PDOI_ITEM_NOT_NULL ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

ITEM_ID should not be null for outside op-eration LINE_TYPE.


PO_PDOI_ITEM_RELATED_INFO ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME (VALUE=&VALUE)specified is inactive or invalid for ITEM_ID(VALUE=&ITEM).


PO_PDOI_ITEM_UPDATE_NOT_AL-LOW


Item attribute(s) required update. Howev-er, this execution does not allow item up-date/creation.


PO_PDOI_LINE_ID_UNIQUE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

LINE_ID must have a unique value. &VAL-UE already exists.


PO_PDOI_LINE_LOC_ID_UNIQUEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

LINE_LOCATION_ID must be unique.&VALUE already exists.


PO_PDOI_LINE_NUM_UNIQUE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

LINE_NUM must have a unique value.&VALUE already exists.


PO_PDOI_LT_ZERO ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME (VALUE =&VALUE)specified is less than zero.





PO_PDOI_MULT_BUYER_PART ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Multiple buyer parts are found whichmatch the specified Item Num (VAL-UE=&VALUE).


PO_PDOI_NO_DATA_FOUND ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

No rate found for currency_code (VAL-UE=&CURRENCY) andRATE_TYPE_CODE (VAL-UE=&RATE_TYPE).


PO_PDOI_OVERLAP_AUTO_RULE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Sourcing rule (VALUE=&START_DATE)and (VALUE=&END_DATE) overlaps withan existing sourcing rule.


PO_PDOI_PO_HDR_ID_UNIQUE ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

PO_HEADER_ID must be unique. (VALUE= &VALUE) already exists.


PO_PDOI_PRICE_BRK_AMT_BASED_LNÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Cannot create price breaks for amount–based lines in a BLANKET order agree-ment.


PO_PDOI_QT_MIN_GT_MAX ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Minimum Quantity (VALUE =&MIN) spe-cified is greater than maximum Quantity(VALUE =&MAX).


PO_PDOI_RATE_INFO_NULL ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

RATE TYPE, RATE_DATE and RATE mustbe null.


PO_PDOI_RULE_NAME_UNIQ ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Rule Name (VALUE= &VALUE) and ItemId (ID =&VALUE) should be unique.


PO_PDOI_SHIPMENT_NUM_UNIQUEÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Shipment Num must have a unique value.&VALUE already exists.


PO_PDOI_SPECIF_DIFF_IN_LINESÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME (VALUE=&PO_HEADER_ID) specified in line is dif-ferent from (VALUE=&VALUE) in header.


PO_PDOI_VALUE_NUMERICÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

&COLUMN_NAME (VALUE= &VALUE)needs to be a numeric value.





ORIGINAL_RFQ_NUM is invalid ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

The original RFQ number that is trans-mitted already exists. Select another RFQnumber.

ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

Category ID is invalid for Item ID. ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ

The category ID transmitted with the ItemID does not match the category ID alreadyset up in the system for that item. If it isnull, make sure that Purchasing is default-ing a category ID and that the category IDis enabled. Default item categories are spe-cified in Setup > Items > Category > Cate-gory Set. Make sure that the default itemcategory is one of the values in the rows.


Fixing Failed Transactions

Some examples of errors could be that the supplier’s information doesnot conform with Purchasing data requirements (for example, datefields are in an incorrect format), cross–reference rules set up betweenyou and your supplier are inaccurate, or your own Purchasing orOracle Applications data is not up to date. If errors exist in thesupplier’s data, ask the supplier to correct and resend the data.

Other errors could be the result of the following:

• If you create sourcing rules along with the imported data, makesure the documents in the data are submitted as approved.Sourcing rules can be created only when the Purchasingdocuments have a status of Approved.

• Flexfields may need to be frozen and recompiled. Navigate to theDescriptive Flexfield Segments window by choosing Setup >Flexfields > Descriptive > Segments. See: Defining DescriptiveFlexfield Structures, Oracle Applications Flexfields Guide.

See Also

Purchasing Interface Errors Report, Oracle Purchasing User’s Guide


Price/Sales Catalog Notification Workflow

The price/sales catalog notification workflow uses the Price UpdateTolerance you set to determine when a price increase in an Updateprice/sales catalog submission exceeds your tolerance. Workflow is anunderlying technology that sends a notification to the buyer if the pricetolerance is exceeded and waits for the buyer to accept or reject theprice increase. The Purchasing Documents Open Interface applies ordoes not apply the price increase depending on the buyer’s action.

The buyer is notified automatically by the workflow. The supplier isnotified of price update rejections only if you customize the workflowto do so.

You can view or modify this workflow in the Oracle Workflow Builder.See the Oracle Workflow Guide.

If you’re using Release 10.7: This workflow is available with Release11 only. Disregard this section if you are using the enhancedPurchasing Documents Open Interface with Release 10.7.

The following figure shows how the workflow affects line statuses inthe Purchasing Documents Open Interface tables:


Figure 3 Price/Sales Catalog Workflow Overview


Customizing the Issue Notifications Process

You can view the workflow in a Process window using the WorkflowBuilder.

� To display the workflow in the Oracle Workflow Builder:

1. Choose Open from the File menu, and connect to the database.

See: Opening and Saving Item Types, Oracle Workflow Guide.

The Display name of the price/sales catalog notification workflowis PO Catalog Price Tolerance Exceeded Notifications. The name of itsWorkflow definition file is poxprcat.wft.

2. Expand the data source, then the item type branch within that datasource.

3. Expand the Processes branch, then double–click the IssueNotifications process activity to display its diagram.

Required Modifications

There are no required modifications you need to make to thisworkflow.


Optional Customizations

Although you can use the workflow as is, you may wish to customize itfurther to accommodate your organization’s specific needs. You canmodify the Issue Notifications process to suit your business needs.

You could modify the process to send the buyer a reminder sooner orlater than the activity Wait for Buyer Action from Exceeded PriceTolerances Form does by default. You could modify the workflow tosend the notification to people other than the buyer. If you want tosend the supplier an automatic notification of rejected price updates,you must modify the workflow. Some of these customizations aredescribed below.

To help you with your customizations, refer to the sections later thatdescribe the components of this process.

You cannot modify any of the item attributes except for Supplier UserName. (Information about when you might customize this attribute isprovided below.) You cannot modify any of the function activities ormessages in the workflow; however, you could replace them in theIssue Notifications process with ones of your own. You can modify thenotification activities.

See: Workflow Customization Guidelines: page 64.

� To change the Timeout period from seven days:

1. In the Workflow Builder, expand the Functions branch and selectthe Wait for Buyer Action from Exceeded Price Tolerances Formactivity.

2. Choose Properties from the Edit menu.

The activity’s Control Properties window appears.

3. Select the Details tab.


4. Change the Timeout to a period of time that best suits yourorganization’s needs.

5. In Oracle Applications, submit the Workflow Background Process ifyou haven’t already. See: To Schedule Background Engines, OracleWorkflow Guide.

� To send automatic notifications of rejected price updates to thesupplier:

1. Create Workflow users and roles for your suppliers and associatee–mail addresses with them.

See: Setting Up an Oracle Workflow Directory Service, OracleWorkflow Guide.

2. Create a function activity that for a given supplier assigns thecorrect supplier user name to the Supplier User Name itemattribute.

When you create a function activity in the Workflow Builder, youalso have to create the PL/SQL stored procedure that the functionactivity calls.

See: To Create a Function Activity, Oracle Workflow Guide.

3. Place the function activity in the Issue Notifications processdiagram.


You could place it after the Were Any Items Rejected? activity andbefore the Supplier Username Value activity. Your new functionactivity will assign the supplier’s user name to the Supplier UserName item attribute. Then, the Supplier Username Value activityretrieves the supplier name from the item attribute.

Deciding Whether to Modify the Original or Create a New CustomProcess

Customize the default (original) workflow that Purchasing provides,after you make a backup. Unlike the PO Approval, PO RequisitionApproval, and PO Create Documents workflows in Release 11 ofPurchasing, only one price/sales catalog notification workflow can becalled in Purchasing. You can’t select a separate customization, likeyou can with the other workflows in the Document Types window.Therefore, you need to make your customizations to the defaultworkflow. You’ll always have your backup to revert to, if you need,while you are testing your customizations.

The PO Catalog Price Tolerances Exceeded Notifications Item Type

The Issue Notifications process is associated with an item type calledPO Catalog Price Tolerances Exceeded Notifications. This item typeidentifies all workflow processes available with the price/sales catalogupdate submission.

The PO Catalog Price Tolerances Exceeded Notifications item type alsohas several attributes associated with it. These attributes referenceinformation in the Purchasing application tables. The attributes areused and maintained by function activities as well as notificationactivities throughout the process.

To view descriptions of each item type attribute, select the attribute inthe Workflow Builder and choose Properties from the Edit menu. Lookin the Description field.

Summary of the Issue Notifications Process

To view the properties of the Issue Notifications process, select theprocess in the navigator tree, then choose Properties from the Editmenu. The Issue Notifications process has no result type, indicatingthat when the process completes, it has no defined result of, forexample, End (Valid) or End (Invalid) corresponding to any lookuptype in the navigator tree.


This process activity is runnable, indicating that it can be initiated as atop–level process to run by making calls to the Workflow EngineCreateProcess and StartProcess APIs.

The activity Notify Buyer of Price Updates that Exceed Tolerance sendsthe buyer a notification if any of the supplier price updates exceed theprice tolerance you have set as described in the section MonitoringPrice Increases: page 22. Then the workflow waits for the buyer torespond before updating the price or price breaks. If the buyer doesnot respond after the amount of time you specify in the ControlProperties page of the activity Wait for Buyer Action from ExceededPrice Tolerances Form, the notification is sent to the buyer again.

As soon as the buyer responds to all of the pending price updates, theworkflow cancels the notification so that it does not show up the nexttime the buyer queries for notifications.

The function activity Were Any Items Rejected? determines if any priceupdates were rejected. If they were, the supplier can be notified of thedocument lines whose prices were rejected through the functionactivity Notify Supplier of Price Updates that were Rejected if youcustomize the workflow to send automatic supplier notifications. SeeOptional Customizations: page 59.

Issue Notifications Process Activities

Following is a description of each activity listed by the activity’sdisplay name. You can create all the components for an activity in the


graphical Workflow Builder except for the PL/SQL stored proceduresthat the function activities call. All function activities execute PL/SQLstored procedures which you must create and store in the OracleRDBMS. The naming convention for the PL/SQL stored proceduresused in the Issue Notifications process is:

PO_WF_PO_PRICAT_UPDATE.<PROCEDURE>

PO_WF_PO_PRICAT_UPDATE is the name of the package that groups allthe procedures used by the Issue Notifications process. <PROCEDURE>represents the name of the procedure.

Notify Buyer of Price Updates that Exceed Tolerance

If any of the price updates in the price/sales catalog update submissionexceed the tolerance you have set, this activity sends the buyer anotification. One notification is sent for each document.

Wait for Buyer Action from Exceeded Price Tolerances Form

This activity waits for the buyer to respond to the notification. Thecatalog submission (and the workflow) do not continue until the buyerresponds. If the buyer does not respond after the amount of timespecified in the Control Properties page of this activity, the notificationis sent to the buyer again.

Cancel any Outstanding Buyer Notifications

As soon as the buyer responds to the notification, this activity cancelsthe notification so that it doesn’t show up the next time the buyerqueries for notifications.

Were Any Items Rejected?

This activity determines if any price updates were rejected. If theywere, the supplier can be be notified of the document lines whoseprices were rejected through the function activity Notify Supplier ofRejected Price Updates, if you’ve customized the workflow to do so.

Were All Items Accepted or Rejected?

This activity is not currently used by the workflow.

☞


Supplier Username Value

This activity makes sure that the supplier’s user name is on the list ofuser names in Oracle Applications. This activity is used only if youcreate a function activity to populate the Supplier User Name itemattribute. Supplier Username Value is a standard Workflow activityused to do comparisons. It is associated with the Standard item type.

Notify Supplier of Price Updates that were Rejected

If the activity Were Any Items Rejected? records any price updates thatthe buyer rejected, this activity sends a notification to the supplier ifyour supplier is set up in Workflow to receive such notifications. Seethe Oracle Workflow Guide.

Workflow Customization Guidelines

Following are some basic guidelines you should be aware of whencustomizing a workflow.

Access Levels

You should always operate the Workflow Builder at the sameconsistent access level, because the level you work at affects theprotection level of any changes you make to a workflow.

To view your access level, select About Oracle Workflow Builder fromthe Help menu in the Workflow Builder. It should be set to 100 orabove. It’s very important that your access level be set to 100 or abovebecause, at this level, you can clearly see which Workflow activities areprotected against customization (read–only), and which areunprotected (available for you to customize).

From the Workflow Builder’s Navigator, you can determine if aWorkflow activity—such as a process, function activity, or itemattribute—is protected against customization by a red lock in the lowerright corner of the icon.

Also be sure that Allow modifications of customized objects is unchecked.Choose About Oracle Workflow Builder from the Help menu and makesure that it is unchecked. See the Oracle Workflow Guide for furtherexplanation of this feature.

Attention: Oracle allows modifications only to thoseWorkflow activities that are displayed as unprotected when

☞


you operate the Workflow Builder at an Access Level of 100 orabove. Do not modify protected Workflow objects. Unlessinstructed otherwise, you should not change your access levelto something lower than 100 in an attempt to modify protectedactivities.

You can protect an individual activity through its access settings in theControl Properties window. The example below assumes an AccessLevel of 100 in the About Oracle Workflow Builder window. At anAccess Level of 100, checking the ”Lock at this Access Level” check boxprevents a particular activity from being modified by anyone with anaccess level greater than 100. Checking the Preserve Customizationscheck box prevents the activity from being modified by anyone with anaccess level less than 100. Checking both of these boxes means that onlysomeone at your level (100) can overwrite your changes.

Attention: One reason it’s important to work at a consistentaccess level is upgrading. Workflow enhancements that maybe included in future upgrades of Purchasing work at an accesslevel of 20. In the example above, future Workflow upgradeswill not overwrite your changes because only someoneworking at an access level of 100 can overwrite your changes.This is why, if you work at an access level of 20, even if youcheck both of the check boxes above, future upgrades willoverwrite your changes.


For complete information on how access levels work, see:

Overview of Oracle Workflow Access Protection, Oracle Workflow Guide

Allowing Access to an Object, Oracle Workflow Guide

Backups and Testing

Always make a backup of the original workflows that Purchasingprovides before you customize them. If you should ever have aproblem with a workflow, the first thing a support representative mayask you to do is to upload the original workflow and see if the problemstill exists.

Always test your customized workflow on a test database beforeuploading it to your actual database.

You can create a backup from a UNIX prompt or through the WorkflowBuilder. Or, you may have your own source control system. Below aresample instructions for making backups.

From a UNIX prompt:

1. Change to the directory that contains the .wft file:

$PO_TOP/admin/import

2. Use the copy command to copy the .wft file to a backupdirectory/file.

For example:

cp poxprcat.wft/my_directory/my_backups/poxprcat.wft/

Through the Workflow Builder:

1. Open the workflow in the Workflow Builder.

2. Select the workflow in the Navigator and choose Save As from theFile menu.

3. Choose File to save the backup to a local hard disk.

Enter the path name of the new directory in which you want tosave a backup copy.

For example:

D:\my_directory\my_backups

☞

Example


Upgrade Support

Future upgrades of Purchasing can include upgrades to the Purchasingworkflows. Workflow upgrades look at the internal name and accesssettings of a workflow activity (such as a process, function activity, oritem type) to determine whether to apply the upgrade to the activity.

If you copy an activity and change its internal name, or check theactivity’s Preserve Customizations check box, you protect yourcustomization to that activity from being overwritten by futureupgrades. For example, if you customize a process by adding atransition to a new activity in that process, you must check the PreserveCustomizations check box in the process’s Control Properties windowto preserve your added transition. But if you do this, any futureupgrades to the process provided by Purchasing will be ignored.

Attention: To protect your customizations to a process, youmust check the Preserve Customizations check box in theprocess’s Control Properties window.

Each time you customize an activity (beyond the optional setupchanges described in the Purchasing setup documentation), decidewhether to change the default activity that Purchasing provides, or tocopy and rename it. The following paragraphs describe how to helpyou make that decision.

You want to completely change Process D shown below. You copy andrename it My Process. Since you have changed its name, you also mustchange its name in the icon in the Default Purchasing Process. And ifyou do this, you must Preserve Customizations on the DefaultPurchasing Process as well. Otherwise, a future upgrade to the DefaultPurchasing Process, if it is upgraded, will overwrite your call to MyProcess, and you’ll have to reapply your call to that process after everyupgrade. (Note: The upgrade will never overwrite My Process itself,since its name has changed.)

Note: When you provide your own name to a Workflowobject, use a name that clearly indicates that it is acustomization.


If you keep the same name, Process D, you don’t have to check thePreserve Customizations check box for the Default Purchasing Process.Therefore, you’ll get future upgrades to the Default Purchasing Process,if there are any, and your Process D changes will also be preserved aslong as you checked its Preserve Customizations check box.

If you make a lot of changes to a process, you may want to copy andrename it. Future upgrades will upgrade the default process that is stillthere, but that you’re no longer using, and you can optionally applythose upgrade changes, if any, to your customized process. In somesituations, this may be easier than reapplying your customizations to acompletely new process created by the upgrade. If you are makingminor changes to a process, you may want to modify the defaultprocess directly if you think that your customizations are small enoughto reapply after each upgrade of Purchasing. Based on the extent ofyour changes, you need to decide which option will be easier for you.

Note: If a future upgrade provides better functionality foryour organization than your customizations, you can alwaysuncheck the Preserve Customizations check box to overwriteyour customizations with the upgrade.