Oracle iProcurement

The Oracle iProcurement functionality provides the essentials for the ordering portion of the procurement process.  This includes catalog content management, requisitioning, purchase order creation, and receiving orders.

Oracle iProcurement 11i enables internal corporate requesters to independently order items from both local (internal) and remote (external) catalogs. Oracle iProcurement 11i is fully integrated with Oracle Applications Release 11i.

Oracle iProcurement is part of Oracle Applications, an integrated suite of E-Business solutions designed to transform your business into an E-Business. Along with the rest of the Oracle E-Business suite, iProcurement helps an enterprise streamline the procurement process with end-to-end business automation. It is the starting point for the ordering process and provides powerful self-service requisitioning capability with an intuitive, web shopping interface. It constitutes a key component of the complete procure-to-pay business flow and helps an enterprise to process and manage requisitions and receipt of the  requested goods/services in an efficient and automated manner.

Indirect & Direct
Indirect sourcing is:
The purchase or procurement of any goods or services that are not directly related to/included in the manufacture of any of our primary products
Examples include (but are not limited to): Office supplies, Advertising, Training & Tools etc.

Direct sourcing is:
The purchase or procurement of any goods or services that are directly related to/included in the manufacture of any of our primary products
Examples include (but are not limited to): Standard Inventory Item (Laptop), Manufacturing Item (Car)

iProcurement should be used for the purchase of ALL goods and services

Why are we switching to iProcurement?
Simplicity : There are several different ways to acquire indirect materials right now, each with its own rules
Cost Savings: Transactional costs are reduced by lowering the number of touches a requisition experiences eBusiness Direction All Businesses have implemented/are implementing Oracle Purchasing systems
  • Ability to buy administrative items
  • Ability to buy production items
  • Self-guiding catalog
  • Desktop receiving
  • Single global instance
  • Punchout to other exchanges
  • Integration with enterprise resource planning (ERP) system


  1. Perform Oracle iProcurement-specific system administration setup
  2. Define information templates
  3. Define data security (realms)
  4. Enable Categories for Oracle iProcurement
  5. Perform preliminary catalog load
  6. Perform preliminary catalog schema maintenance
  7. Verify profile options for iProcurement
  8. Verify workflow settings for iProcurement
  9. Set up company specific order controls
  10. Implement custom packages
PO: Allow Requisition Approval Forward Action - Only Site Level
When this profile is set to Yes, Approve, Reject, Forward, Approve and Forward actions are allowed in a requisition approval notification. Otherwise, only Approve and Reject actions are allowed.

PO:Workflow Processing
Affects the performance of the Purchasing approval workflow  processes. Online completes an entire approval workflow process before letting you proceed to the next activity. Background allows you to proceed to the next activity while the approval process completes in the background. Whichever option you choose, you can always view the current status of a requisition or purchase order through the Requisitions Summary or Purchase Orders Summary windows.
When this profile option is set to Background, you must start the Workflow Background Process, which you access through the System Administration responsibility. It is recommended that you set this process to run frequently, if you are using it for Background mode approvals.

POR : Default Currency Conversion Rate Type
Use this profile option to specify the default exchange rate type. This rate is used when creating non-catalog requests, when converting a bulk loaded item's transactional price into a requester's functional price, and when converting a punchout or transparent punchout item’s transactional price into the functional price.
If you will be converting prices of punchout or transparent punchout items, this profile option must be set to either Corporate or Spot (not User). Otherwise, the requester will receive an error message during checkout that no exchange rate exists and will not be able to check out the item.

POR: Enable Automatic Debit Memo Creation for Returns
Enables automatic creation of debit memos for all return to supplier transactions. Valid values are Yes or No.

POR: One Time Location
Enter the location to be used as the one-time address. The application uses the location code entered here as the one time location. The actual one-time address details are entered during checkout.

POR: Require Blind Receiving
This profile is used to turn on/off Blind Receiving support in Oracle iProcurement. Blind receiving support requires  corresponding setup in Oracle Purchasing. Valid values are Yes or No.

POR: Use Oracle Approvals Manager
Indicate whether Oracle Appprovals Manager (OAM) will be used as the approval engine for requisitions.

Catalog Management

Oracle iProcurement uses stores and catalogs to organize items for requesters.

What Are Catalogs?
A catalog is a cohesive source of supplier product and service information that provides a means by which the information can be found quickly by the requestor.
Attributes of a good catalog are:

  • Content (product categories)
  • Accuracy (product descriptions)
  • Robustness (availability)
  • Ease of use (good indexing, searching)
Why Use Catalogs?
An internet-based procurement solution is only effective if the user can reliably order the items they need.  Poor catalog management leads to:
  • Contract leakage
  • Maverick buying
  • Workarounds
  • Decreased spend control
Each store contains one or more catalogs of items. When requesters search, Oracle iProcurement searches across all catalogs in the store and displays the results. (You search one store at a time.).Grouping similar catalogs into a single store provides the following benefits:
  • Provides logical groupings. In some cases, requesters may understand store groupings better than categories, which may be too technical or granular for requesters.
  • Produces more relevant search results. For example, searching for battery can return AAA battery, industrial battery, and notebook computer battery. If, however, each battery is in a separate catalog and you segment the catalogs by store, the notebook computer battery can belong to a Computer Supplies store. Searching for a battery in the Computer Supplies store returns only computer batteries.
Types of Catalogs
Oracle iProcurement supports the following types of catalogs:
■ Local catalog (also known as the base catalog - extractor & bulk loader)
■ Punchout catalog hosted by a supplier or marketplace
■ Transparent punchout catalog hosted by a supplier or marketplace
■ Informational catalog

Local Catalog
There are two sources for data residing in the local catalog. One of these sources is your internal procurement system. Using the catalog extractor, data from purchasing documents such as blanket purchase agreements and requisition templates can be made available to requesters in Oracle iProcurement. The other source for local content is data loaded directly into Oracle iProcurement through the catalog bulk loader. This data may have originated from a supplier or third-party content management service, downloaded from, or created internally.

Punchout Catalog Hosted by Supplier or Marketplace
While creating a requisition, requesters can punch out directly to an Oracle Exchange marketplace, such as, or to a supplier's Web store (to access supplier-hosted catalogs). After selecting items for purchase, requesters return to Oracle iProcurement to add additional items to their cart and check out as they normally do. For more information on setting up punchout, see the Punchout and Transparent Punchout Guide for Oracle iProcurement and Oracle Exchange.

Transparent Punchout Catalog Hosted by Supplier or Marketplace
A transparent punchout catalog (also known as a distributed search) allows requesters to search for items on an external site without leaving Oracle iProcurement. Unlike punchout, requesters do not access the site directly. Instead, when the requester searches for items, the transparent punchout works in the background to access the remote catalog and returns the matching items directly to the search results in Oracle iProcurement. Requesters do not necessarily know the items came from an external site. From the Search Results page, requesters add the items returned from the transparent punchout to their shopping cart and check out as they normally do. From Oracle iProcurement, you can set up a transparent punchout to a supplier site or to an Oracle Exchange marketplace, such as

Informational Catalog

An informational catalog enables you to provide to requesters instructions or links for ordering items or services that may not fit into the other catalog types. For example, your company may already have internal Web pages containing purchasing information for employees. You can use the informational catalog as the starting point for accessing those pages. The informational catalog enables Oracle iProcurement to be your company’s portal for all ordering.

Creating and Maintaining Local Content

Buyer-hosted catalogs are hosted, as the name suggests, by the purchasing organization.  A single catalog is built with product and services information from multiple suppliers.  It is used by all purchasing staff and has a common user interface, no matter which supplier the product or service is ultimately obtained from.

Buyer-Hosted catalogs are:

  • Singular (one catalog fits all)
  • Unified (consistent look and feel)
  • Supplier independent (contains selected products and services from more than one supplier)
Suggested Commodities
Direct material: mass-produced mechanical parts; products with pre-negotiated or stable prices; strategic maintenance, repair, and operation (MRO) items (such as packing material).
Indirect material: office supplies; standard MRO items; products with unstable pricing.
Before Extracting or Bulk Loading Content
It you are extracting categories from Oracle Purchasing, keep in mind that the existing category structure will be reproduced in the Oracle iProcurement catalog.  This also means that this is an opportunity to create a multi-tiered structure before extraction.
If you are going to create a category structure in Oracle iProcurement, you’ll need to create or load these categories using schema editing or bulk loading, and then map these categories to Oracle Purchasing categories.

Think first about how you want the catalog to look and be structured:
  • Will you use only extracted items and categories?
  • Will you use only bulk loading?
  • Will you use both methods?
  • Are the categories you extract sufficient, or do you want to create a different category structure for iProcurement users?
Extracted Item Sources Requirements
To extract items from Oracle Purchasing documents certain conditions must be met. First and foremost is that the item must belong to a Web enabled Purchasing category set. Then the conditions indicated in the table above must be met.
Source Document
This is the Oracle Purchasing document type. Blanket indicates a blanket purchase agreement. Quotation indicates an existing Oracle Purchasing quotation.
ASL stands for Approved Supplier List. If indicated in the above table, the item must be included in an active ASL.
Supplier Item #
Indicates that a supplier item number must exist in the Oracle Purchasing document.
System Item
Indicates that the item must be correctly set up as a purchasing item in Oracle Purchasing or Oracle Inventory as a master item that is enabled for the operating unit you are extracting.
Other requirements
This column in the table identifies other requirements that must be met for the Oracle Purchasing document to be considered for item extract. Typically these are that the document must be approved, the document’s effectivity dates must indicate that it is active, and that the document amount limit has not been exceeded.
Oracle Purchasing Contract Agreements
Not listed in the table, but very much a part of the ordering process are contract agreements. They have no items and therefore are not considered during extraction. However the still have requirements that must be met to be used for automatic sourcing. Similar to blanket agreements, they must be approved, the document’s effectivity dates must indicate that it is active, and that the document amount limit must not be exceeded.

Implementation Considerations

The extraction criteria for each of the following data elements is explained in further detail below:
■ Purchasing categories
■ Blanket purchase agreements
■ Global agreements (blanket purchase agreements for which Global is selected)
■ Catalog quotations
■ Requisition templates
■ Approved supplier list (ASL) entries
■ Items from the item master file, including internally orderable items

The extractor does not extract outside processing items.

If the extracted items include updates to items that requesters have placed on favorites lists, the favorites lists are also updated. (Saved carts are not updated, but upon checkout, Oracle iProcurement will alert the requester to items that no longer exist or are no longer valid.)

The item data that is extracted is as follows: supplier, supplier site, category, item number, item description, unit of measure (UOM), price, currency, supplier item Creating and Maintaining Local Content number, attribute 13 (for images, if any, on blanket purchase agreements or catalog quotations), and attribute 14 (for image URLs, if any, on blanket purchase
agreements or catalog quotations). If extracting requisition templates, the requisition template name is also extracted and displayed as a public shopping list.

If extracting items from agreements or quotations, the agreement or quotation number is also extracted; the number displays to the requester if it is set up to display using schema editing.

Purchasing Categories For categories to be extracted into the Oracle iProcurement catalog, the following requirements must be satisfied:
■ The category belongs to the Purchasing Category set.
■ The category is Enabled for iProcurement in the Categories window.
■ The category is active.
Oracle iProcurement extracts the category description, such as Computers and Monitors, and displays that as the category name in Oracle iProcurement. If there is no category description, it extracts the category code, such as IT.COMPUTER, and makes that the category name.

Blanket Purchase Agreements Items on blanket purchase agreements appear in the Oracle iProcurement catalog if the following conditions are met:
■ The blanket purchase agreement is approved and valid (not canceled, closed, finally closed, or frozen).
■ The blanket purchase agreement header and line are active. (Their effective dates include today.)
■ The item belongs to a purchasing category that satisfies the requirements stated in the Purchasing Categories section. The category has been extracted.

Global Agreements Items on global agreements appear in the Oracle iProcurement catalog if the following conditions are met:

■ The global agreement meets the same requirements as given for blanket purchase agreements, above.
■ Since global agreements are created in one operating unit and assigned to others, the following conditions must also be met to ensure that the global agreement is valid in its assigned operating units:

  • The supplier site for the item on the global agreement is an active Purchasing site in the assigned operating unit.
  • If the item on the global agreement is a master item, the item is defined in the financial system parameters (FSP) organization for the assigned operating unit and is purchaseable in the FSP organization. The FSP organization is the inventory organization specified in the Supplier-Purchasing tabbed region of the Financial Options window. Each operating unit has an FSP organization that contains a bank of valid items for that operating unit. If an item on a global agreement exists in the FSP organization in the operating unit in which the agreement was created but not in the assigned operating unit, then the item is not extracted from the assigned operating unit.
  • If the item on the global agreement is a master item, the UOM class used on the agreement must match the UOM class defined for the master item. If the currency on the global agreement differs from the  requester’s functional currency, the rate type from the Purchasing Options (for the requester’s operating unit) and the extraction date are used to perform the currency conversion.

Bulk Loading Catalog Data

Bulk Load: XML or spreadsheet (tab-delimited text) file that supplier creates and buyer uploads using the eContent Manager.
You can use either extraction or bulk loading, or both methods, to maintain buyer-hosted content. For example, bulk-loaded items can augment items already extracted into the iProcurement catalog.

  • You can bulk load items in addition to items you’ve extracted.
  • You can modify extracted items using your bulk load file. Basically, bulk loading lets you specify more information about items than the item master or other sources may allow.  
The Oracle iProcurement catalog supports the bulk loading of catalog data. Catalog data consists of the items and services available for purchase as well as the associated prices for these goods.
Catalog data may have originated from any of the following sources:
■ Downloaded from an Oracle Exchange marketplace, such as
■ Obtained directly from a supplier.
■ Obtained from a third-party catalog provider.
■ Created internally.

The bulk loader supports item catalogs created in the following formats:
■ Tab-delimited text file (spreadsheet)
■ Catalog Interchange Format (CIF)
■ cXML (commerce eXtensible Markup Language, which is based on the XML language)

The catalog bulk loader also supports the creation of catalog schema using XML files. The catalog schema consists of a combination of categories, local descriptors used to describe items in a specific category, and base descriptors used to describe any item or service in the catalog.

Setting Up Contract AutoSourcing

Oracle iProcurement supports the association of a requisition line with a contract purchase agreement defined in Oracle Purchasing. This allows the automatic creation of standard purchase orders through the use of the PO Create Documents workflow. The standard purchase order that is created stores the contract number in the Purchase Orders window, in the Reference Documents tabbed region, in the Contract field. Oracle Purchasing adds the total amount of the purchase order line to the Released amount on the contract purchase agreement.

Associating a requisition line with a contract purchase agreement can be done in two basic ways, automatic or explicit.

Automatic Contract Sourcing If the PO Create Documents workflow option "Should Contract be used to autocreate the Doc?" is set to Yes, Oracle iProcurement checks whether there is a valid contract purchase agreement for the supplier and
supplier site specified on the requisition. If there is, that contract is used. If multiple contracts exist for the supplier and supplier site, the latest created contract is used.
Automatic contract sourcing can be used for the following types of items:
■ Bulk loaded, punchout, or transparent punchout catalog items where there exists a valid contract purchase agreement for the same supplier and supplier site associated with the item.
■ Non-catalog requested items where there exists a valid contract purchase agreement for the same supplier and supplier site associated with the item.
■ Extracted ASLs that are not linked to a source document and where there exists a valid contract purchase agreement for the supplier and supplier site specified on the ASL.

Explicit Contract Sourcing
You can also explicitly enter a contract purchase agreement for an item in the catalog.
Explicit contract auto-sourcing can be used for the following types of items:
■ Bulk loaded items that have an explicit reference to a contract purchase agreement in Oracle Purchasing.
■ XML punchout or transparent punchout items for which the supplier hosting the content has specified a contract purchase agreement number that is valid in Oracle Purchasing.
■ XML punchout or transparent punchout items from an Oracle Exchange marketplace where the buying company has specified on a supplier price list a valid contract purchase agreement number in Oracle Purchasing.

If a specific, valid contract purchase agreement number is given for an item, the PO Create Documents workflow references that contract purchase agreement on the purchase order, even if other valid contract purchase agreements exist for the
supplier and supplier site.

Overview of iProc

The basics components of the iprocurement product are
■ Catalog and Content Management
■ Shopping
■ Checkout and submit requisition
■ Approval and Order creation(Requisition Tracking and Management)
■ Desktop Receiving

Catalog and Content Management

Oracle iProcurement 11i offers a flexible solution to catalog and content management, enabling you to select from several approaches based on your business model.
1. Load catalogs directly into the Oracle iProcurement catalog using the catalog bulk loader, which supports catalogs formatted in XML, standard text, catalog interchange format (CIF), or cXML. Using the catalog bulk loader, you can load
new catalogs, update existing catalogs, and delete catalog content. Oracle iProcurement 11i also supports catalogs created in multiple languages and currencies to support requester communities worldwide, respecting their cultural backgrounds.

2. Use the catalog extractor to load items and services from Oracle Purchasing into the iProcurement catalog.

3. Punchout to an Oracle Exchange marketplace, such as, or a supplier's Web store to access their catalogs. This punchout can be a direct link to the store, where the requester searches, shops, and returns items to
Oracle iProcurement. Alternatively, you and the supplier can set up a transparent punchout that works in the background to return matching items from the external site directly to the requester’s search results.

4. Use informational catalogs, which contain instructions or links for ordering other items or services at your company. The informational catalog enables Oracle iProcurement to be your company’s portal for all ordering.

Oracle iProcurement employs the concept of stores. Using stores, organizations can define an intuitive collection of their content areas. Stores can be configured to include any combination of local catalogs, punchout catalogs, information catalogs and transparent punchout catalogs.

For most organizations, restricting access to content by role is very important. After configuring catalogs and stores, administrators can easily control which are available to different classes of requesters within the employee population.

Internally Sourced Items
In a buying organization, goods are sourced either from external suppliers or from internal inventory and warehouse locations. In Oracle iProcurement, externally sourced items are requested using purchase requisitions and items sourced from an internal source are requested using internal requisitions. Internal requisitions are not converted into purchasing documents (purchase orders. blanket releases, and so forth). Rather, internal requisitions are converted into internal sales orders. These internal sales orders are subsequently processed and then the requested items can be received in Oracle iProcurement.

Once items have been added to the cart, requesters have three options to complete the requisition process. Regardless of the checkout option selected, at the end of each checkout a requisition is submitted.

Delivery -Multiple Destination Types
You can use Oracle iProcurement 11i to create requisitions for requester-initiated inventory replenishment requests, such as stocking a shop floor crib. Alternatively, requested items can be delivered to an expense destination.

One Time Addresses
There are occasions where requesters want items delivered to a location that is not an office location or other pre-defined location established in the database. This is considered a one time address and can be defined as a deliver to location during the requisition creation process.

Integration to EAM
Oracle Enterprise Asset Management (EAM) is an Oracle Applications module that identifies, schedules and tracks all work activity/costs related to assets throughout an organization. Oracle iProcurement requisitions update EAM work orders.

Multiple Account Distributions and Account Generation Workflow Integration
Charge accounts for requisition lines are generated using Account Generator Workflow rules. You can split charges for requested items across multiple accounting codes, allowing multiple departments or account to bear the cost of items on a single requisition line. This eliminates the need to create multiple requisition lines when the same item is being requested for multiple departments.

Encumbrance Support
For customers using budgetary controls, Oracle iProcurement provides the ability to check funds on–line before submitting requisitions. If a request carries costs past their budgetary limit, the requester is informed and can take appropriate action.
Funds are automatically reserved during the requisition submit process.

Requisition Tracking and Management
After the requester has created and submitted a requisition, the requester can quickly and easily track further processing of the requisition using the Oracle iProcurement application.

Requisition Tracking
The requester receives real-time notifications to keep the requester up-to-date with actions taken against the requisition. Requesters can optionally launch enhanced queries to gain additional intelligence and insight into the progress of their

Requisition Management
If there are changes to be made to an existing requisition, the requester has the capability to withdraw the requisition, make the necessary changes and resubmit it, or if the original request for the goods/services is no longer valid, the requester can simply cancel the original requisition. Requesters can also submit a request for changes to the purchase order created from their requisitions.

Requisition Approval Routing
Oracle iProcurement provides flexibility in streamlining the approval process:
■ Vacation Scheduling: Approvers can indicate dates of planned absence and specify proxy approvers for their notifications, eliminating potential bottlenecks in the approval process.
■ Approval Manager workflow can reassign, forward, or request more information during the approval process.
■ Approver checkout: When the requisition goes to the approver for approval, the approver can also make changes to the requisition before approving it.

Desktop Receiving
In Oracle iProcurement requesters can receive items, return items, correct items that have been previously received, and view their receiving transaction history.


Shopping describes the process of finding the correct items for your order and adding them to your shopping cart.  Depending on the procurement needs of your requesters and the buying policies of your organization, the setup can be simple or complex.

My Favorites
If requesters order the same items regularly they can develop a Favorites List by selecting an item from the search results and clicking the Add to Favorites button.

Public List
Public lists are requisition templates that are created in Oracle Purchasing and then extracted into iProcurement. An example of a public list is an office supplies list.  The list could contain the standard set of office supplies a new hire would need.

Searching in iProcurement makes use of the Context or InterMedia features of the Oracle database.  Users can search for item names, item numbers, supplier names, and other criteria available in your catalog. Review the Managing iProcurement Catalog Content course for more details on what items are available in the unified catalog.

Browse Categories
iProcurement catalog management enables the catalog administrator to create a table of contents by item category. For example, you may want to order a pencil. By using the Browse Category feature you would first select Office Supplies and then Pencils to see the selections available.

There may be occasions when an item is not listed in either the internal catalog or on a supplier or external marketplace punchout site.  You can create an item that is not listed in your catalog by using the Create Non-Catalog Request page.  Non-Catalog items can include services or specialty items.

External Marketplace
Users may “punchout” to a supplier or marketplace Web site to search for items and bring them back into iProcurement to be used on a requisition. Review the Managing iProcurement Catalog Content course topic for more details on punchout.

iProcurement Requisitions

The Oracle iProcurement functionality provides the essentials for the ordering portion of the procurement process.  Here we will discuss the shopping process that leads to to requisitioning (ordering) in Oracle iProcurement.

From the iProcurement home page you can:
  • Search or select items to order from a catalog (Find a Product or Go shopping).
  • Initiate the creation of a requisition (Approve).
  • View the status of your requisitions (Requisitions at a Glance).
  • View and respond to your notifications (To Do List).
  • View your company’s latest purchasing news (Purchasing News).
  • Review your company’s purchasing policies.
  • The iProcurement administrator can customize the Purchasing News and Purchasing Policies regions in the iProcurement home page, as well as change the logo on the home page to your company’s logo. 
Basic Shopping Flow
Navigate to iProcurement Responsibility (N) Home Page > Shop. Search or select the item to procure and add to the shopping cart. once all the required items are selected to the shopping cart we can check out with any of the three available methods.

Checkout Methods: Comparison
From the user perspective the different checkout methods dictate the amount of information that requesters must enter to complete an order. From the implementation perspective the methods differ in how much help entering information you expect the requester to require. For example, power checkout provides the same access to requisition information as step-by-step, but does so in fewer pages.

Step-by-Step Checkout
Requesters are led step-by-step through entering the details needed to create an order. Requester needs less experience to complete the order process. Defaults details from requester's My Profile, which the requester can override Requires the Review/Submit step

This checkout method is ideal for the requester who needs complete control over the information to be included in the final requisition.
During the delivery stage specify: Date you want it delivered, Requester Location to deliver to ,Different delivery information for each line item, A one-time address
During the billing stage specify: Procurement card, Taxable status, Project to bill to,
Different billing information foreach line item, Multiple charge accounts for a single line item
During the notes stage specify: Description for the requisition, Notes to the buyer and approver, Attachments
During the approval stage specify: Review your list of approvers, Specify additional approvers, Change first approver, Delete non-mandatory approver, Add note to approver Attach justification attachment

Power checkout
Power checkout is used by requesters with more experience with  iProcurement, but that still need to  have full control over content. Defaults details from requester's My Profile, which the requester can override Enables updates to checkout information on a single page Requires Review/Submit step.
You can enter or update all the information on a single page during the power checkout process.  You can review and edit approvers similar to the step-by-step checkout process.

Express checkout limits what you can update during checkout
Defaults all details from the requester's My Profile Requester can enter only:
  • Need-by date
  • Requisition description
  • Notes to buyer and approvers
  • Review is optional
To change any of the defaulted information, you will have to use your browser’s back button and use the step-by-step checkout process.

You may review your requisition before submitting it for approval. You are actually submitting the requisition to the Requisition Approval workflow. If your requisition is approved it will then be submitted to the PO Create Documents workflow to create an order for the supplier.

Internally Sourced Requisitions Overview

The internal requisitions feature introduced in Oracle iProcurement generally follows the same flow as the internal requisition flow Oracle Applications, with some exceptions.

Extract Internal Items
In iProcurement, the process begins once the internally orderable items have been extracted into the catalog.  Using the extractor is the only way to get the internal items into the unified catalog.

Search and Display of Internal Items
After searching for items in the catalog, internally orderable items can be viewed and selected. At this point the user may have the option to manually select and/or modify the source information, if the POR: Allow Manual Selection of Source is set to Yes.  Alternatively, the iProcurement user can decide to let the application decide which organization or supplier should supply the item(s) selected.

Sourcing and Checkout
Once the user selects an item for internally sourced lines the sourcing logic is triggered (the source organization and, optionally, the source subinventory are determined). During checkout, the existing validations are performed as well as additional validations for the internally sourced line items.  At the end of the checkout process an internal requisition line will have been created.

Requisition Approval and Sales Order Creation

Next, the normal requisition approval processes are performed, after which the internal requisition lines are converted into internal sales orders through the two processes Create Internal Sales Orders in Oracle Purchasing and Import Orders in Oracle Order Management. The resulting internal order is then picked, packed and shipped. 

The associated internal requisition line can then be received in iProcurement.

Throughout this process, the internal requisition can be viewed and various information pertaining to the associated internal sales order can be viewed by clicking the internal requisition number from the Requisition Status page and then click the View link associated with the internally sourced line from the View Requisition Details page. If available the Order number, Order Creation Date, and Shipment Number are displayed.

Internally Sourced Requisitions - Details
The internally orderable items are extracted from core applications using the item extractor.  The extractor has been enhanced to consider items that have the internal orders enabled flag set to Yes for extraction.  Such items may also be externally purchasable, but they need not be.  Therefore, items in the catalog may be strictly purchasable (internal orders enabled in the Master Item window is set to No), strictly internally orderable (purchasable in the Master Item window is set to No) or both purchasable and internally orderable (purchasable and internal orders enabled in the Master Item window is set to Yes).

Item Attributes in Source Organization
The following attributes must be set for the item in each organization, in order for those organizations to be considered as source organizations: 
  • Purchasable
  • Transactable
  • Shippable
  • OE Transactable
  • Inventory
Loader Values Parameters
The extractor also looks at the value of a new loader parameter when determining whether to extract internal items.  This new loader parameter is called Internal Items.  If checked, then internally orderable items will be loaded into the catalog during the extraction process.

Internally orderable items can be found on requisition templates as well.  These internal items will also be extracted, although the source defined on the associated requisition template will not be recorded.  Lastly, internally orderable items can be added to a requester’s favorites list.  Again, no source information is maintained on the favorites list.

Search and Display of Internal Items
Internally orderable items can be distinguished by the select source link found in the new Stocked Internally on the Search Results page.  The select source link is also found as field in the Compare Results and Item Details pages.  Internally orderable items can only be distinguished through this field.

Profiles That Affect Internally Sourced Items

The display of Internally orderable items is controlled by 2 profiles:
  •  PO: Legal Requisition Type Profile: Controls whether internally orderable items display on the Search Results page and whether internal requisitions can be created in Oracle Purchasing.
  •  POR: Allow Manual Selection of Source: Controls whether the select source link displays. By clicking on the select source link, the user can manually select and override the system defaulted source information for a given item.  Therefore, this profile controls both the ability to distinguish which items are internally orderable and the ability to manually select the source information.

Requisition Management Actions

Navigate to iProcurement Responsibility > (N) Home Page > (T) Requisition Status
You can manage your requisitions from the Requisition Status page. Search criteria is used to find the requisition requiring action.  Once selected from the search results, click the appropriate action.

Copying Requisitions
From the Requisition Status page, select a requisition that you wish to copy.  Click the Copy to Cart button, make any changes to the quantity that are needed, and then click Proceed to Checkout.
  • You can copy requisitions from the Requisition Status page.
  • You can copy requisitions of any status.
  • Copying a requisition copies the items from the original requisition into a shopping cart.
  • The new requisition will need to be taken through the checkout process.
Canceling Requisitions
Canceled requisitions cannot be re-opened. A buyer in Oracle Purchasing can cancel the purchase order which would then allow the requisition lines to be cancelled.
From the Requisition Status page you can cancel requisitions that have been submitted for approval.
The following rules apply to canceling requisitions:
  • You can cancel requisitions of any status.
  • You cannot cancel individual requisition lines.
  • You cannot cancel requisitions once it has a line converted to a purchase order.
Resubmitting Requisitions
Withdrawing Requisitions
Only requisitions that have not been placed on a purchase order can be withdrawn.  For example, if you create and approve a requisition with four lines and a buyer placed one of those lines on a purchase order, you cannot withdraw any of those four lines.
Resubmitting a Requisition
A user can resubmit any requisition that was either rejected by an approver or returned by a buyer.

Requisition Status
From the Requisitions page on the Requisition Status tab, the approval status of a requisition can be determined.  Clicking the Status link displays the approval history of an item.  All approved requisitions are placed directly into the Oracle Purchasing approved requisition pool.
The requisition statuses are:
  • In Process
  • Approved
  • Rejected
  • Return
  • Cancelled

Perform Oracle iProcurement-specific system administration setup

Define additional responsibilities and set profile options
Define additional users
Verify Profile Options That Impact Oracle iProcurement: Oracle Applications

Audit Trail: Activate
If you want to keep track of the changes made to your data by application users, you should set up AuditTrail for the relevant tables.  Defining AuditTrail for your site involves defining Audit Groups, which are groups of tables and columns for which you intend to track changes. You then define Audit Installations to instruct AuditTrail which ORACLE IDs you want to audit. Finally, you run the Audit Trail Update Tables Report, which allows your AuditTrail definitions to take effect.

Default Country
This is the default source for the Country field for all address zones and is used by the Flexible Address Formats feature, the Flexible Bank Structures feature and the Tax Registration Number and Taxpayer ID validation routines.

Help Localization Code
This is the localization code for localized Help files.

GL: Set of Books Name
Specify your set of books. This option also associates a set of books with a responsibility.

Sequential Numbering
Sequential numbering assigns numbers to documents created in the Oracle financial products.

HR: User Type
Use this profile option to limit field access when sharing Oracle Human Resources and Oracle Payroll.

These are a few key profile options. 
PO: Set Debug Workflow On
Used usually by technical support staff only for finding problems with the Oracle Purchasing workflow processes. The default value is No.  The user can view and update this profile option. It can also be updated at the user, responsibility, application, and site levels.

PO: Workflow Processing Mode
Affects the performance of the Purchasing approval workflow processes:
Online - Completes an entire approval workflow process before letting you proceed to the next activity, but provides you with an updated Status (for purchase orders) as soon as it finishes.
Background - Enables you to proceed to the next activity while the approval process completes in the background. When this profile option is set to Background, you must start the Workflow Background Engine, which you access through the System Administrator responsibility. It is recommended that you set this process to run frequently, if you are using it for Background mode approvals.

MO: Operating Unit
Determines the operating unit associated with your responsibility.

HR: Cross Business Groups
Affects the suggested buyer functionality by including buyers from different business groups.

HR: Business Group
Associates a business group with a responsibility.

Attachment File Directory
Specifies the directory where attachments are stored.

ICX: Limit connect
Determines the maximum number of page hits per session.

ICX: Limit time
Determines the maximum number of hours a user can be logged on per session.

ICX: Override Location Flag
Determines whether the default deliver-to location on orders can be overridden.

ICX: Override Requestor
Determines whether a user can override the default requestor code and create a requisition for everyone, the entire organization, or just the user.

POR: Amount Based Services Line Type
Determines the line type for amount-based non-catalog requests.

POR: Goods Line Type
Indicates the line type that should be used for all bulk loaded items and quantity-based non-catalog requests.

POR: Rate Based Services Line Type
Specifies the line type for rate-based non-catalog requests.

POR: Approved Pricing Only
Restricts user access to only those items associated with blanket purchase agreements, catalog quotations, and requisition templates.

POR: System Approvers are Mandatory
Determines whether the default approvers on the approver list are mandatory.

POR: Hosted Images Directory
Specifies the directory where image files are stored.

POR: Load Auto Category
Controls whether the catalog bulk loader should automatically create any new categories during the loading process.

POR: One Time Location
Used as the one-time location code for the one-time address.

TAX: Allow Override of Tax Code
Controls the ability to override the tax code that is defaulted during the requisitioning process.


Information Templates

You may set up information templates to gather additional information in Oracle iProcurement 11i to pass necessary order processing information to suppliers. When an information template is assigned to a category or item, the application
prompts requesters to provide the information specified in the template when the item is added to the shopping cart. This information becomes a line level attachment to the requisition.

For example, you can implement information templates for items like business cards that require additional information (name, address, e-mail, phone) from the requester. Oracle iProcurement will then prompt for name, address, e-mail, and
phone number when you order business cards. Each information template must be associated with an Oracle Purchasing item or item category. If an information template is associated with an item category, all items belonging to that category
are also associated with the template.

Information templates are not the same as requisition templates in Purchasing. Requisition templates in Purchasing are a pre-filled listing of frequently ordered items. Information templates are additional information templates that a requester in iProcurement completes for certain items.

Setup Steps:

Navigate to Purchasing Super User Responsibility > (N) Setup > Information Templates
1. Enter an Attribute Name and Description. The Attribute Name is the actual field prompt that is displayed in Oracle iProcurement.
2. Optionally, enter a default value to automatically appear in the field.
3. Indicate whether the field is mandatory for iProcurement requesters. If the field is mandatory, requesters will be prompted to enter a value in the field before proceeding to complete the requisition.
4. Indicate whether to activate the attribute to actually display on iProcurement pages. In certain circumstances, you may want to define an attribute, but delay enabling it for display to iProcurement requesters.
5. Choose Associate Template to associate the template with an item or an item category. The information Template Association window appears.
Select the type of association (item number or item category) to associate with the template. If you selected Item Number in the previous step, enter the number. If you selected Item Category, enter the category.

If information templates are created for both the item and a category that it belongs to, then both templates apply to that item.

Defining Realms

A realm is a set of access privileges to internal catalogs, external catalogs, or categories within internal catalogs. A security realm is a list of objects (item source or a category) to which a user is granted access.  Examples of item sources include a company’s internal catalog or an external supplier’s catalog or marketplace.  A category, unlike an item source, represents a grouping of items within the internal catalog. 

You can create the following two kinds of realms:
■ A category realm is a set of access privileges to categories contained in the localcatalog.
■ An item source realm is a set of access privileges to punchout, transparent punchout, or informational catalogs.
Once you create a realm, you assign it to a responsibility or user. The requester associated with that responsibility or user can see whatever categories or item source catalogs are contained in that realm.

Note: You can use realms either to control access to categories in the local catalog (using category realms) or to control access to a punchout, transparent punchout, or informational catalog (using item source realms). For example, you cannot restrict a user’s access to categories within a punchout or transparent punchout. You cannot use realms to control access to an entire local catalog.

Category Realms Example
Assume the following item categories exist in the local catalog:
■ Medical/Surgical Equipment
■ Medical/Surgical Supplies
■ Notepads
■ Writing Instruments
Because of the nature of the items contained in the Medical/Surgical categories, only certain requesters are allowed to create requisitions for these items. You create two realms. One realm grants access to all of the categories mentioned above and is assigned to the iProcurement MedSurge responsibility. The other realm grants access only to the Notepads and Writing Instruments categories and is assigned to the Internet Procurement responsibility.
Any requester who logs in using the iProcurement MedSurge responsibility has access to items in all of the categories mentioned above. A requester who logs in using the Internet Procurement responsibility has access only to items in the
Notepads and Writing Instruments categories. Alternatively, or additionally, you could assign these realms to individual users.

Item Source Realms Example
Assume the following remote catalogs are defined in Oracle iProcurement:
■ (transparent punchout)
■ Office Supplies Unlimited (transparent punchout)
■ Computer Components Corporation (punchout site)
Company policy limits the purchasing of computer hardware to the Information Technology (IT) department. To adhere to this policy and restrict certain requesters from ordering these types of items, two realms are created. One realm grants access to all of the remote catalogs mentioned above and is assigned to members of the IT department. The other realm grants access only to and Office Supplies Unlimited. This realm is assigned to all other requesters. You can assign the realms to a responsibility (which assigns it to all requesters who use that responsibility), to individual requesters, or both.

Responsibility and User Access to Realms
Until you assign realms, users have access to all categories and to all punchout, transparent punchout, and informational catalogs defined in Oracle iProcurement.Once you assign a realm, the affected requester or requesters have access only to the data in the assigned realm.
Realms are additive. For example, when you assign a realm to a responsibility, all requesters assigned that responsibility have access to that realm; however, you can assign additional realms to any of these individual requesters that only they have
access to.

Setting up realms consists of three basic steps:
1. Create the realm.
2. Assign the realm to a responsibility.
3. Optionally assign realms to individual users if desired.
To use realms, you must at a minimum "secure" the responsibility that the requesters use to access Oracle iProcurement. Securing a responsibility consists of entering ICX_POR_REALM_ID in the Name field for the responsibility as described
in the steps below. Next, as described in the steps below, assign a realm ID to that responsibility, to requesters (users) in that responsibility, or both, as your needs require.
If you secure a responsibility with ICX_POR_REALM_ID and do not assign a realm ID, the responsibility is "secured" against accessing any categories or item source catalogs. Anyone assigned to that responsibility does not have access to any
categories or item source catalogs—until you assign a realm ID to the responsibility or user.

Categories restricted by realms display to requesters when browsing categories; however, the items in those categories do not display. Category realms restrict access to items in the excluded categories.

Extracted Buyer-Hosted Content

A buyer uses the extractor in Oracle Purchasing to pull categories and items from the following sources in Oracle Applications:
Classifications (categories):
Oracle Application categories are extracted to Oracle iProcurement to become catalog categories. Since those application categories are often created to satisfy planning or production needs, they don’t usually provide a good basis for a user friendly shopping catalog. Oracle provides the ability to identify only those categories necessary for creating iProcurement orders.

  • Web-enabled Purchasing categories - In Oracle Purchasing or Inventory, enter Y in the descriptive flexfield (attribute 10) for the purchasing category code.
  • Requisition template headers
  • Belong to web-enabled Purchasing categories
  • Items on catalog quotations
  • Items on blanket purchase agreements
  • Items in the Approved Supplier List
  • Items on requisition templates
  • Classifications
Running the Extractor
There are two ways to extract the data:
  • Define Catalog Server Loader Values window
  • Concurrent programs: Catalog Extract Data – Classifications  & Catalog Extract Data – Items
Populating the local catalog
Populating the local catalog with content consists of the following activities. Either extracting or bulk loading data is required; everything else is optional:
■ Extracting Catalog Data from Oracle Applications
■ Bulk Loading Catalog Data
■ Define Category Mapping
■ Define Classification and Supplier Domains

Extracting Catalog Data from Oracle Applications
The following purchasing data from Oracle Purchasing can be reflected in the Oracle iProcurement catalog:
  • Purchasing categories
  • Requisition templates
  • Approved supplier list (ASL) entries
  • Items from the item master file, including internally orderable items
  • Blanket purchase agreements
  • Global agreements
  • Catalog quotations
The catalog extractor in Oracle Purchasing is used to populate the Oracle iProcurement catalog with your Oracle Purchasing data. Before running the catalog extractor, you must specify which data elements you
wish to make available in Oracle iProcurement. For example, if your company does not use requisition templates, there is no need to extract them.

To specify data elements for extraction Open the Define Catalog Server Loader Values window using the following navigation path after logging into Oracle Purchasing: Setup > E-Catalog Admin > Loader Values.
1. By default, blanket purchase agreements (including global agreements) and quotations are extracted. These are grouped together in the Contracts option.

Selecting Item Master extracts purchaseable items in the master item file and item-level ASL entries. Selecting Internal Items extracts internally orderable items, which can be placed on internal requisitions, if the internal requisitions functionality has been implemented in Oracle Purchasing. If an item is both purchaseable and internally orderable, it is extracted based on your selection. If you select only Item Master, it is extracted as a strictly purchaseable (external) item. If you select only Internal Items, it is extracted as a strictly internal item. If you select both, it is available as both an internal and external item in the catalog (if POR: Legal Requisition Type is set to BOTH).

2. Define Rollback Segment (Optional)
Use the Concurrent Programs window to define rollback segments for each of the extractor programs:
■ Catalog Data Extract - Classifications
■ Catalog Data Extract - Items
■ Catalog Data Extract - Purge
Rollback segments are used by the database to store the information needed to undo changes when necessary (for example, during a system failure). Defining rollback segments is optional, because the default rollback settings should be adequate. If you choose to define rollback segments, however, get help from
your database administrator. Defining rollback segment sizes can affect the successful completion and performance of the extractor.

3. Extract the Data (Required)
Extract the data in one of two ways:
■ Click the Extract buttons in the Define Catalog Server Loader Values window.
■ Use the Submit Requests window. See Launching the Catalog Extractor from the Submit Request Window

Managing the Catalog Extractor
To transfer your purchasing data into the Oracle iProcurement catalog, the catalog extractor must be launched. The catalog extractor can be launched from either the Define Catalog Loader Values window or the Submit Request window. The recommended order for running the catalog extractor is:
1. Catalog Data Extract - Classifications
2. Catalog Data Extract - Items
3. Catalog Data Extract - Purge (Optional)
Note: Other than for exceptions, you should not run this program independently. For example, if you are upgrading Oracle iProcurement or extracting data and the log indicates a database error occurred while the interMedia Index was running, you could run the interMedia Index program independently; however, you
should always investigate the error before running the program, to make troubleshooting the problem easier.
4. Rebuild the Catalog Item interMedia Index (Only if data corruption or some other exception occurs) 

Launching the Catalog Extractor from the Loader Values Window

To launch the catalog extractor from the Define Catalog Server Loader Values window:
1. Click Extract Classifications.
2. Monitor the extraction request in Oracle Purchasing by choosing Requests. Choose View Log to check for errors.
3. Once the classifications request completes successfully, return to the Define Catalog Server Loader Values window and click Extract Items.
4. Monitor the extraction request in Oracle Purchasing by choosing Requests. Choose View Log to check for errors.

A list of non catalog templates in an operating unit

A list of non catalog templates in an operating unit.
Associated item category and stores

Select DISTINCT b.category_id, a.template_name, b.item_type, b.unit_of_measure_code, b.org_id,
c.segment1 ||'.' || c.segment2 ||'.' || c.segment3 ||'.' || c.segment4 ||'.' || c.segment5 AS CATEGORY_VALUE, c.DESCRIPTION
WHERE a.template_id=b.template_id
AND b.org_id=d.org_id
AND b.org_id= :org_id
AND a.created_by=b.created_by
AND b.category_id=c.category_id

Tree & Tree Structure


What is a tree?
A tree is hierarchical structures that enable several data management functions such as better access control, application of business rules at various levels of hierarchies, improved query performance, and so on.

This concept is similar to the organization hierarchy in 11i & R12.
For example, MI Corporation has two departments: Marketing and Finance.
The Finance department has two functional divisions: Receivables and Payables.
Defining a tree for the MI Corporation establishes a hierarchy between the organization and its departments, and between the departments and their respective functional divisions as shown in above pic.

What is a tree Structure?
A tree structure is configuration on the basis of which trees are created. It defines and restricts the tree. A tree is an instance of the hierarchy as defined in the tree structure. Tree structures enable you to enforce business rules to which the data must adhere.
The root node is the topmost node of a tree. Child nodes report to the root node. Child nodes at the same level, which report to a common parent node, are called siblings. Leaves are details branching off from a node but not extending further down the tree hierarchy.

Important Points

  • You can associate multiple data sources with a tree structure.
  • Every tree structure can contain one or more trees.
  • You can create tree structures specific to an application but you can share tree structures across applications.
  • If you apply version control to the tree structure, it is carried over to the trees that are based on the tree structure.
  • Each tree version contains at least one root node. Occasionally, a tree version may have more than one root node.
  • An administrator controls the access to tree structures through a set of rules that are periodically audited for validity.

What is a tree version
A tree is created having only one version. However, users can create more than one tree version depending on the need, and they can make changes to those versions. Depending on varying requirements, users can create one or more tree versions and publish all of them or some of them by making the versions active at the same time. Similar to any other version control system, versions of trees are maintained to keep track of all the changes that a tree undergoes in its life cycle.

What are tree labels
Tree labels are short names associated with trees and tree structures and point directly to the data source. Tree labels are automatically assigned to the tree nodes. You can store labels in any table and register the label data source with the tree structure.