Browser version scriptSkip Headers

Oracle® Procurement Cloud Using Procurement
Release 13.2
Part Number E49610-02
Go to Documentation Home
Home
Go to contents  page
Contents
Book<br />List
Book
List
Go to Feedback page
Contact
Us

Go to previous page
Previous
Go to previous page
Next
PDF

3 Manage Procurement Catalog

This chapter contains the following:

Manage Procurement Content

Manage Content Zone

Define Procurement Content

Local Catalogs and Inclusion and Exclusion Rules : Explained

Map Sets: Overview

Using Supplier Content Map Set With Agreement Loader: Explained

Using Supplier Content Map Set With Punchout: Explained

Manage Catalog Category Hierarchy

Manage Procurement Content

Catalogs: Overview

Oracle Fusion Self Service Procurement offers a flexible solution to catalog and content management, enabling catalog administrators to select from several approaches based on the company business model.

You can use any or all of the following approaches to create catalog content:

Local Catalog

Administrators can define partitions of the local catalog using inclusion and exclusion rules for agreements and categories. Administrators or suppliers on behalf of the buying organization can upload local catalog content either online or in batch. While batch upload is optimized for large data upload, the online authoring is optimized for making small and quick updates to catalog content. The catalog batch upload supports catalogs formatted in XML, standard text, catalog. interchange format (CIF), or cXML. Through batch upload or online authoring, administrators can load new catalogs, update existing catalogs, and delete catalog content. Oracle Fusion Self Service Procurement also supports catalogs created in multiple languages and currencies to support requester communities worldwide. Optionally, administrators can organize local catalog content in a hierarchical view for users to navigate to the products they want to buy.

Punchout Catalog

Administrators can setup a punchout to an Oracle Exchange marketplace, such as exchange.oracle.com, or a supplier web store to access their catalogs. The punchout catalog can be a direct link to the store, where the requester searches, shops, and returns items to Oracle Fusion Self Service Procurement.

Informational Catalog

Administrators can define informational catalogs, which contain instructions or links for ordering other items or services at your company. The informational catalog enables Oracle Fusion Self Service Procurement to be your company portal for all order requests.

Public Shopping List: Explained

Public Shopping lists are created in procurement business units and are available to requisitioning business units serviced by that procurement business unit.

The catalog administrator can add item master items and agreement lines to a public shopping list.

The availability of a public shopping list and its items to a preparer is determined by the following:

  1. The public shopping list is available to the user based on the content zone assignments.

  2. The item master item or agreement lines are available to the user based on the content zone assignments.

  3. The item master item or agreement lines are available to the requisitioning business unit of the user.

  4. The public shopping list is valid based on its start and end dates.

The catalog administrator can indicate a suggested quantity on a public shopping list item, which will be defaulted when the preparer views the public shopping list or adds the line to a requisition.

The sequence value for the public shopping list items determines the order of display for the public shopping list lines when viewed in Oracle Fusion Self Service Procurement.

Informational Catalog: Explained

Informational catalogs can be used to provide instructions to employees on how to order products. Administrators use the informational catalog page to provide a URL to the page which contains company instructions, policies, guidelines, or other links. Like punchout catalogs, informational catalogs can optionally be associated to categories, so that it will be available when browsing through catalog content.

Once an informational catalog is created, administrators must associate it to content zones to make the catalog available to users with the privilege to search catalog items.

Punchout Catalogs: Points to Consider

Punchout enables requesters to click on a link that goes to a supplier catalog, search for items on the supplier site, and return those items directly to the requisition. Requesters can then edit and submit the requisition. Using a punchout allows suppliers to maintain and host their own catalog information. This ensures the latest content and pricing is available to requesters.

Punchout supports both cXML and Oracle native XML standards, depending on the model used.

If a contract agreement exists with a punchout supplier, the shopping cart returned by the supplier can include the contract agreement number. This contract agreement number, if valid, will be stored on the requisition line and will allow the autocreation of a purchase order when the requisition is approved.

"Punchout process"

When To Use Punchout

Punchout is particularly useful for products that are configurable or include highly variable or dynamic items and pricing. These products are difficult and costly to maintain in a buyer hosted catalog.

There are a variety of punchout models to provide you with the flexibility to pick the model that best works for you.

Selecting a Punchout Model

The figure below shows the process for deciding which model to use.

Selecting a model diagram

XML (eXtensible Markup Language) is a standard for passing data between applications, and provides a common language for sites to communicate across the internet. cXML (commerce eXtensible Markup Language) is an extension of XML, with standards published by cXML.org.

Model 1: Punchout from Oracle Fusion Self Service Procurement to Oracle Exchange (XML)

In model 1, the supplier loads catalog items directly to Oracle Exchange. The catalog administrator then sets up Oracle Fusion Self Service Procurement to use Oracle Exchange as the punchout hub.

When the user clicks on a punchout link to Oracle Exchange, Oracle Exchange authenticates the requester and returns a response. If the authentication is successful, the user is redirected to the Oracle Exchange site to search for and add items. When the requester finishes adding items to the Oracle Exchange shopping cart, Oracle Exchange returns these items to the requisition. The requester then submits the requisition. The illustration below shows Model 1.

Model 1

Oracle Exchange can be setup as an aggregator site, where requesters can have access to items from different suppliers. Benefits for the suppliers include:

Model 2a and 2b: Punchout From Oracle Fusion Self Service Procurement to Supplier Hosted Catalog (XML & cXML)

In models 2a and 2b, the supplier hosts the catalog at their own site or web store. The catalog administrator sets up a punchout catalog to use the supplier as a punchout site.

When the requester clicks on a punchout link to the supplier site, the supplier authenticates the requester and returns a response. If the authentication is successful, Oracle Fusion Self Service Procurement redirects the requester to the supplier site to search for and add items. When the requester completes adding items to the supplier shopping cart, the supplier site returns the shopping cart items to Oracle Fusion Self Service Procurement. The requester then submits the requisition. The illustration below shows Models 2a and 2b.

Model 2a and 2b

This model provides a unique point to point solution between the buyer and the supplier. The supplier can closely manage the content, and can control access by allowing only certain buyers to access the site. Suppliers who already maintain cXML catalogs can continue to do so, without needing to support XML as well.

Model 3: Punchout From Oracle Fusion Self Service Procurement to Supplier Hosted Catalog Through Oracle Exchange (XML)

In this model, the supplier hosts the catalog at their own site or web store. When the user clicks on the punchout link, the requester is taken directly to the supplier site. Although behind the scenes, the access is through Oracle Exchange. Using Oracle Exchange for the punchout simplifies the initial setup process and the authentication and maintenance of the punchout. The supplier must set up a punchout from Oracle Exchange to their site. To setup access to the supplier site through Oracle Exchange, the catalog administrator needs to download the supplier punchout definition from Oracle Exchange. Downloading the supplier punchout definition seeds the punchout definition from Oracle Fusion Self Service Procurement to the supplier site through Oracle Exchange, without requiring the catalog administrator to perform manual setup.

The requester clicks on the punchout link, Oracle Exchange authenticates the requester, and sends a punchout request to the supplier. The supplier site then responds to Oracle Exchange, and in turn Oracle Exchange forwards the supplier site response to Oracle Fusion Self Service Procurement. If successful, the requester is redirected to the supplier site for shopping. When the requester completes adding items to the supplier shopping cart, the supplier site returns the shopping cart items to the requisition. The requester then submits the requisition. The illustration below shows Model 3.

Model 3

The catalog administrator does not need to configure a punchout for each supplier, but can just download the supplier punchout definition from Oracle Exchange. Suppliers only need to define their punchouts on Oracle Exchange once, rather than configuring punchout separately for each company using Oracle Fusion Self Service Procurement . When catalog administrators download punchout catalogs, Oracle Exchange sends the supplierSynch document to Oracle Fusion Self Service Procurement that contains the punchout definition.

Model 4: Punchout From Oracle Fusion Self Service Procurement to Supplier Hosted Catalog Through Oracle Exchange (cXML)

In Model 4, the supplier hosts a cXML catalog at its own site or web store. Similar to Model 3, the requester accesses the supplier site (behind the scenes) through Oracle Exchange. The supplier must set up a punchout from Oracle Exchange to its site, and the catalog administrator then downloads the supplier punchout definition from Oracle Exchange when setting up the punchout catalog.

The requester clicks on the punchout link, Oracle Exchange then authenticates the requester, and sends a punchout request to the supplier. The supplier site then responds to Oracle Exchange, and in turn Oracle Exchange forwards the supplier site response to Oracle Fusion Self Service Procurement. If successful, the requester is redirected to the supplier site for shopping. When the requester completes adding items to the supplier shopping cart, the supplier site returns the shopping cart items to Oracle Fusion Self Service Procurement. Oracle Fusion Self Service Procurement then redirects the shopping cart to Oracle Exchange, where Oracle Exchange converts the shopping cart from cXML to XML and returns the items to Oracle Fusion Self Service Procurement. The requester then submits the requisition. The illustration below shows Model 4.

Model 4

This model provides the same benefits as Model 3. In addition, suppliers already maintaining cXML catalogs can continue to use them without having to also support XML.

Mapping is performed in 2 steps:

  1. If mapping exists in Oracle Exchange, the values in the supplier cart will be mapped to the Oracle Exchange value.

  2. When the cart is returned to Oracle Fusion Self Service Procurement by Oracle Exchange, the Oracle Fusion Self Service Procurement supplier map set pertains, if applicable.

Double Punchout

As part of Model 1, the requester has access to Oracle Exchange when creating a requisition. When in Oracle Exchange, the user may have the ability to drill out to a supplier punchout site. This is called a double punchout.

Repunchout (cXML)

Oracle Fusion Self Service Procurement provides the capability for requesters and approvers to inspect cXML punchout items through repunchout, if the supplier site supports the inspect or edit operation. This is controlled through the operationAllowed tag in the cXML files. Since Oracle Fusion Self Service Procurement only supports the inspect operations, any changes made on the supplier site during repunchout are not returned to the requisition. If repunchout is enabled, the item will be hyperlinked on the Edit requisition page.

Shopping Lists: Explained

Shopping List is the collective term for Public and Personal Shopping Lists

Public Shopping List

Public Shopping Lists are created by the procurement catalog administrator, and are collections of items available to preparers or requesters for requisitioning. A Public Shopping List is also utilized to support kit requisitions. For example, office supplies, or a new hire kit. The availability of a Public Shopping List is based on the procurement BU in which the list is created, and whether the preparer was granted access to the list. The availability of public shopping lists is driven by the content zone that the list was added to.

Public Shopping Lists are created in procurement business units, and can be shared across the requisitioning business units that the procurement BU services. In the case where the procurement business unit is the same as the requisitioning business unit, only one requisitioning business unit will have access to the Public Shopping List. In the case where a procurement business unit services multiple requisitioning business units, the public shopping lists can be shared across the requisitioning business units that it services.

The procurement catalog administrator can add the following contents to a Public Shopping List through the supplier item catalog:

My Shopping List

My shopping list, also known as a personal shopping list, is a collection of frequently ordered items created by preparers or requesters. The Personal Shopping List allows the preparer or requester to quickly order items for which they often create requisitions.

Embedded Analytics: Explained

Embedded Analytics enables actionable insight for application users by providing access to information or data which will help them to complete a transaction. With respect to Oracle Fusion Self Service Procurement, Embedded Analytics are metrics which help users select items either based on what is popular among other users, or the average time it takes for an item to be received.

Embedded Analytics is dependent on the availability of Oracle Business Intelligence and Analytics Application. In addition, the profile POR_DISPLAY_EMBEDDED_ANALYTICS needs to have been set to Yes before the metrics are visible to end users.

Item Popularity Rank

Item Popularity Rank helps users determine what items they should add to their requisition based on popularity. The analytic shows how often an item has been requested by other users compared to other items in the same item category in the last 90 days. It is displayed as X out of Y where X is the rank and Y is the total number of items in an item category. For example, an item with a rank of 1 out of 10 is more popular than an item with a rank of 3 out of 10.

Average Requisition to Fulfillment Time

Average Requisition to Fulfillment Time shows and average of how long it will take to receive an item based other orders for the same item.

The analytic shows the total elapsed time from requisition submission to order fulfillment (i.e. receiving the order) for similar items in the last 90 days. It is a summation of Average Requisition Approval Time, Average Requisition Approval to PO Processing Time, and Average PO Fulfillment Time.

  1. Average Requisition Approval Time: Average time from requisition submission to requisition approval for similar items in the last 90 days

  2. Average Requisition Approval to PO Processing Time: Average time from requisition approval to PO open for similar items in the last 90 days.

  3. Average PO Fulfillment Time: Average time from PO open to Item fulfilled for similar items in the last 90 days.

    Or

Note

If the application is performing 2-way matching, the invoice date is used. If the application is performing 3 or 4-way matching, receipt date is used.

Manage Content Zone

Content Zone: Overview

A content zone defines what subset of content (local, punchout, informational, public shopping lists, smart forms) should be available to what users.

Content Zones: Explained

Managing a large number of items and services requires a mechanism for controlling what content should be available to users. The Content Security model provides the ability to control access to catalog content across users. The local catalog provides flexible controls against attributes such as agreements, and categories to determine whether certain items should be included or excluded in the catalog. The content zone will determine which segments of content (local, punchout, informational, and smart forms) should be accessible to what users.

The following features are supported through the content security model using content zones:

Creating Content Zones: Points to Consider

Administrators first create smart forms, shopping lists, and catalog definitions for a procurement BU. To make any content available to users, catalog administrators need to associate the catalogs, smart forms, and shopping lists to content zones.

Content Security Considerations

The catalog administrator is responsible for setting up the content security. The administrator determines what subset of the content will be accessible to which users in the procurement application.

Requesters and preparers access the procurement catalog when shopping. The Catalog Administrator accesses the procurement catalog when creating public shopping lists. Buyers access the procurement catalog when creating or updating purchase order, agreement, and requisitions. The content security model restricts what each user can access from the catalog in each flow.

Content Browsing Considerations

Catalog users are able to search for items within the content made available to them through content security. In addition, there is a unified model for browsing and for searching all content (local, punchout, informational, and smart forms) that can be optionally grouped by commodity. Administrators can define as many levels as they want for their category hierarchy. Local content is associated to the purchasing categories. Punchout catalogs, informational catalogs, and smart forms can be associated to any level of the hierarchy structure (browsing or purchasing category).

Create Content Zones

Each content zone is created for a procurement BU and is designated whether the content zone is to be used for procurement, or for requisitioning. This determines the flow to which the content zone applies, and provides administrators with control over who can see what content.

Procurement

A content zone for procurement can be accessible to all users working in the procurement business unit or to specific workers. The content zone applies to users searching the catalog when creating purchase order, agreement or public shopping list.

Requisitioning

A content zone for requisitioning can be accessible to all users working in specific requisitioning business units or to specific users. The content zone applies to buyers updating requisition lines in process requisition, or to self service requesters in Oracle Fusion Self Service Procurement

The following graphic shows catalogs, smart forms and public lists associated with a content zone.

"Graphic showing catalogs, smart forms
and public lists associated with a content zone."

Define Content Availability

Determine the content availability by defining which items are included or excluded from the catalog search results, and then apply security to the content definition based on who will have access to the content.

Define which items should be included or excluded from the local catalog based on blanket agreement and category inclusion and exclusion rules.

Process flow for the catalog administrator
and the procurement catalog user

Content Zones: How They Work with Catalogs, Smart Forms, and Public Shopping Lists

Content zones provide a mechanism for controlling what segments of catalog content should be available to users. Administrators define catalogs, public shopping lists, and smart forms and then secure access to them using content zones. Content zones enable administrators to apply the same catalog, smart forms, and public shopping lists definitions to multiple users or business units.

Catalogs, smart forms and public lists
are grouped under a content zone.

Catalogs

Administrators can maintain local, punchout, and informational catalogs in the procurement business units where they have access. Catalogs are associated to content zones to enable one place to secure content.

Smart Forms

Smart forms are configurable templates that enable users to order goods or services that are not available in the catalog. Smart forms are created in a procurement business unit and can be secured using content zones. A smart form is available to a user in Oracle Fusion Self Service Procurement if the user has access to the content zone containing the smart form.

Public Shopping Lists

Associating public shopping lists to content zones enables administrators to control what public shopping lists users can see. Note that even though a user may have access to a public shopping list, the user might not see certain items on the list due to content security restrictions by agreement and category.

Content Zone Security Options: Points to Consider

When content zones are created for procurement business units, administrators indicate whether the content zones are to be used for procurement or for requisitioning. Designating the use of the content zone determines to which flow the content zone is applied.

A content zone for requisitioning can be accessible to all users working in specific requisitioning business units or to specific users. The content zone applies to buyers updating requisition lines in process requisition, or to self service requesters in Oracle Fusion Self Service Procurement.

The following security options will be available depending on the content zone usage:

Requisitioning

When a content zone is used for requisitioning, the catalog administrator needs to specify the requisitioning business units to which the content zone is applicable. When the content zone is assigned to a requisitioning business unit, all users who have access to that requisitioning business unit can access the content zone. To further restrict access to the content zone, the catalog administrator can assign the content zone to individual users (employees or contingent workers).

Procurement

When the content zone is used for procurement, by default, all users who have access to the owning procurement business unit can access the content secured by that content zone. Optionally, the catalog administrator can restrict access to the content secured by the content zone to individual users (employees or contingent workers).

Including a Public Shopping List in a Content Zone: Points to Consider

Associating public shopping lists to content zones enables administrators to control what public shopping lists users can see. Note that even though a user may have access to a public shopping list, the user might not see certain items on the list due to content security restrictions by agreement and category.

Considerations

On the Shopping List page in Oracle Fusion Self Service Procurement, public shopping lists will be available to user if the following are true:

Then each item is checked to see if the items are available in the requisitioning business unit that the preparer is currently shopping in.

For agreement items, the requisitioning business unit assignment on the agreement will determine if an agreement item will be displayed, that is, an item will be displayed in a requisitioning BU if the agreement has been assigned to the requisitioning BU. The agreement and the agreement lines must be open.

Master Items are checked to see if the item is enabled for the deliver-to organization derived from the deliver-to location specified in the requisition preferences.

Content zones will also be applied on the public shopping list items. Preparers can only see items from the aggregated content zones they have access to.

If the public shopping list header is available in a requisitioning BU, but no items are applicable, then the public shopping list will be displayed without any items.

Smart Form: Overview

Smart Form is a tool used by catalog administrators to define noncatalog request forms. Catalog administrators can define forms for multiple purposes: goods based or fixed price services based request types. A smart form can contain defaulting information and can be extended to use information templates to collect additional information.

Smart Forms: Explained

A smart form is used to define noncatalog request forms. Catalog administrators create smart forms for goods based, or fixed price services based request types. A smart form can contain defaulting information and can be extended to use information templates to collect additional information. The Catalog Administrators can also define a smart form description or instruction text providing detailed information about the smart form.

Smart forms:

Contract Purchase Agreements

By associating a contract purchase agreement with a smart form, all approved requisition lines created with this smart form will be automatically processed onto purchase orders without buyer intervention.

Information Templates

Information templates are used to collect additional information from the preparer before the requisition is submitted. During the definition of the smart form, the procurement catalog administrator can add an information template to the smart form, such that the information template will be displayed when a preparer navigates to the smart form request page. The administrators can define an information template section with description or instruction text. This text provides preparers with specific instructions on how to fill out the form.

Procurement Business Units

Smart forms are created in a procurement business unit, and can be secured using content zones. Smart forms created in procurement business units can be shared across the requisitioning business units that the procurement BU services.

Attachments

Attachments can be added to individual smart forms. Attachments can provide preparers with more information, such as detailed steps to complete the request.

Supplier attachments can also be added during the creation of a smart form. This is to provide a streamlined process for the organization to send additional information to the supplier. The attachments will be carried forth in the downstream process.

Note

Preparers cannot modify or delete attachments in a smart form that are added by a catalog administrator.

Specifying Values on Smart Forms: Points to Consider

Values are dependent on the Procurement BU in which a smart form is created.

Dependent Values

The following is a list of the dependent values:

These values are reset if the catalog administrator updates the procurement BU before saving the smart form. Once a smart form is saved, the procurement BU field cannot be edited.

The catalog administrator can specify, using the User Editable checkboxes next to each field, to designate whether or not users can override the defaulted values.

Restricting Browsing Categories in Smart Form: Explained

By specifying a browsing category in the Restricted to Browsing Category field, you can restrict the list of item categories that the preparer can use when completing the smart form request in Oracle Fusion Self Service Procurement. The list of categories will be restricted to the item categories belonging to the specified browsing category.

If no value is specified in the Restricted Browsing Category field, the preparer can pick any item category.

Information Templates: Overview

Information templates are used in the creation of a Smart Form. They provide flexibility for your organization to add additional attributes in a smart form in order to gather the required information from a preparer. Information templates are also used to collect more information for specific items or items from a specific category during requisition creation.

Information Template: Explained

An information template is used to gather additional information from a preparer. It can be assigned to an item, a category, or a smart form. Information templates are used in the creation of a Smart Form to provide the flexibility to add additional attributes in a smart form in order to gather required information from a preparer. Information templates are also applicable to item master items and purchasing categories.

The data entered for an information template, which is associated with a smart form, item or category, is available as attachments in downstream products (such as Purchasing) after the requisition is approved. When creating an information template, the catalog administrator selects the attachment category that determines if the attachment will be available to the supplier or buyer.

Using Information Templates

Information Templates are created in a Procurement Business Unit and are available to Requisitioning Business Units serviced by that Procurement BU. In the event where a Requisitioning BU is serviced by multiple Procurement BUs, and more than one service provider had assigned an information template to an item or category, applicable information templates from all service provider Procurement BUs will be returned.

Information templates are available to the preparer if the items or smart forms that the information templates are associated with are available to the preparer.

Procurement catalog administrators can define a unique information template name so they are easily identifiable in a smart form. Information template header information provides users the ability to specify a non-unique Display Name, while creating information templates with unique information template names. For example, more than one procurement BU can maintain information templates to collect business card information. The same Display Name, Business card information, can be used on these information templates to indicate the purpose of these templates when displayed in Oracle Fusion Self Service Procurement. Procurement Catalog Administrators can also define an information template section description or instruction text providing preparers with specific instructions on how to fill out the form.

Information templates can only be deleted if they are not referenced. An information template is considered referenced if it is applied on any requisition lines, whether in completed or incomplete state. This is to prevent deletion of an information template that is currently in use.

Once an information template is deleted, it is no longer returned on the Manage Information Templates page.

Adding Attributes

Information template attributes are maintained as Descriptive Flex Fields (DFFs).

Attributes first need to be setup in the Descriptive Flexfields application, and the catalog administrator specifies the DFF context on the Create and Edit Information Template page to apply the list of attributes.

For example, the catalog administrator set up a context Business Cards Marketing, with the following context sensitive fields:

When creating an information template, the catalog administrator can then specify in the Attribute List field the context Business Cards Marketing, which will associate the attributes to the information template.

Note

The maximum number of attributes that can be created for an information template is fifty.

Existing information attributes are maintained as attachments downstream, such as in Purchasing.

Supported Attributes

The following attribute types are supported by DFFs:

End Dates

Procurement Catalog Administrators can specify an End Date on an information template. An information template is inactive if the system date is more than or equal to the End Date.

When an information template is inactive, it will no longer be applied when items (to which this information template is assigned) are added to the requisition. Requisitions created with lines that are associated to this information template will continue to display the information template information.

For incomplete requisitions, the inactive information templates are no longer available at the time the requisition is retrieved.

For copied and withdrawn requisitions, information templates are also no longer available if the information template is inactive at the time the requisition is copied or resubmitted.

Information Templates and Smart Forms : How They Work Together

An information template can be assigned to an item, a category and a smart form.

Adding Information Template to a Smart Form

During the definition of smart form, the procurement catalog administrator adds an information template to a smart form, so that the information template will be available for the preparer to provide additional information when requesting the item specified in the smart form.

Information Templates, Items and Categories : How They Work Together

An information template can be assigned to an item, a category and a smart form.

Items and Categories

The catalog administrator can specify the items and category associations when creating an information template. If the preparer adds an item to the requisition, information templates associated with the item or the category of the item will be available for the preparer to provide additional information before the requisition is submitted.

Define Procurement Content

Configure Requisition Business Function: Explained

The Procurement Application Administrator has access to the Configure Requisition Business Function page for setting up a business unit that has a requisitioning business function associated with it. The attributes specified here are used to default values and behavior of the application when users are creating requisitions and purchase orders for the requisitioning BU.

Requisitioning Section

Next Requisition Number

The Next Requisition Number is used to specify the next number to be used when generating a requisition. When a requisition is created online, the Next Requisition Number is assigned to the requisition; the number specified cannot be in use by an existing requisition. Note that when a requisition is created through the requisition import process, a numeric or alphanumeric requisition number can specified on the requisition record; it will be accepted if there is not in use by an existing requisition number.

Default Deliver-To Organization

The default organization is used as the deliver-to organization for a requisition line if it is a global location. This organization is used to derive the list of item master items that are accessible to the user when creating a purchase order for the requisitioning BU.

Line Type

The Line Type is the value specified to be defaulted on requisition lines created for the requisitioning BU. Line Type can be modified.

One-Time Location

The One-Time Location is the location code to be defaulted as the deliver-to location for the requisition line when the requester specifies a one-time delivery address on a requisition. The location specified must be a global location that is enabled for the requisitioning BU.

Reapproval required for changes made during an active approval process

Reapproval required for changes made during an active approval process is applicable when allowing approvers to modify a requisition when it is routed for approval. It controls whether the requisition must be sent back for reapproval when the approver submits the modified requisition.

Group Requisition Import

The Import Requisition process can be used to import requisitions from other Oracle or non-Oracle applications. On import, requisition lines are grouped first by requisition header number, then by the provided Group Code, then by the value set in the Group-by input parameter (None, Buyer, Category, Item, Location, or Supplier). The specified attribute is used as the default value for Group-by. All remaining requisition lines that have not yet been assigned a requisition number will be grouped together under the same requisition.

Create Orders Immediately for Requisition Import

Create orders immediately after requisition import controls whether the Generate Orders program will run immediately after the requisition import process is complete.

Purchasing News

The contents specified in Purchasing News is displayed in the Purchasing News section on the Shop Home page. If the URL and URL display name are specified, they are displayed on the Shop Home page for the requesters to drill down and view more information.

Context Values for Requisition Descriptive Flexfields

You can extend the attributes of a requisition at the header, line, and distribution level using Descriptive Flexfields. Specifying the context value pulls in the associated descriptive flexfields when the user enters the requisition.

Purchasing Section

Default Procurement BU

A requisitioning BU can be served by multiple procurement business units. If a procurement BU cannot be determined based on information on the requisition line, the Default Procurement BU is used to process all requisition lines.

Price Change Tolerance

The Price Change Tolerance is applicable when there is a price change on the purchase order line associated with a requisition line. If the value is null, no checks will be performed. If the value is a valid numeric value, then any changes made to the price on the purchase order line must be within the tolerance percentage value, or the purchase order cannot be submitted. The tolerance can be specified using the tolerance percentage or tolerance amount. The more restricting of the two tolerances will take precedence if both are specified.

Ship-to Location

When the purchase order cannot derive a ship-to location, the specified Ship-To on the Requisitioning BU is defaulted.

Cancel Backing Requisitions

Cancel Backing Requisitions controls whether a backing requisition should be canceled when there is purchase order cancellation.

Options are:

Allow Requester-To-Agreement UOM Conversion

If a requisition does not have an agreement specified, Allow requester-to-agreement UOM conversion is used to specify whether Requisition UOMs can be converted to Agreement UOMs during agreement sourcing. Checking this box indicates that agreements that meet the sourcing criteria, but have Agreement Line UOMs different from Requisition Line UOMs, can be considered during agreement sourcing. If the box is left unchecked, such agreements will not be considered.

Adding Price Breaks Using Loader: Explained

A price break is a discount when a certain number of items are purchased. Price breaks can be added to a BPA line through the upload process using either the TXT or XML file format. Multiple price breaks can also be added to a BPA line through Loader.

Loading Multiple Price Breaks with an XML File

Under each line (ITEM tag) which requires multiple price breaks, create multiple PRICE BREAK tags with the relevant details.

For example:

<ITEM lineNum="10" lineType="Goods" action="SYNC"
           <CATEGORY_NAME>Computers</CATEGORY_NAME>
           <DESCRIPTION>Lenovo Laptop</DESCRIPTION>
           <PRICE negotiated="Y">
               <UNIT_PRICE>2500</UNIT_PRICE>
               <UOM>Each</UOM>
               <AMOUNT />
               <PRICE_BREAK>
                       <QUANTITY>10</QUANTITY>
                       <BREAKPRICE>2490</BREAKPRICE>
               </PRICE_BREAK>
               <PRICE_BREAK>
                       <QUANTITY>40</QUANTITY>
                       <BREAKPRICE>2480</BREAKPRICE>
               </PRICE_BREAK>
           </PRICE>
</ITEM>

In this example, the line is meant to have two price breaks, so the PRICE BREAK tag occurs twice within the PRICE tag for the item Lenovo Laptop.

Loading Multiple Price Breaks with a TXT File

To upload multiple price breaks for a line using a TXT file, first include a line which has both the item details and the price break. Then include another line immediately after, and remove all other attributes except for the price break. For example:


Line Number

Description

Category Name

Internal Item Number

Manufacturer

Price

Quantity

Price Break

10

Lenovo Laptop

Computers

 

Lenovo

2500

10

2490

 

 

 

 

 

 

40

2480

20

Dell

Computers

 

Dell

2400

 

 

In this example, the item Lenovo Laptop has two price breaks. The first line in the table contains the item details and the first price break. The second line in the table is another price break for the first line that is the Lenovo Laptop. Note that on the second line the item details fields are all blank. Only the price break fields (Quantity and Break Price) contain data.

Tips

The following are tips for working with price breaks through Loader:

  1. To prevent multiple occurrence of the same price break for a line, if you wish to modify a line with an existing price break, you can do any of the following:

  2. If you wish to update the value for a price break attribute:

Note

To expire a line, set the expiration date for the line to: (system date minus 1).

Agreement Upload File Format

Agreement line attributes can be updated either using the Edit Agreement UI page or through a background process using agreement loader. Loader supports four file formats (TXT, XML, CIF, and cXML). These file formats have columns or tags which correspond to different agreement line attributes. The table below lists the supported agreement line attributes and the corresponding column name/tag in the different file formats.

Agreement Line Catalog Attributes

Agreement Line Attribute

Attribute Key

XML Tag

TXT Column

cXML Tag

CIF Column

Line Type

LINE_TYPE

Specified as an attribute of the ITEM tag. For example:

<ITEM lineType="Goods">

Line Type

Extrinsic. For example:

<Extrinsic name="LINE_TYPE">Goods </Extrinsic>

Parametric Data ({Name:Value pair}) for example: {LINE_TYPE = Goods;}

Category Name

CATEGORY

CATEGORY_NAME

Category Name

Classification

Classification Codes, SPSC Code

Item

ITEM

INTERNAL_ITEM_NUM

Internal Item Number

Extrinsic. For example:

<Extrinsic name="ITEM"> CM96715</Extrensic>

Internal Item Number

Revision

ITEM REVISION

Specified as an attribute of the INTERNAL_ITEM_NUM tag. For example:

<INTERNAL_ITEM_NUM revision="1">

Revision

Extrinsic for example:

<Extrinsic name="ITEM_REVISION"> 1</Extrinsic>

Item Revision

Supplier Item

VENDOR_PRODUCT_NUM

SUPPLIER_ITEM

Supplier Item

SupplierPartID

Supplier Part ID

Description

DESCRIPTION

DESCRIPTION

Description

ShortName

Short Name

Supplier Item Auxiliary Identifier

SUPPLIER_PART_AUXID

SUPPLIER_ITEM_AUXILIARY_IDENTIFIER

Supplier Item Auxiliary Identifier

SupplierPartAuxiliaryID

Supplier Part Auxiliary ID

Manufacturer Part Number

MANUFACTURER_PART_NUM

NAMEVALUE For example:

<NAMEVALUE name="MANUFACTURER_PART_NUM"> ORACLE-101 </NAMEVALUE>

Manufacturer Part Number

ManufacturerPartID

Manufacturer Part ID

Supplier URL

SUPPLIER_URL

NAMEVALUE For example:

<NAMEVALUE name="SUPPLIER_URL"> http://www.oracle.com </NAMEVALUE>

Supplier URL

URL

Supplier URL

Manufacturer URL

MANUFACTURER_URL

NAMEVALUE For example:

<NAMEVALUE name="MANUFACTURER_URL"> http://www.oracle.com </NAMEVALUE>

Manufacturer URL

Extrinsic. For example:

<Extrinsic name="MANUFACTURER_URL"> http://www.oracle.com </Extrinsic>

Manufacturer URL

Attachment URL

ATTACHMENT_URL

NAMEVALUE For example:

<NAMEVALUE name="ATTACHMENT_URL"> http://www.attachmentURL.com </NAMEVALUE>

Attachment URL

Extrinsic. For example:

<Extrinsic name="ATTACHMENT_URL"> http://www.attachmentURL.com </Extrinsic>

Parametric Data ({Name:Value pair}) for example: {ATTACHMENT_URL= http://www.attachmentURL.com;}

Thumbnail Image

THUMBNAIL_IMAGE

NAMEVALUE For example:

<NAMEVALUE name="THUMBNAIL_IMAGE"> http://www.oracle.com/thumbimage.jpg </NAMEVALUE>

Thumbnail Image

Extrinsic. For example:

<Extrinsic name="THUMBNAIL_IMAGE"> http://www.oracle.com/thumbimage.jpg </Extrinsic>

Parametric Data ({Name:Value pair}) for example: {THUMBNAIL_IMAGE= http://www.oracle.com/thumbimage.jpg;}

Manufacturer

MANUFACTURER

NAMEVALUE For example:

<NAMEVALUE name="MANUFACTURER"> Oracle </NAMEVALUE>

Manufacturer

ManufacturerName

Manufacturer Name

Image

PICTURE

NAMEVALUE For example:

<NAMEVALUE name="PICTURE"> http://www.oracle.com/image.jpg </NAMEVALUE>

Image

Extrinsic. For example:

<Extrinsic name="PICTURE"> http://www.oracle.com/image.jpg </Extrinsic>

Image

Availability

AVAILABILITY

NAMEVALUE For example:

<NAMEVALUE name="AVAILABILITY"> In Stock </NAMEVALUE>

Availability

Extrinsic. For example:

<Extrinsic name="AVAILABLITY"> In Stock </Extrinsic>

Availability

Lead Time

LEAD_TIME

NAMEVALUE For example:

<NAMEVALUE name="LEAD_TIME"> 6 </NAMEVALUE>

Lead Time

LeadTime

Lead Time

Long Description

LONG_DESCRIPTION

NAMEVALUE For example:

<NAMEVALUE name="LONG_DESCRIPTION"> Sun Blade Servers </NAMEVALUE>

Long Description

Description

Item Description

UOM

UOM_CODE

UOM

UOM

UnitOfMeasure

Unit of Measure

Price

UNIT_PRICE

UNIT_PRICE

Price

Money

Unit Price

Alias

ALIAS

NAMEVALUE For example:

<NAMEVALUE name="ALIAS"> Blades </NAMEVALUE>

Alias

Extrinsic. For example:

<Extrinsic name="ALIAS"> Blades </Extrinsic>

Parametric Data ({Name:Value pair}) for example: {ALIAS= Blades;}

Comments

COMMENTS

NAMEVALUE For example:

<NAMEVALUE name="COMMENTS"> Cooling Required </NAMEVALUE>

Comments

Extrinsic. For example:

<Extrinsic name="COMMENTS"> Cooling Required </Extrinsic>

Parametric Data ({Name:Value pair}) for example: {COMMENTS = Cooling Required;}

UNSPSC

UNSPSC

NAMEVALUE For example:

<NAMEVALUE name="UNSPSC"> 14111506 </NAMEVALUE>

UNSPSC

Extrinsic. For example:

 <Extrinsic name="UNSPSC"> 14111506 </Extrinsic>

Parametric Data ({Name:Value pair}) for example: {UNSPSC = 14111506;}

Expiration

EXPIRATION_DATE

EXPIRATION_DATE

Expiration Date

ExpirationDate

Expiration Date

Negotiated by Preparer Flag

NEGOTIATED_BY_PREPARER_FLAG

Specified as an attribute of the PRICE tag. For example:

<PRICE negotiated="Y">

Negotiated

 

 

Amount

AMOUNT

AMOUNT

Amount

 

 

Quantity

QUANTITY

QUANTITY

Quantity

 

 

Start Date

START_DATE

START_DATE

Start Date

 

 

End Date

END_DATE

END_DATE

End Date

 

 

Ship to Organization Code

SHIP_TO_ORGANIZATION_CODE

SHIP_TO_ORG

Ship-To Organization

 

 

Deliver To

SHIP_TO_LOCATION_ID

SHIP_TO_LOCATION

Ship-To Location

 

 

Break Price

PRICE_OVERRIDE

BREAKPRICE

Break Price

 

 

Discount Percent

PRICE_DISCOUNT

DISCOUNT

Discount

 

 

The upload files also contains columns or tags which are used by the loader process for internal processing. These attributes and the corresponding column name or tag in the different file formats are listed below:


Attribute

XML Tag

TXT Column

cXML Tag

CIF Column

Action

Specified as an attribute of the ITEM tag. For example:

<ITEM action="ADD">

Action

<IndexITemAdd>

<IndexItemDelete>

DELETE

Catalog Name

name

Title

File Name

File Name

Line Number

lineNum

Line Number

 

 

Language

Specified as an attribute of the CATALOG tag. For example:

<CATALOG xml:lang="en-US">

Language Section

Specified as an attribute of the DESCRIPTION tag. For example:

<DESCRIPTION xml:lang="en-US">

LANGUAGE

Translating Agreement Lines Through Agreement Loader : Critical Choices

Using Loader, a user can load translations for agreement lines.

Note

Translation through Loader is discussed from the point of view of Description-only Items and Item Master Items.

For all items, the following are the translatable catalog attributes:

Note

All other catalog attributes are nontranslatable.

During the upload process, if Loader encounters a line in the upload file which already exists in the agreement and the language is different from the language of the already existing line, Loader will interpret this line to be a translation.

In an upload file, language can be specified at the line level (CIF and cXML file formats) or at the file level (XML and TXT file formats). A language at the line level applies only to that line whereas a language at the file level applies to all the lines in the file.

Language is specified as a two letter language code defined in the ISO 639 standard, followed by a dash and then a two letter country code defined in the ISO 3166 standard. For example, en-US, ko-KR.

Before loading translations for items, the line must first exist in the created language of the blanket purchase agreement (BPA) or an error will be returned. The language in which the agreement header is created in is referred to as the Agreement Creation Language.

Description-Only items

If the profile option PO: Load Description Based Items in all Languages is set to Yes, when a line is uploaded in the creation language of the BPA, the translatable attributes are automatically loaded in all the installed languages in the application. If the profile option is set to No, the line is only loaded in the language specified in the upload file.

Item Master Items

When an item master item is first added to a blanket purchase agreement (BPA), all existing translations for the item (stored in inventory) will be copied over to the BPA. When a user subsequently loads translations for the item master items, updates from the user will overwrite the existing translations on the BPA.

If a user attempts to load item master items to a BPA where the created language is not one of the languages in which the item has been translated (or created) in inventory, an error is returned to the user.

Points to Consider

Some points to consider and tips are listed below:

Download Punchout: Explained

Download punchout is a mechanism for administrators to automatically download a supplier punchout definition from Oracle Exchange. The supplier definition is stored as a punchout catalog allowing requesters to easily access a supplier site through Oracle Exchange, from the Shop and Search pages.

Suppliers must define their punchout on Oracle Exchange before the punchout can be downloaded. Once the punchout is defined, the download punchout feature from the Manage Catalogs page can optionally be used to download one or more supplier punchout definitions.

Using Download Punchout

The existing punchout catalog is used to connect to Oracle Exchange and download the supplier punchout definitions. From the Supplier Web Store page in Oracle Exchange, you can select the supplier punchout definitions you want to download. When the download operation is successfully completed, a punchout catalog for each downloaded supplier will exist. Optionally, you can edit the punchout catalog to update the punchout name, description, keywords, mapping, and category assignment for browsing. Like any catalog, the downloaded punchout definition must be associated to a content zone to be available to requesters.

Note that for the translatable attributes such as catalog name and keyword, the supplier definition is downloaded for the languages available in Oracle Exchange.

Upload Lines Process: How It Works

The Agreement Loader is used to upload agreement lines in bulk using a data file. The catalog administrator, the buyer, or the supplier of the agreement can use the Agreement Loader. Loader parses the file based on the file format, performs basic validations on the data provided, and raises errors for failed validations. If no errors are found, the uploaded content is processed and the agreement is updated.

Settings That Affect Uploading Agreement Lines

If the number of lines with errors exceeds the error threshold, loader stops processing the remaining lines in the upload file. If the error threshold is not reached, loader continues processing the lines till it gets to the end of the file. In both cases, any of the lines processed successfully will be submitted for update against the agreement.

Examples of some Upload Error scenarios:

How The Agreement Loader Processes Lines

The agreement loader parses the input file in an accepted file format, and transfers the validated information to be updated against the agreement. The File formats that are supported by the Agreement Loader are CIF, cXML, TXT and XML.

If there are any parsing errors or other formatting issues, the agreement loader issues error messages. Loader performs some preliminary validations, like checking the validity of catalog attribute names, external mapping translations, data checks and so on. If there are any errors in these validations, an error is raised to the user.

If a line passes all the syntax and business validations, then it is submitted for update against the agreement.

The figure below illustrates a flowchart for how the agreement loader processes lines.

Agreement loader process flow

During any stage, if the number of lines with errors exceeds the threshold set by the user, the loading process is ended. Any lines which were successfully processed are submitted for updating against the agreement.

FAQs for the Upload Process

What happens if the upload has errors?

The Upload Errors page displays the errors for a given agreement or change order where the latest upload job completed with errors. Access the Upload Errors page by clicking the Error link in the upload status column. The Upload Errors page displays file level errors, parsing errors from XML parser, or agreement line level data validation errors. You can export the list of errors in a spreadsheet format. The errors displayed on this page are purged based on the value specified in the Error Retention Period (Days) field. This value is controlled through the profile PO_AGRMT_LOADER_PURGE_DAYS.

What's CIF or cXML?

A Catalog Interchange Format (CIF) file is a comma-separated text file. A commerce eXtensible Markup Language (cXML) .xml file is based on the XML language. The loader can process CIF or cXML files to load catalog items. Typically, the supplier gives you a CIF or cXML file they have prepared.

There are two kinds of CIF files: index and contract. Index files contain item definitions and their corresponding pricing. Contract files contain pricing only and are not supported by loader.

CIF files also support two types of loadmode, full and incremental. A full loadmode is a replacement of one catalog file with another, that is, all existing lines in the BPA are marked as having expired and then replaced with the lines from the upload. Also during a full load, the delete column in the upload file is ignored. If the delete flag has been set for a line in the upload file, the line will be loaded (after all existing lines in the BPA has been marked as being expired) and the line will not be marked for deletion.

In an incremental load, the only lines which are affected are those being uploaded. If a line being uploaded already exists on the BPA, this line is updated (or marked for delete if the delete flag for the line was set in the upload file).

If a loadmode is not specified, loader will assume an incremental loadmode. Valid loadmode values for CIF are Full, Incremental, F, I. These values are case insensitive. Valid loadmode values for cXML are FULL and INCREMENTAL. The values F, and I are not supported.

What's XML?

An eXtensible Markup Language (XML) file is a general purpose markup language file with a set of rules for encoding documents in machine-readable form. XML is a subset of Standard Generalized Markup Language (SGML). The primary purpose of XML is to facilitate the sharing of data across different systems. The upload process will parse and process the XML file to load agreement lines and its associated attributes provided that the XML file conform to the XML DTD.

Local Catalogs and Inclusion and Exclusion Rules : Explained

Catalog Administrators can control local catalog content visibility by agreements or category. For example, Administrators can restrict certain requesters to requesting items from a small set of approved agreements. Administrators can define items that should be included or excluded from the local catalog based on blanket agreement and category inclusion and exclusion rules.

Local Catalogs

A Local Catalog consists of items (item master items and agreement lines) and item attributes defined in Oracle Fusion Inventory and Oracle Fusion Purchasing such as categories, descriptions, UOM, and so on.

When defining a local catalog, content must be first separated into logical and manageable partitions. These partitions can be created based on purchasing categories, browsing categories, and blanket agreements. Each of the different options that can be used to define a local catalog is referred to as a dimension.

Once a local catalog is defined, it can be associated to content zones which are made accessible to the users assigned to see that catalog content.

Using Intersection for Restrictions Across Agreements and Categories

In a local catalog, items can be included or excluded based on the agreement and category inclusion or exclusion rules.

In order to determine the available local content, the application will resolve the inclusion or exclusion rules within a local catalog as illustrated in the table below:


Example

Local Catalog Setup (Inclusion versus Exclusion)

Available Content

A

Exclude Agreements {123, 456}, Include Category {Pens, Pencils}

Anything that is in the Pens category or in the Pencils category as long as they are not in Agreements 123 or 456.

B

Exclude Agreement {123}, Exclude Category {Pens}

All content as long as it is not in Pens or Agreement 123. For example, no content from Pens, and no content from Agreement 123.

C

Include Agreement {123}, Exclude Category {Pens, Pencils}

All items from Agreement 123, except those items that belong to Pens category or Pencils category

D

Include Agreement {123}, Include Category {Pens}

Only Pens from Agreement 123

Using Union for Restrictions in Separate Catalogs

Restrictions can also be separated. For example, excluding agreement 123, but including all office supplies content even if it is in agreement 123. In this case, separate catalogs are needed to define restrictions as union.


Example

Local Catalog Setup (Intersection versus Union)

Available Content

A

Catalog 1: Agreement {123} and Category {Pens}

Only Pens from Agreement 123.

B

Catalog 1: Agreement {123} Catalog 2: Category {Pens}

Anything that is in agreement 123 or in the Pens category.

C

Catalog 1: Agreement {123, 456} and Category {Pens}

Pens from agreements 123 or 456. Items must be pens, and they have to be in either Agreement 123 or 456.

D

Catalog 1: Agreement {123} and Category {Pens} Catalog 2: Agreement {456}

Pens from Agreement 123 or anything from Agreement 456.

E

Catalog 1: Agreement {123} and Category {Pens} Catalog 2: Agreement {456} and Category {Chairs}

Pens from agreement 123 or Chairs from Agreement 456.

F

Catalog 1: Agreement {123} and Category {Pens} Catalog 2: Agreement {456} Catalog 3: Category {Chairs}

Pens from Agreement 123 or anything from Agreement 456 or anything in the Chairs category.

G

Catalog 1: Exclude Agreement {123} Catalog 2: Category {Pens}

Anything in the Pens category or anything else not in Agreement 123.

Map Sets: Overview

Manage Supplier Content Map Sets allows the catalog administrator to create, duplicate, edit, and manage mappings between external and internal values for categories, UOMs, supplier names, and supplier sites. These mappings will be used for conversion in business flows such as shopping through Punchout or uploading lines through the Agreement Loader.

Using Supplier Content Map Set With Agreement Loader: Explained

A map set can be used when uploading agreement lines. The applicable attributes that can be mapped are category and unit of measure. The values as stated in the upload file are considered external values in this mapping process. When uploading agreement lines, the user can indicate if mapping should be applied to map the external value to a corresponding internal value for the attribute.

If the user chooses to apply mapping, a map set must be specified.

  1. If a default map set is setup for the procurement BU, the value is defaulted. The user can override the value.

  2. If no default map set is set up for the procurement BU, the user must then select a map set.

The following steps are used to determine a mapped internal value for the attribute:

  1. If a map set is specified, the map set will be searched during the mapping process to identify a matching external value to the attribute being mapped. If a match is found, the mapped internal value is used for further processing.

  2. If the external value is not found in the specified map set, the default map set for the Procurement BU of the agreement line will be searched for a matching external value. If a match is found, the mapped internal value is used for further processing.

  3. If the external value is still not found in the default map set, then the external value is not mapped, and is used as is for further processing.

Using Supplier Content Map Set With Punchout: Explained

A map set can be associated with a punchout catalog for the requested item's attributes when the shopping cart from a supplier punchout site is returned to Oracle Fusion Self Service Procurement.

When the punchout is to a supplier web store that only sells products from that supplier, mapping of the Category and Unit of Measure attributes are applicable. When the punchout is to an aggregator site, such as Oracle Exchange, mapping of the Category, Unit of Measure, Supplier, and Supplier Site attributes are applicable.

The values returned from the supplier punchout site are considered external values in this mapping process. When defining a punchout catalog, the catalog administrator indicates if mapping should be applied to map external values to corresponding internal values.

If mapping for the punchout catalog should be applied, a map set must be specified.

  1. If a default map set is setup for the procurement BU, the value is defaulted. The user can override the value.

  2. If no default map set is set up for the procurement BU, the user must then select a map set.

The following steps are used to determine an internal value mapping for the attribute:

  1. If a map set is specified, the map set will be searched during the mapping process to identify an internal value for the attribute being mapped. If a match is found, the mapped internal value is used for further processing.

  2. If the external value is not found in the specified map set, the default map set for the procurement BU of the punchout catalog will be searched for matching an external value. If a match is found, the mapped internal value is used for further processing.

  3. If the external value is still not found in the default map set, then the external value is used as is for further processing.

Manage Catalog Category Hierarchy

Catalog Category Hierarchy: Overview

Category hierarchy presents a hierarchical view of the catalog to users. Category hierarchies allow administrators to create a parent category that includes other categories, which are known as child categories. When users navigate through the parent category, the child categories appear, helping users to navigate quickly to the category which contains the products they need.

Category Browsing: Explained

There are multiple ways to search for items in the catalog. One way is to browse for items by category.

Browsing by Category

When you enter simple search criteria from the Shop page, the search results appear in a list from which you can sort, compare, add to your shopping list, or add to your requisition. For example if you search for pens your search will yield a list of pens that are available in the catalog.

Alternatively, you can search for pens using a category search. For example, in the Browse Category region on the Shop Page, you can click on the link for the category Office Supplies. The search results will yield a list of all office supplies in the catalog. You can then drill down the category hierarchy from the top level category Office Supplies selected on the Shop page. For example, the figure below shows if you were shopping for pens, you click on the category Office Supplies and then drill down using the category Pens and Pencils.

Figure showing drilling down in a browsing
category

Category Hierarchy with Catalog Association: Explained

Users can search for all content (local content, punchout, smart forms, informational content) regardless of how the content is grouped. Administrators can group punchout, informational catalogs, and smart forms by category and the browsing feature will also retrieve punchout, informational catalogs, and smart forms together with local content.

Local content (item master items and agreement lines) is associated with purchasing categories. Smart forms, punchout, and informational catalogs can optionally be associated with any level of the category hierarchy (browsing or purchasing category).

Hierarchy With Associated Catalog Content

When the user associates the punchout, informational, local, and smart form to a category, the system travels up and down the tree to associate the punchout, informational, local and smart form with all the browsing and purchasing categories of the same branch. Item master items, and agreement items are indexed with their corresponding purchasing categories. For example, in the illustration below, when the user navigates down the branch from Information Technology browsing category to the Computer Servers purchasing category, the search results will always include the Dell USA punchout which is associated with Computers. The system associates the punchout catalog Dell USA with the categories of the same branch as Computers which are Information Technology, Components for Information Technology, Computers, and Computer Servers.

The informational catalog How to Request Computer Services is associated with the browsing category Information Technology. As the user navigates the branch of Information Technology, the Informational Catalog is seen at the level of Information Technology, Components for Information Technology, System Cards, Computers, Memory Module Cards, and Computer Servers.

Local catalog items also show up during browsing. Using the example in the figure below, items in BPAs with suppliers Techworks or Zones Corporate that are tied to the purchasing categories Memory Module Cards or Computer Servers will show up as the user navigates down the Information Technology branch, based on the content available to the user via content zone.

The procurement catalog index is automatically updated after any changes to the hierarchy are saved.

The figure below shows catalog category hierarchy structure.

Catalog category hierarchy structure

Category Hierarchy: How Browsing Categories and Item Categories Fit Together

If you manage a large number of products and services you may need a mechanism to organize the products in the catalog to make it easier for users to navigate to the products they want to buy. The category hierarchy presents a hierarchical view of the catalog to users.

Category hierarchies allow you to create a parent category that includes other categories, which are known as child categories. When users navigate through the parent category, the child categories appear, helping users to navigate quickly to the category which contains the products they need. Categories are used to classify items.

You can develop your own method of categorizing products or you can use standard coding systems such as UNSPSC. Some of the benefits of adopting a standard coding system are visibility of spend analysis throughout the corporation, cost control optimization, and ability to explore all the ecommerce capabilities.

The figure below shows the category hierarchy for a catalog. There are two types of categories in the catalog that define a catalog hierarchy: Browsing categories and item categories. It is not required to have the same number of levels in all branches of the hierarchy.

Category hierarchy diagram

Browsing Categories

Browsing categories are also known as navigation categories. They define the category hierarchy for category browsing. The category hierarchy helps users browse for catalog items. Browsing categories can be either a parent or child to another category, but cannot contain any items. Browsing categories are optional and companies can decide what categories should be enabled for browsing.

You can associate catalogs (local, punchout, informational) and smart forms to the browsing categories. When user navigates to the category, the associated content type will be displayed. An alternative to setting up browsing categories is to tag punchout, informational, and smart forms with keywords, so that users can find them when performing basic search.

Item Categories

Item categories are used to group items for various reports and programs. A category is a logical classification of items that have similar characteristics. For Procurement, every item must belong to an item category. Item categories allow you to: