Requisitions Setup

Requisitions Setup Checklist

Use the following checklist for all setup related to requisition creation and management. The steps are organized by functional area. For example, all steps that concern setting up delivery information on requisitions appear together. This is a checklist of all setup steps in this chapter. These steps appear in a suggested, but not required, order.

Requisitions Setup Checklist
Number Step Functional Area Required or Optional Information Source
1 Foreign Currency Support Shopping Optional Foreign Currency Support
2 Information Templates Shopping Optional Information Templates
3 Suggested Buyer Delivery Optional Suggested Buyer
4 One-Time Address Delivery Optional One-Time Address
5 Purchase Order Grouping for Requisition Lines with One-Time Addresses Delivery Optional Purchase Order Grouping for Requisition Lines with One-Time Addresses
6 Hazard Information Delivery Optional Hazard Information
7 Global Requester Delivery Optional Global Requester
8 Charge Account Displays Billing Optional Charge Account Displays
9 Expense Charge Account Rules Billing Optional Expense Charge Account Rules
10 Employee P-Cards Billing Optional Employee P-Cards
11 Supplier P-Cards Billing Optional Supplier P-Cards
12 PO Extract for P-Card Reconciliation Billing Optional PO Extract for P-Card Reconciliation
13 Project Accounting Billing Optional Project Accounting
14 Grants Accounting Billing Optional Grants Accounting
15 Favorite Charge Accounts Billing Optional Favorite Charge Accounts
16 Approvals Approval Required if you have not implemented Oracle Purchasing Approvals
17 Global Approver Approval Optional Global Approver
18 Requisition Changes Requisitions Optional Requisition Changes
19 Requester-Initiated Changes to Purchase Orders Requisitions Optional Requester-Initiated Changes to Purchase Orders
20 Requisition Cancellations Requisitions Optional Requisition Cancellations
21 Life Cycle Tracking Requisitions Optional Life Cycle Tracking
22 Internal Requisitions Requisitions Optional Internal Requisitions
23 Oracle Services Procurement Requisitions Optional Oracle Services Procurement

Foreign Currency Support

Each time a requester searches for an item in a catalog, the search can display the currency associated with that item. This currency can be any valid currency defined in the application, including the functional currency. Similarly, users can make a non-catalog request in any valid currency. When these items are added to the shopping cart, the application converts the price for that item into the functional currency using the relevant exchange rate, and then displays the functional currency throughout the application.

The foreign currency feature displays the foreign currency price along with the functional currency price on key windows in the application.

The foreign currency can appear on the following pages:

Setup Steps

Decide whether to display the transaction currency price to requesters during checkout. Use Oracle Applications Framework personalization to display or hide the field.

The following table shows the default settings of transaction and functional prices and amounts in the shopping cart:

Price and Amount Fields by Default
Field Name Personalization Name Displayed or Hidden by Default?
Transaction Currency Price Price Displayed by default
Functional Currency Price FuncPrice Hidden by default
Transaction Amount TxnAmountFlow This field cannot be personalized
Functional Amount FuncAmount and TxnAsFuncAmount This field cannot be personalized

If you do not want to accept the defaults for Transaction Currency Price and Functional Currency Price, then use Oracle Applications Framework personalization to change them. For more information, see Personalize Oracle iProcurement Using Oracle Applications Framework.

To apply your changes to the Review and Submit page of the checkout process, apply your personalizations to that page.

Note: The Transaction Amount is hidden if the transaction currency is the same as the functional currency for all lines in the cart. It is visible if there is at least one foreign currency line. The Functional Amount always appears. Personalization does not control these fields.

Information Templates

You can set up information templates to gather additional information in Oracle iProcurement 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 such as business cards that require additional information (name, address, e-mail address, phone) from the requester. Oracle iProcurement prompts for name, address, e-mail address, 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.

Setup Steps

Create an information template

  1. Navigate to the Define Information Template window in Oracle Purchasing.

  2. Give your Template a name.

    This name appears as a heading during checkout.

  3. Select Available in All Organizations to make the template available to requesters in all operating units. Deselect this option to make the template available only to requesters in the same operating unit in which you are creating the information template.

    For example, you are logged in with a responsibility that is tied to the Vision France operating unit. If you leave this option deselected, then your information template is available only to users in your French operating unit.

  4. Select an Attachment Category of To Supplier or To Buyer.

    To Buyer means that the requisition, when turned into a purchase order, displays the information template as an attachment to the buyer. To Supplier means that the information template also is available as an attachment to the supplier.

  5. Enter an Attribute Name and Description. The Attribute Description is the actual field prompt that appears in Oracle iProcurement.

    Define Information Template Window

    the picture is described in the document text

    If you use Multilingual Support (MLS), you can enter translations for the following fields: Template, Attribute Name, Attribute Description, and Default Value. To enter the translations, select Translations from the View menu. For more information, see the Oracle E-Business Suite User's Guide.

  6. Optionally, enter a default value to automatically appear in the field.

    For example, for an Attribute Name of Body Color, the default value could be Black.

  7. To make the template field to be a list of values from which the requester selects, see the steps for creating lists.

  8. Indicate whether the field is mandatory for Oracle iProcurement requesters. If the field is mandatory, requesters must enter a value in the field before proceeding to complete the requisition.

  9. Indicate whether to activate the attribute to actually appear in Oracle iProcurement. In certain circumstances, you can define an attribute, but delay enabling it for display.

  10. Choose Associate Template to associate the template with an item or item category.

    Information Template Association Window

    the picture is described in the document text

  11. In the Information Template Association window select the type of association (Item Number or Item Category) to associate with the template.

  12. If you selected Item Number, enter the number. If you selected Item Category, enter the category.

  13. Save your work.

Create pop-lists

Complete these steps to make your template fields a menu of valid values. For example, you create a Country of Origin field. Instead of letting the requester enter any value, you provide a menu that contains only the values Canada, US, and Mexico.

For more information about the following steps, see the Oracle E-Business Suite Flexfields Guide.

  1. Log in to Oracle Purchasing.

  2. Use the following navigation: Setup > Flexfields > Validation > Sets.

  3. Create a flexfields validation set that satisfies the following criteria:

    • Format Type is Char, and Maximum Size is less than or equal to 240.

    • Validation Type is either Independent or Translatable Independent.

    • List Type is any of the provided options.

  4. Use the following navigation: Setup > Flexfields > Validation > Values.

  5. Search for the validation set name that you created and add values to it.

    For example, your validation set is Country of Origin, and the values are Canada, US, or Mexico.

  6. Access the Information Templates window the preceding instructions for defining information templates describe

  7. In the LOV field, select your validation set name.

  8. Save your work.

Implementation Considerations

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

The information template is also accessible through a Special Information link in the cart, if the requester wishes to update the fields after initially adding the items to the cart.

the picture is described in the document text

The preceding figure shows how information templates are associated with multiple lines in a cart, through the Special Information column. (The Special Information column appears by default.)

Suggested Buyer

As requisitions are created in Oracle iProcurement, it is possible to indicate the suggested buyer for each requisition and requisition line. You can define a buyer for any of the following:

If a buyer is found on any of the preceding items, then it becomes the default buyer in the corresponding purchase requisition based on its position in the document hierarchy. The Oracle iProcurement requester can accept this default or override it based on the list of buyers in the Suggested Buyer field on the requisition. This suggested buyer information is then passed to the resulting purchasing document and may be overridden during the document creation process.

Profile Options

Workflow

Implementation Considerations

One-Time Address

Requesters can specify alternate delivery locations, such as a home address, that are not an office location or other location from the database. This is a one-time address. This feature lets requesters specify the one-time address on a requisition line during the checkout process. The requester can associate the one-time address with specific requisition lines or with all requisition lines on a given requisition. One-time locations appear as line-level attachments on the resulting purchase order.

Setup Steps

To set up a default one-time address:

  1. Set up a dummy HR location to use as the deliver-to location on the requisition line whenever the requester specifies a one-time location. When defining this location, it might or might not be associated with an organization. If it is associated with an organization, then you must define a distinct location for every organization. You can set up this location on the Location window, which you can access from the Setup > Organizations > Locations...Purchasing menu.

  2. Set the value of the POR: One Time Location profile option to be equal to the name of the location that you created in the preceding step. You can set this profile value at the site, responsibility, or user level.

  3. By default, enter the address details. Use Oracle Applications Framework personalization to configure the address so that individual address lines are available. For more information, see Personalize Oracle iProcurement Using Oracle Applications Framework.

Profile Options

POR: One Time Location must be set to a location that has been previously defined in the Location window.

Function Security

You can restrict access to this functionality using menu function security. Under Menu Exclusions, exclude the function One Time Location. For information about function security setup, see Function, Menu, and Data Security.

Workflow

None

Implementation Considerations

No additional considerations.

Purchase Order Grouping for Requisition Lines with One-Time Addresses

As requisitions are created in Oracle iProcurement, it is possible to assign one-time addresses as the deliver-to locations for each line. Requesters specify one-time locations (delivery addresses) when they want to have heir ordered items delivered to a location that has not been previously defined (and most likely not used again). Delivery of items on individual requisition lines can be to distinct one-time locations. Each one-time location appears on the resulting purchase order line as an attachment.

In the case where the same item is found on two or more requisition lines, each with a separate one-time delivery address, the buyer or requester may not want these two (or more) requisition lines to be grouped onto the same purchase order line since there could be some confusion as to the quantity to be delivered to each location. The following figure details the requisition-to-purchase order process when one-time locations are employed:

the picture is described in the document text

As requisition lines are converted into purchase order lines, multiple requisition lines are grouped onto one purchase order line if certain characteristics, such as item and unit of measure, are the same. If one-time locations are associated with the requisition lines, each one-time location is represented on the resulting purchase order line as an attachment. Details of the main functional elements of the one-time location grouping functionality follow.

Grouping Options

Attributes in the PO Create Documents Workflow control the grouping feature and provide the requester the ability to not group requisition lines that contain one-time locations. The workflow looks at the available requisition lines to be converted into purchase order lines and first determines the value of these attributes to determine whether to group requisition lines with the same data.

The workflow attributes are:

Each of these attributes can have a value of Yes or No. Depending on the value selected, the workflow PO Create Documents behaves differently:

Note: When the attribute Is Grouping of One Time Address Line Allowed? is set to No, then no grouping of requisition lines with one-time locations occurs, even if the one-time addresses are the same.

The internal names of the preceding attributes are GROUPING_ALLOWED_FLAG and GROUP_ONE_ADDR_LINE_FLAG, respectively.

Append Quantity and UOM to Attachment

As one-time locations are converted and become attachments for the purchase order lines, these text attachments include the following information (for one-time location text attachments only):

The following is an example of the text of an attachment:

Please ship 30 (Each) to:

100 Mason St.

Palo Alto, CA

95320

Setup Steps

  1. Access the PO Create Documents Workflow. For more information, see Customize Workflows.

  2. Find the workflow attributes Is Grouping of Requisition Line Allowed? and Is Grouping of One Time Address Line Allowed?

  3. To modify the grouping logic, change the values of these attributes from Yes to No. Yes is the default value for both attributes. The following table details the results of the various attribute setting combinations:

    One-Time Location Grouping Attributes
    Is Grouping of Requisition Line Allowed? Is Grouping of One Time Address Line Allowed? Result
    YES YES Groups all similar requisition lines regardless of the existence of one-time locations.
    YES NO Groups similar requisition lines unless a one-time location is found on the requisition line.
    NO YES No grouping of requisition lines ever occurs.
    NO NO No grouping of requisition lines ever occurs.

Profile Options

Workflow

Implementation Considerations

Hazard Information

Requesters can indicate hazard information for each line item of a requisition. As requesters create requisitions in Oracle iProcurement, they can associate both a hazard identification number and a hazard class with a requisition line. In addition, if an item already has a hazard identification number or a hazard class linked to it, either from a source document or the item master, then this default information is copied to the resulting requisition line.

Setup Steps

By default, the hazard fields are hidden. To display them, use Oracle Applications Framework. For more information, see Personalize Oracle iProcurement Using Oracle Applications Framework.

Global Requester

Oracle iProcurement lets requesters create requisitions on behalf of another requester, even if that requester is in a different operating unit or business group. For example, a manager in the United Kingdom can order office supplies for a newly hired employee in the United States, even though the UK and the US represent different business groups. Possible scenarios include:

The process flow routes the resulting requisition for approval based on the preparer's approval path, when using an employee-supervisor hierarchy. When using a position hierarchy and the preparer or approver belongs to a different business group than the requester, then the preparer or approver must manually select an approver for the requisition. (The workflow cannot generate an approval list in this scenario.)

During Checkout, iProcurement shows the Requester field on the requisitiont. When global requester functionality is enabled, then clicking the Search icon next to this field lets you select requesters in other business groups.

Note: When you click the Flashlight icon, the list of available requesters includes all employees in the business group associated with the login responsibility, plus the preparer. For example, a manager in the UK logs on using the US responsibility. This manager sees everyone in the US business group, plus himeself.

If the global requester functionality is enabled while searching for requisitions on the Requisitions tab, then you can select the option Include employees from other organizations to expand the search to preparers or requesters in other business groups. The list of available preparers and requesters includes all employees in the business group associated with the login responsibility, plus the preparer.

Note: You can monitor only those requisitions that were created in the operating unit associated with your login responsibility. For example, a manager in the UK logged on using the US responsibility and created a requisition. When the manager logs on using the UK responsibility, the manager does not find the requisition. The manager finds it only when logging in using the US responsibility.

Setup Steps

  1. Set HR: Cross Business Group to Yes to allow the selection of requesters in other business groups.

    If this profile option is set to No, then preparers can select requesters in other operating units, but not in other business groups.

  2. Set the profile option ICX: Override Requestor to either By All or Within Organization.

    When ICX: Override Requestor is set to No, then the Requester field on the requisition defaults to the preparer and cannot be changed.

Profile Options

Function Security

Implementation Considerations

Displaying Charge Accounts

The following profile option determines how or whether to display charge account information at certain points during the checkout process:

Profile Options

Expense Charge Account Rules

When determining the default charge account, the account generator may reference the charge account defined on the employee record. Expense Charge Account Rules enable you to override one or multiple segments of that default account based on the item category. This ability to override does not interfere with the action of the account generator, but replaces those segments you configure after the account generator has created a charge account.

Setup Steps

  1. Log in to Oracle Applications and choose the Procure to Pay Administrator responsibility.

  2. Navigate to Purchasing Setup > Financials > Accounting > Expense Account Rules.

  3. Define the rules (for each item category) in the window. Duplicate rules for the same category or account segment are not permitted.

  4. Save your work.

Profile Options

Employee P-Cards

Employee P-Cards let companies incorporate electronic payment and settlement procedures to streamline their procure-to-pay processes. Employers assign each requester his or her own employee P-Card to make purchases using Oracle iProcurement.

Setup Steps

For more information about setting up procurement cards, see the sections on Setting Up Credit Card Programs and Procurement Card Management in the Oracle Payables User's Guide.

In addition to the setup steps provided in the Oracle Payables User's Guide, you must enable supplier sites to accept procurement cards.

  1. Log in to Oracle Applications. From the Oracle Purchasing menu, choose Supply Base > Suppliers.

  2. Query the supplier associated with the supplier site that you want to set up.

  3. Choose Sites. Query the supplier site for which you want to enable procurement cards.

  4. Select the Procurement Card check box to indicate that the supplier site is P-Card enabled.

  5. Save the changes.

Profile Options

Supplier P-Cards

Supplier P-Cards (or Ghost Cards) let companies incorporate electronic payment and settlement procedures to streamline their procure-to-pay processes. Instead of having to maintain a separate employee P-Card for each requester in the company and each requester having to use his or her own employee P-Card to make purchases, companies can maintain a single supplier P-Card for each supplier or supplier site in the system, and consolidate all purchases from that supplier or supplier site on the single P-Card. The feature lets all requisitions in Oracle iProcurement (across requesters) created against the respective supplier or supplier site be automatically charged to the single supplier P-Card. To enable the feature, the supplier P-Card must be set up and tied to the supplier or supplier site in advance. This arrangement improves control on the purchasing process and reduces maverick spending.

The following are the major business flows involved in the supplier P-Card functionality used in Oracle iProcurement:

Supplier P-Card Setup

To enable the supplier P-Cards feature, enable supplier or supplier sites to accept procurement cards.

  1. Log in to Oracle Applications. From the Oracle Purchasing menu, select Supply Base > Suppliers.

  2. Query the supplier associated with the supplier site.

  3. Choose Sites. Query the supplier site for which you want to enable procurement cards.

  4. Select the Procurement Card check box to indicate that the supplier site is P-Card enabled.

  5. Save the changes.

    After the supplier or supplier sites have been enabled for P-Cards, set up supplier P-Cards in Oracle Payables using a process similar to the setup for employee P-Cards. The following diagram shows the windows that you use to set up supplier P-Cards in Oracle Payables.

    Setup for Supplier P-Card

    the picture is described in the document text

    Card Programs: On this page, set up the following information for a P-Card: See the Oracle Payables User Guide for details.

    • Card Brand: Card brand name (American Express, Diners, Visa, Mastercard, and so forth).

    • Card Type: Select whether the card is of type Procurement, Travel, or Supplier. You can use only P-Cards of type Supplier and Employee in Oracle iProcurement. To set up a supplier P-Card, you would select a card type of Supplier.

    • Card Issuer/Issuer Site: Select a card issuer or issuer site for the card program. The card issuer or issuer site needs to be an active supplier or supplier site in the system.

    Card Profiles: On this page, associate card profiles to the card program. You can associate multiple credit card profiles with each card program. The profile records any transaction amount limits that are associated with a P-Card. These transaction limits are passed to the P-Cards (both employee and supplier) that you create using the profile. See the Oracle Payables User Guide for details.

    Note: When using the P-Card (employee or supplier) associated with the card profile for a requisition checkout in Oracle iProcurement, the transaction limit enforcement is::

    • If the aggregate amount (in functional currency for the operating unit) for all lines in the requisition checkout that can be charged to the P-Card is equal to or smaller than the transaction limit defined on the card profile, then the P-Card is assigned to all the lines.

    • If the aggregate amount (in functional currency for the operating unit) for all lenses) in the requisition checkout that can be charged to the P-Card is greater than the transaction limit defined on the card profile, then the P-Card is not assigned to any of the lines.

    Credit Cards: On this page, define the P-Card and associate it with a card program and card profile. See the Oracle Payables User Guide for details.

    In the Credit Cards window:

    1. Enter Information for the P-Card, such as the card number and expiration date.

    2. Associate the card with the card program and card profile.

    3. If the card program is of type Procurement, then enter additional information about the employee who would own the P-Card.

    4. If the card program selected is of type Supplier, then enter the supplier or supplier sites, which are to be associated with the supplier P-Card. The business rules for associating the P-Card to a supplier or supplier site when the card program selected is of type Supplier are:

      • You cannot complete the fields in the window that apply for a card program of type Procurement (such as Card Member Name, Employee Name, and Employee Number).

      • The supplier and supplier site fields on the window are mandatory. That is, each supplier P-Card must have at least one supplier or supplier site associated with it.

      • You can associate each supplier site only with a single supplier P-Card.

      • You can associate a single supplier P-Card with (shared by) multiple supplier sites as long as the supplier sites belong to the same supplier.

      • You can associate supplier sites within a supplier with different supplier P-Cards.

      • The Select All Eligible Sites button provides the requester the ability to enter the multiple supplier sites. Clicking this button automatically completes the supplier site fields for the selected supplier with valid but unassigned (that is, the site is not assigned to another supplier P-Card) supplier sites for the selected supplier.

    For additional information about setting up supplier P-Cards, see the Oracle Payables User's Guide.

Supplier P-Card Assignment for Requisitions

When the requester creates a requisition in Oracle iProcurement, one of the following payment methods can be assigned to each line on the requisition:

As the requester is checking out a requisition in Oracle iProcurement, the application verifies and determines which payment method to assign to each line on the requisition. The first payment method (employee P-Card) is an option which the requester can explicitly select during the requisition checkout. When certain conditions are met (the requester does not have to explicitly select them), the application automatically assigns the other payment methods (supplier P-Card and no P-Card) to the requisition line.

Note: A requisition in Oracle iProcurement can contain multiple lines. Depending on the source of the item or service on the line (internal or from external supplier or supplier site), the type of the item (expense or inventory) and other setup, different payment methods could apply to each line. Hence, the assignment of the payment method is done at the requisition line level, and not at the requisition header level.

The following business rules apply for the assignment of payment methods to a requisition line during checkout:

  1. No P-Card (neither employee P-Card nor supplier P-Card) can be assigned to a requisition line in the following cases:

    • No supplier or supplier site is available or selected for the requisition line.

    • The item or service on the requisition line is sourced internally.

    • The supplier or supplier site available or selected for the requisition line is not P-Card enabled.

    • No employee P-Card has been set up for the requester and no supplier P-Card has been set up for the supplier or supplier site that is available or selected for the requisition line.

    • The requisition line is associated with a project, in which case a P-Card (employee or supplier) cannot be assigned to the line.

    • For an inventory item being delivered to a subinventory, a P-Card (employee or supplier) cannot be assigned to the line. On the other hand, if the inventory item is not delivered to a subinventory, then a P-Card (employee or supplier) can be assigned to the line.

  2. If none of the preceding cases is met, then P-Cards (employee or supplier), if set up, are eligible to be assigned to the requisition line. Only one of them can be applied, and Oracle iProcurement determines which one to apply during the requisition checkout process.

    To provide maximum flexibility, a system profile controls which P-Card (employee or supplier) gets precedence when both P-Card types are eligible to be applied to the requisition line. The profile option is POR: Override Supplier P-Card. This profile option applies to the Supplier P-Card Assignment for Requisitions business flow.

  3. The following figure shows the business logic for assignment of P-Cards to a requisition line during a checkout if none of the cases mentioned in Rule #1 applies, and if the POR: Override Supplier P-Card profile option is set to No.

    Supplier P-Card Assignment for Profile Set to No

    the picture is described in the document text

  4. The following figure shows the business logic for assignment of P-Cards to a requisition line during a checkout if none of the cases mentioned in Rule #1 applies and if the POR: Override Supplier P-Card profile option is set to Yes.

    Supplier P-Card Assignment for Profile Set to Yes

    the picture is described in the document text

  5. After the application has determined the payment method for the requisition lines during checkout, the information is visible to the requester. Access to this information is available on the Review and Submit page during checkout, and also on the Requisition Details page after the requisition has been submitted. If an employee P-Card has been assigned to at least one line on the requisition, then the partially masked employee P-Card number appears in the P-Card Number field at the requisition header level. At the requisition line level, the P-Card Used field indicates which payment method is assigned to that particular line. The possible values for this field are:

    • Yes, when employee P-Card is assigned to the line

    • Supplier P-Card, when supplier P-Card is assigned to the line

    • No, when no P-Card is assigned to the line

    • Only one employee P-Card can be used for each requisition, and it might or might not apply to all the lines on the requisition. The P-Card Number field at the requisition header level contains either a single partially masked employee P-Card number or a blank value.

    • The requester does not see the actual supplier P-Card number (neither in the P-Card Number field at the requisition header level nor in the P-Card Used field at the requisition line level). The value of the P-Card Used field at the requisition line level (when it is Supplier P-Card) is the only indication to the requester that a supplier P-Card has been assigned to the line.

Common P-Card Logic

The requisition that is created in Oracle iProcurement is converted into a purchasing document in Oracle Purchasing. When all the necessary conditions are met, the resulting purchase order document contains the supplier P-Card number that was associated with the requisition line. The processes in Oracle Purchasing to convert a requisition into a purchase order include:

Requisition-to-Purchase Order Conversion Processes

Note: If purchase orders are created directly or are created from requisitions submitted in Oracle Purchasing (that is, there is no associated requisition in Oracle iProcurement), then no P-Card can be assigned to the purchase order, even if the particular supplier or supplier site accepts P-Cards.

The logic to determine how and which P-Card number (employee or supplier or none) should be applied to the purchase order works as indicated in the following table. This logic applies to all the requisition-to-purchase order conversion processes.

Common P-Card Logic
Number Value of P-Card Number for Requisition Header Value of P-Card Used Flag for Requisition Lines Requisition-to-Purchase Order Conversion Logic in Oracle Purchasing
1 None Yes Scenario is NOT possible. If no P-Card number is at requisition header level, all values for P-Card Used flag should be either No or Supplier.
2 None No No employee P-Card can apply to purchase orders.
For such requisition lines:
If requisition lines have same supplier or supplier site and other purchase order header level information, then requisition lines can appear on a single purchase order.
Else, requisition lines appear on different purchase orders.
3 None Supplier No employee P-Card can be applied to purchase order.
Derive supplier P-Card defined for supplier or supplier site:
If supplier P-Card is valid (see Validity Verification), maintain supplier P-Card for requisition lines.
If supplier P-Card is invalid, delete supplier P-Card for requisition lines.
For such requisition lines:
If requisition lines have same supplier or supplier site and other purchase order header level information, then requisition lines can be put on a single purchase order.
Else, requisition lines appear on different purchase orders.
4 Employee P-Card Number Yes Employee P-Card from requisition header can be applied to purchase order:
If employee P-Card is valid (see Validity Verification), maintain employee P-Card for requisition lines.
If employee P-Card is invalid, delete employee P-Card for requisition lines.
For such requisition lines:
If requisition lines have same supplier or supplier site and other purchase order header level information, then requisition lines can be put on a single purchase order.
Else, requisition lines appear on different purchase orders.
5 Employee P-Card Number No Do not apply employee P-Card from header level to lines.
For such requisition lines:
If requisition lines have same supplier or supplier site and other purchase order header level information, then requisition lines can be put on a single purchase order.
Else, requisition lines appear on different purchase orders.

Note: Validity verification for employee and supplier P-Cards includes:

P-Cards In The Purchase Order Autocreate Window

In addition to the logic discussed in the preceding table, when a buyer in Oracle Purchasing converts a requisition into a purchase order using the Purchase Order Autocreate window, the buyer can resolve or change the supplier or supplier site at that time. Even if the buyer selects a supplier or supplier site that accepts supplier P-Cards, the P-Card information is not applied at that time. In other words, only the requisition lines that have P-Card information assigned to them during the requisition checkout in Oracle iProcurement can have P-Cards assigned to them in the resulting purchase order.

Changing Supplier Or Supplier Site On A P-Card Purchase Order

Even if a P-Card is assigned to the purchase order, the buyer has the ability to change the supplier or supplier site on the purchase order. The new supplier or supplier site might not accept P-Cards (employee or supplier) and it could lead to an error condition. Hence, if a P-Card (employee or supplier) exists on a purchase order, and, if the buyer changes the supplier or supplier site on the purchase order, the application automatically deletes the P-Card number on the purchase order. Before doing so, the application generates an appropriate warning message for the buyer.

Purchase Order Communication to Supplier

When the purchase order with the assigned supplier P-Card has been created and approved, the supplier P-Card information is sent as a part of the purchase order when it is communicated to the supplier. The information sent is adequate for the supplier to charge the amount on the purchase order to the assigned supplier P-Card. Similar to the existing support for the employee P-Card, the following information for the supplier P-Card is sent as a part of the purchase order:

Also, similar to existing support for employee P-Cards, the supplier P-Card information is included as a part of the purchase order only when the purchase order is communicated to the supplier through EDI delivery and XML delivery.

For information about purchase order communication to the supplier using EDI delivery, see the Oracle e-Commerce Gateway User's Guide. For more information about purchase order communication to the supplier through XML delivery, see the Oracle Purchasing XML Transaction Delivery Guide and the Oracle XML Gateway User's Guide.

Profile Options

Purchase Order (PO) Extract for P-Card Reconciliation

The P-Card reconciliation process electronically reconciles the P-Card statements and the corresponding purchase orders in the buyer's purchasing application for both employee and supplier P-Card transactions. The card issuer typically provides the reconciliation engine, which resides in the buyer's purchasing system. To accommodate the reconciliation process, the engine needs a couple of information feeds:

This reconciliation is necessary so that the buyer is able to electronically verify that only valid supplier purchase orders are included in the invoices that are paid to the card issuer. After a successful reconciliation between the PO history feed and the transaction feed, the reconciliation engine sends the reconciled data files to Oracle Payables (using the Oracle Payables Open Interface). The following figure shows the flow for the P-Card reconciliation process:

the picture is described in the document text

For more information about this part of the process, see the documentation provided with the reconciliation engine and the Oracle Payables User's Guide.

At the end of the P-Card billing cycle, the buying company receives a transaction feed containing an electronic statement for all P-Card purchases that the buying company made. The Purchase Order Extract for P-Card Reconciliation feature:

Major Features

PO History Feed Concurrent Report

The concurrent report accumulates and compiles the necessary PO history data in a specific format. Upon its completion, the output file is stored in a specified directory location. The following business rules apply to the concurrent request:

Criteria Selection of Purchasing Records

Only purchase orders that satisfy certain selection criteria are included in the PO history feed. Some of the selection criteria for the purchase records are entered on the PO History Feed Report Request window (as described in the preceding section), while the application automatically and internally applies the rest of the selection criteria. The internal selection criteria are:

The following figure indicates the selection logic based on the Approval, Control, and On Hold statuses of the purchase order in Oracle Purchasing and the appropriate output status for the purchase order in the PO History Feed.

Status and Selection Logic
Number Approval Status Control Status On Hold Status Selection and Status of Purchase Order in PO History Feed
1 Approved All except Canceled and Finally Closed Not On Hold PO is sent with Order Status = ON
2. Approved All except Canceled and Finally Closed On Hold PO is sent with Order Status = HL
3 Approved Canceled OR Finally Closed Does Not Matter PO is sent with Order Status = CN
4 In Process Does Not Matter Does Not Matter PO is not sent
5 Incomplete Does Not Matter Does Not Matter PO is not sent
6 Pre-approved Does Not Matter Does Not Matter PO is not sent
7 Rejected Does Not Matter Does Not Matter PO is not sent
8 Requires Reapproval1. All except Canceled and Finally Closed Does Not Matter If (PO APPROVED_DATE ¹ NULL), PO is sent with Order Status = HL
If (PO APPROVED_DATE = NULL), PO is not sent
9 Requires Reapproval3. Canceled or Finally Closed Does Not Matter If (PO APPROVED_DATE ¹ NULL), PO is sent with Order Status = CN
If (PO APPROVED_DATE = NULL), PO is not sent

For information about the format and data elements of PO History Feed, see PO History Feed File.

Setup Steps

The output of the concurrent program is stored in a specific directory. The directory is derived from the UTL_FILE_DIR parameter in the INIT.ORA file of the Oracle Purchasing installation. For more information about setting the output directory location, see the Oracle e-Commerce Gateway Implementation Manual.

Project Accounting

Integration with Oracle Projects enables requesters to optionally reference project and task information on requisition lines. Cost distribution of a single requisition line can span one or more projects.

Setup Steps

You must license and implement Oracle Projects. For more information, see the Oracle Projects Implementation Guide.

When you are implementing Oracle Projects, decide whether to expose the project and task fields to requesters:

To hide any of the project-related fields, then use Oracle Applications Framework. For more information, see Personalize Oracle iProcurement Using Oracle Applications Framework.

Note: If you have installed Oracle Projects, then the project-related fields appear in the Billing section of the requisition, even if you do not implement or use Oracle Projects. You can hide these fields if you do not use them.

Grants Accounting

Oracle Grants Accounting integrates with Oracle iProcurement to support the charging of requisitions and resulting purchase orders to projects that grants (awards) funded. The integration introduces the concept of an award number, which represents additional information about the source of funding associated with projects and tasks.

In addition to the standard project and task information, the Award dimension from Oracle Grants Accounting can specify the source of funding associated with projects and tasks. This helps organizations manage all aspects of the grant funding they receive. In higher education institutions, other public sector agencies, and project-intensive commercial enterprises, it is often necessary to distribute the cost of a purchase request line across multiple projects. To support this need, you can enter multiple projects and awards for each requisition line.

You must enable the Award number field if you have implemented Oracle Grants Accounting for the associated operating unit. The Award number field is only required for projects that awards in Oracle Grants Accounting fund.

Setup Steps

You must license and implement Oracle Projects and Oracle Grants Accounting. For more information, see the Oracle Grants Accounting User's Guide.

By default, the Award field appears if you have implemented Oracle Grants Accounting for the associated operating unit. To hide this field, use Oracle Applications Framework. For more information, see Personalize Oracle iProcurement Using Oracle Applications Framework.

Favorite Charge Accounts

The favorite charge accounts functionality provides the requester the capability to maintain a list of up to 50 frequently used charge accounts on the iProcurement Preferences page. During the checkout process, the requester can access the favorite charge accounts list and use it to automatically complete the charge account information for the items, rather than having to manually enter the charge account information.

Setup Steps

  1. Log in to Oracle iProcurement.

  2. On the Home page, click Preferences in the upper-right corner.

  3. In the Preferences area, click iProcurement Preferences.

  4. Enter Favorite Charge Accounts and a nickname for each account. To add another row, click Add Another Row.

  5. Select a default favorite charge account.

  6. Save the changes.

Function Security

Implementation Considerations

Approvals

You can conduct requisition approvals in Oracle iProcurement in the following ways:

The following figure shows that an employee and supervisor approval setup in Oracle Purchasing consists of:

Approval Setup in Oracle Purchasing

the picture is described in the document text

The following figure shows how the approvals setup appears using AME. For descriptions of each of these steps, see the AME implementation steps.

Approval Setup Using AME

the picture is described in the document text

Whether you set up approvals in Oracle Purchasing or AME, the Requisition approval workflow in Oracle Purchasing handles the approval. For example, the Approval List Routing Using AME process in the Requisition approval workflow is initiated if AME approvals have been set up. (See the AME Implementation Steps.) This process uses your approval setup in AME to perform the approval, send notifications, and complete other approval tasks in Oracle iProcurement.

Implementing Oracle Purchasing Approvals

For instructions, see the approval setup information in the Oracle Purchasing User's Guide. See also information about requisition approval workflow attributes, whose defaults you can change, in the Oracle Purchasing User's Guide.

Implementing AME Approvals

  1. Offline, analyze your approval structure. Determine the approval structure to use in iProcurement

    An example of Employee/Supervisor approval structure:

    • Meredith Walton, Buyer, reports to

    • Pat Stock, Manager, reports to

    • Casey Brown, Executive

    An example of Position Hierarchy approval structure:

    • Shop Floor Manager reports to

    • Production Manager who reports to

    • Plant Manager

  2. If you are going to use the Employee/Supervisor structure you must perform the following tasks:

    1. In the Human Resources responsibility, navigate to the Job Window.

    2. Create a job.

    3. Assign approval authority to the job.

    4. Create employees and assign appropriate jobs and supervisors.

    5. Create users.

    6. Add appropriate responsibilities to the users.

    For complete details on performing these steps, see: Oracle HRMS Enterprise and Workforce Management Guide.

  3. If you are going to use the Position Hierarchy structure you must perform the following tasks:

    • In the Human Resources responsibility, navigate to the Positions Window.

    • Create all of your organization's positions.

    • Use the Position Hierarchy window to build and administer your position hierarchies.

    • Create employees and assign them to the referenced positions with the Enter Person window.

    • Use the Submit Requests window to run the Fill Employee Hierarchy process.

    • Create users.

    • Add appropriate responsibilities to the users.

    For complete details on performing these steps, see: Oracle HRMS Enterprise and Workforce Management Guide.

  4. In Oracle Purchasing, navigate to the Document Types window.

  5. Select a Document Type:

    • Purchase Requisition

    • Internal Requisitions

    • Change Order Request: Requisition

  6. For the selected document type, select one of the provided Approval Transaction Types, or one that you created in AME:

    • PURCHASE_REQ

    • INTERNAL_REQ

    • RCO

    Document Types Window

    the picture is described in the document text

    Note: Use the Approval Transaction Types field to enable or disable AME. If a transaction type is selected in this field, then Oracle iProcurement uses AME to conduct approvals. If you leave the Approval Transaction Types field blank, then AME approvals are not used. Instead, the approval setup in Oracle Purchasing are used.

  7. Use the Oracle Approvals Management Implementation Guide, available on My Oracle Support forum to complete the following steps:

    • Create attributes. See the following list of attributes that Oracle iProcurement provides. For example:

      • ITEM_CATEGORY (line level)

      • REQUISITION_TOTAL (header level)

    • Create conditions using the attributes. Conditions are the "if" clause in an action rule. They are similar to approval groups in Oracle Purchasing. For the rule to apply to a transaction, all of its conditions must be true.

      For example, to enforce a rule about a requisition's total amount, you could have the following condition, where REQUISITION_AMOUNT is an attribute: USD1000 <= REQUISITION_AMOUNT < USD5000. In this example, a requisition initiates this approval rule when the requisition total amount is greater than or equal to 1000 USD and under 5000 USD.

    • Create approval groups. An approval group is an ordered set or list of one or more approvers. For example, an approval rule can add an approval group's members, in order, to a transaction's approval list. Typically, approval groups represent functional approvers outside a transaction's chain of authority, such as finance or internal legal counsel, who must approve a transaction before or after management has done so. You can also insert an approval group into the chain of authority.

    • Define actions. Actions generate the approval list for a transaction. If a transaction satisfies all conditions in an action rule, then the associated actions are processed to generate the approval list.

      • The Action Types page is where you would define approval groups with the same order number to enable parallel approval.

      • It is also the page where you define voting methods. This provides you with the ability to model group approvals more closely to the business rules that your organization uses. For example, you might choose First Responder Wins.

    • Create action rules.

      Define rules based on the conditions that result in an action. For example:

      • If the condition USD1000 <= REQUISITION_AMOUNT < USD5000 is met, then require approvals up to at least level 1 approval authority.

      • If the condition USD5000 <= REQUISITION_AMOUNT < USD9000 is met, then require approvals up to at least level 2 approval authority.

Example

In the following example:

  1. If the condition 0 USD <= REQUISITION_TOTAL <= 100 USD, then require approvals up to at least level 1.

  2. If the condition 1000 USD < REQUISITION_TOTAL <= 25000 USD, then require approvals up to at least level 2.

  3. If the condition ITEM_CATEGORY in {IT.EQUIPMENT...}, then require post-approval from IT approval group.

Name Job Approval Authority
Meredith Walton Buyer 1
Pat Stock Manager 2
Casey Brown Executive 3
Connie Horton (in the IT approval group) IT Manager 4

Provided AME Attributes

Oracle iProcurement provides the following types of AME attributes:

The following tables display and describe the attributes that Oracle iProcurement provides for use by AME.

AME Mandatory Attributes
Mandatory Attribute Name Attribute Type Attribute Description Static Usage?
ALLOW_DELETING_RULE_GENERATED_APPROVERS Boolean Requisition preparer allowed to delete system-generated approvers?
The value is derived from the POR: System Approvers Are Mandatory profile option, for the user or responsibility. It determines whether the user can delete mandatory approvers from the system-generated approver list during checkout.		 No
ALLOW_REQUESTOR_APPROVAL Boolean Determines if preparer can approve own requisitions if preparer has enough approval authority. The value is derived from the document type setup for the requisition (Purchase, Internal, or Change Order Request). No
AT_LEAST_ONE_RULE_MUST_APPLY Boolean AME raise exception when no rules apply to a transaction? Yes
EFFECTIVE_RULE_DATE Date Date that determines active rules. The default provided value assumes every rule is effective. Yes
EVALUATE_PRIORITIES_PER_LINE_ITEM Boolean Determines whether to evaluate rule priorities for each line item under strict line-item evaluation Yes
REJECTION_RESPONSE String How AME responds to a rejection Yes
USE_RESTRICTIVE_LINE_ITEM_EVALUATION Boolean Determines whether to require that the same line item satisfy all line-item conditions in a given rule Yes
USE_WORKFLOW Boolean Determines whether Oracle Approval Manager should log exceptions to the workflow context stack  
WORKFLOW_ITEM_KEY String Requisition approval workflow's item key No
WORKFLOW_ITEM_TYPE String Workflow item type No
AME Non-Mandatory Header Attributes
Non-Mandatory Header Attribute Name Attribute Type Attribute Description Static Usage?
REQUISITION_TOTAL Currency Total of all requisition lines that have not been canceled, given in the functional currency. Conversion method is derived from POR: Default Currency Conversion Rate Type for the user. General Ledger currency conversion must be enabled. No
JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID Number Person ID of non-default first approver for job-level authority approval types Yes
INCLUDE_ALL_JOB_LEVEL_APPROVERS Boolean Determines whether to include all approvers at a given job level Yes
TRANSACTION_DATE Date Date when requisition was created No
TRANSACTION_GROUP_ID Number Business group identifier (ID) of the requisition preparer No
TRANSACTION_ORG_ID Number Operating unit in which the requisition was created No
TRANSACTION_REQUESTOR_PERSON_ID Number Person ID of the requisition preparer No
TRANSACTION_REQUESTER_USER_ID Number User ID of the person initiating the transaction No
TRANSACTION_SET_OF_BOOKS_ID Number ID of the set of books that owns the transaction. The value is derived from the Financials System Parameters for the operating unit. No
AME Non-Mandatory Line Attributes
Non-Mandatory Line Attribute Name Attribute Type Attribute Description Static Usage?
PO_NATURAL_ACCOUNT String Natural Account: Segment of the accounting flexfield that is specified as the Natural Account Segment. The value is derived from the natural account segments for the charge accounts specified on the requisition line distributions. No
PO_COST_CENTER String Cost Center: Segment of the accounting flexfield that is specified as the Cost Center Segment. The value is derived from the cost center segments for the charge accounts specified on the requisition line distributions. No
ITEM_NUMBER String Item Number: Item number composed by concatenating all segments defined on the Item key flexfield. The value is derived from the item number associated with the requisition line. No
ITEM_CATEGORY String Item Category: Item category composed by concatenating all segments defined on the Item Category key flexfield. The value is derived from the item category associated with the requisition line. No
DELIVER_TO_LOCATION String Deliver-to Location: The value is derived from the deliver-to location specified on the requisition line. The value is the location code in the database base language. (AME does not use multi-lingual support that is provided in the Oracle Applications setup windows.) No

Note: A requisition has a header, lines, and distributions. AME does not support three levels of attributes. Therefore, the definition of a line is a combination of the line and distribution information. For example, a requisition line with two distributions is considered as two lines in AME approvals.

Profile Options

Function Security

Workflow

Global Approver

As requisitions are created in Oracle iProcurement, approval paths are generated. You can set up the list of approvers to include employees belonging to different business groups. For example, it is possible for requester A from business group 1 to have his or her requisition routed to approver B from business group 2. In addition, approvers from different business groups can be manually inserted into the approval list. As such, the list of values for approvers can include a column containing the business group of each potential approver.

Approvers can view the requisition details from the notifications pages, even if the requisition was created in a different operating unit. Requisitions that were created in a different operating unit are not available through the general requisition status pages nor are they available for modification. The approval action history display includes business group information for each approver.

Setup Steps

If any approvers in the hierarchy are employees in different business groups, then set the profile option HR: Cross Business Groups to Yes before you set up your approval hierarchy.

Profile Options

Requisition Changes

A requester in Oracle iProcurement can change a requisition after it has been submitted. Requesters can change the requisition at any time prior to its conversion to a purchase order, even though it currently is on an approver's notifications list. When the requisition is in the change process, it is removed from the current approver's notification list. (It is withdrawn from the approval process.)

Note: A different change process occurs if the requisition line has been placed on an approved purchase order. For more information, see Requester-Initiated Changes to Purchase Orders.

Either requesters or approvers can make changes to requisitions.

Requester-Initiated Changes

Approver-Initiated Changes

The approver can also make changes to a requisition while approving it. The approver can add, delete, or modify the requisition lines. When finished, the approver checks out the requisition again. The checkout is initiated from a special Approver Shopping Cart. (For more information, see the online Help.)

In some cases, the approver checkout process assumes the requisition preparer's information. In other cases, the approver's. These assumptions are taken during defaulting and validation. For example, if the approver adds a line to the requisition, the Need-By Date defaults from the preparer's preferences, not the approver's. In the Approver Shopping Cart and checkout process, all requisition lines (even the unchanged ones) are validated again. For example, the system verifies whether the account information on the requisition remains valid.

The following table shows the information that either the preparer or the approver assumes during the approver checkout.

Information Preparer or Approver
Oracle Applications Framework personalization and page functions Approver
Function security Approver
Favorite charge accounts list Approver
General preferences, such as Date Format Approver
iProcurement preferences, such as Need-By Date Offset Preparer
Billing and encumbrance, such as list of valid projects and tasks Preparer
Validation (for example, that the account information remains valid) Preparer
P-card and p-card profile Preparer
Delivery related profile options such as ICX: Override Requester Preparer
Account generation, if the account cannot be retrieved from the item or preparer's user definition in the People window Approver

Function Security

Workflow

Requester-Initiated Changes to Purchase Orders

Requester-initiated changes to purchase orders can often be time-consuming and labor-intensive. Oracle iProcurement supports a streamlined and self-service process for making changes. Requesters can request line cancellations, changes to the order quantity or amount, need-by date, and, under some conditions, price. This capability complements the requisition change feature. When submitted and approved, the purchasing business unit retains appropriate controls and can accept or reject proposed changes. As expected, material changes to the purchase order result in both a new revision and an immediate supplier notification.

This feature provides the Oracle iProcurement requester the ability to request attribute changes and line cancellations to purchase orders that have been created from the requisition. The following attributes on the purchase order lines are available for changes:

Oracle iProcurement allows administrators to define when a requester change request should be forwarded to the requester's approval hierarchy, or the buyer for approval. In some cases, it is more efficient to bypass steps of the approval process if the change request is below some predefined limit. There are tolerance settings to control when requester changes are routed to the requester's approval hierarchy.

Setup Steps

Whenever the requester initiates a purchase order change order request, the change order request gets routed through the Oracle iProcurement requester’s approval hierarchy. Since the requisition has already been through the approval hierarchy at least once before, some customers would not want the change order request to be routed through the approval process and others would.

To change the tolerance settings use the Setup: Tolerances and Routings function in Oracle Purchasing. See: Oracle Purchasing Users Guide.

Function Security

Workflow

Implementation Considerations

Requisition Cancellations

This feature provides the Oracle iProcurement requester with the capability to select and cancel individual requisition lines (in addition to the entire requisition), before they are placed on a purchase order or a sales order.

Note: After the requisition lines are placed on an order, a cancellation triggers the requester change order process. See Requester-Initiated Changes to Purchase Orders.

Setup Steps

Enabling the function security for a requester enables the requester to select and cancel individual lines (including all lines on the requisition, which would be equivalent to canceling the entire requisition).

Function Security

Implementation Considerations

Life Cycle Tracking

Requesters can view the following information when they click the Details icon for a requisition line, as the information is updated:

Setup Steps

No setup is required for displaying the procure-to-pay life cycle details, except for the shipment information. For example, if you use Oracle Payables to create the invoice and match the invoice to the purchase order that corresponds to the requisition line, then the invoice appears. If the information, such as the invoice or payment, has been created in Oracle Applications for the requisition line, then it appears.

The following steps show what needs to happen to display shipment information for a requisition line.

In the shipment details, the Shipment number, Shipment Date, Expected Receipt Date, and (optional) Freight Carrier come from the ASN that the supplier sends to Oracle Purchasing or enters in Oracle iSupplier Portal. The Track Shipment icon appears if a link is set up to the carrier. A Tracking Number appears if the carrier is set up to find the shipment by tracking number.

If ASNs are not used and carrier setup has not been performed, then the Shipment section appears with the text No data exists.

To set up a carrier (optional)

  1. Log in to Oracle Applications using the Procure-to-Pay Administrator responsibility.

  2. Navigate to Purchasing Setup > Shipment Tracking Setup.

  3. For instructions on setting up a carrier and a carrier URL, see the Oracle Transportation Execution Implementation Manual.

    The URL that you set up is accessed when the requester clicks the Track Shipment icon. If you have chosen a Tracking Number as your lookup parameter during this setup, the Tracking Number displays that shipment's information at the carrier's URL.

To populate, display, or update the shipment details (optional)

  1. A purchase order for the requisition line must be created in Oracle Purchasing.

  2. The supplier must respond to the purchase order with an ASN. The supplier can send the ASN electronically to Oracle Purchasing, which uses the Receiving Open Interface to process the ASN, or the supplier can use Oracle iSupplier Portal to enter the ASN.

    The Shipment number, Shipment Date, and Expected Receipt Date are required on the ASN. Freight Carrier is optional. Waybill/Airbill Number is optional. If provided, it appears as the Tracking Number in Oracle iProcurement. These are the only fields from the ASN that appears in the shipment details in Oracle iProcurement.

  3. To display or update the shipment details, run the Receiving Transaction Processor:

    • Log in using the Oracle Purchasing responsibility.

    • Navigate to Requests to open the Submit a New Request window.

    • Submit the Receiving Transaction Processor request.

    • Make sure the request completed successfully.

Function Security

Internal Requisitions

In a buying organization, the source of goods are from either:

Requests for externally sourced items use purchase requisitions. Requests for internally sourced items use internal requisitions. Oracle iProcurement supports the creation of internal requisitions. Unlike purchase requisitions, the process does not convert internal requisitions into purchasing documents (purchase orders or blanket releases). Instead, the process converts internal requisitions into internal sales orders. Subsequent processing of these internal sales orders occurs. Receiving of the requested items occurs in Oracle iProcurement. The following is a summary diagram of the process.

Internal Requisition Process Flow

the picture is described in the document text

For complete implementation of internal requisitions you must start in Oracle Purchasing. See the section Overview of Internal Requisitions in the Oracle Purchasing User's Guide.

Source Subinventory

In addition to Oracle iProcurement determining the source organization, the source subinventory is also a default setting. When sourcing is automatic and transparent, and the source is determined to be an internal organization, the subinventory that is reservable and that has the greatest available inventory is selected. If multiple subinventories have equal available inventory, then the first subinventory alphabetically is the default. If all subinventories have zero available inventory, then no subinventory is the default. The available inventory figure is an estimate only, the definition of which is:

[INVENTORY ON HAND - RESERVED INVENTORY IN SUBINVENTORY]

Note: If inventory is reserved without an indication of subinventory, then that reservation is not included in the available inventory calculation.

When requesters manually select the source information, all available subinventories that are enabled for quantity tracking appear. The available inventory for each subinventory appears with the subinventory value in the list. The inventory is only an estimate and may not be valid at the time of order fulfillment.

Checkout and Validation (Mixed Lines)

It is possible to include both internally sourced and supplier sourced lines on a single requisition. Because of additional constraints for internally sourced lines, during checkout extra validation is performed on the internally sourced lines.

The following table shows a comparison of the checkout validation between supplier-sourced lines and internally sourced lines.

Item Checkout Validation
Field or Attribute Supplier-Sourced Line Internally Sourced Line
Deliver-to Location Item must belong to the organization associated with the deliver-to location

  • Item must belong to the organization associated with the deliver-to location.

  • The location must be associated with a customer.

  • There is a valid shipping network between the source inventory organization and the destination inventory organization (deliver-to organization).
One-Time Address None Cannot deliver internally sourced items to a one-time address.
Requester None New requester cannot result in a new deliver-to location that infringes on the preceding deliver-to location rules.
Buyer None Buyer cannot be entered.
Charge Account Non-modifiable if destination is inventory.

  1. Non-modifiable if destination is inventory.

  2. If destination is expense, cannot allocate to multiple charge accounts.

It is possible to create internal requisitions for both expense and inventory destinations.

At the end of the checkout process a single requisition, containing both internal and external lines is created. This requisition is then routed through the same approval path as a requisition with all purchase requisition lines. Upon approval, the internally sourced lines are converted into internal sales orders and the externally sourced lines are converted into purchasing documents (purchase orders or blanket releases).

It is possible to receive internal orders in Oracle iProcurement. For more information, see Receipt Creation.

Setup Steps - Profile Options

Workflow

Implementation Considerations

Internal Requisition Changes

You can use Internal Requisitions/Internal Sales Orders to transfer material between warehouses / inventory organizations of the same company. The internal requisition from Oracle iProcurement generates an internal sales order in Oracle Order Management, which fulfills the transfer-shipping request.

In the Requestor Change Order window, we can specify the auto-approval tolerances for internal requisitions. Using a Purchasing responsibility, navigate to Setup > Tolerances and Routings > Requestor Change Order to change the tolerances for Need-by Date and Quantity.

the picture is described in the document text

The following sections describe the ways in which changes to the Internal Requisition are synchronized with the Internal Sales Order and vice versa.

Urgent Flag and Shipment Priority Code

The Urgent flag on the Internal Requisition line determines whether the internal requisition line is urgent. Oracle Order Management tracks shipment priority differently. Shipment priority is an extensible quick code (lookup). The Urgent flag on the internal requisition line maps to the Shipment Priority field on the internal sales order line via the profile option POR: Urgent Flag maps to Shipping Priority. The values for this profile option come from the Shipment Priority Code lookup. The seeded values of the lookup are High and Standard. If the urgent flag is checked then the Create Internal Orders concurrent program takes the value of the profile option and populates the shipping priority field in the Order Management interface tables. If the profile option value is not set, then the shipping priority for the order line remains null.

Need-by Date and Request Date

You can update the Need-By Date on the Internal Requisition to a future date only and the change will get reflected in the Request Date of the Internal Sales Order. However, the changes made in the Internal Requisition need to be approved before the change is reflected in the Internal Sales Order. Before you make the changes, the Order Management processing constraints validate the changes. The order line goes on hold until the changes are approved. Upon approval, the hold gets released and changes are reflected in Internal Sales Order.

A seeded processing constraint in Order Management prevents the update of Request Date on an Internal Sales Order line. This processing constraint has been made a non-system constraint so that you can enable or disable this processing constraint as per your business requirement. If you change the Need-By Date in the Internal Requisition, and if this processing constraint has been disabled, the Request Date will update to the value of the Need-By Date.

If you change the Request Date on the Internal Sales Order, you can only update it as the Scheduled Ship Date/ Arrival Date. The profile option POR: Sync up Need by date on IR with OM ensures that the value of the Scheduled Ship Date and Scheduled Arrival Date on the Internal Sales Order line is reflected in the Need-By Date on the Internal Requisition line. If the value of the profile option is set to Yes, then the value of the Need-By Date on the Internal Requisition line is updated with the changed value of the Scheduled Ship Date / Scheduled Arrival Date. If the profile option is set to No, then the changed value of the Scheduled Ship Date / Scheduled Arrival Date will not be updated in the Need-By Date of the Internal Requisition.

Changing the Quantity on the Internal Requisition Line

If you change the quantity on the Internal Requisition line, you need to get the Internal Requisition re-approved. Also, the sales order line is put on hold during the re-approval process. The Internal Sales Order line should not be Pick Released, Invoice Interfaced, or Closed. A seeded processing constraint in Order Management prevents update of Ordered Quantity on an Internal Sales Order line. This processing constraint has been made a non-system constraint so that you can enable or disable this processing constraint as per your business requirement.

Cancellation

If you choose to cancel the Internal Requisition, the Internal Sales Order gets cancelled provided the Order Management processing constraints allow the cancellation. Similarly if the Internal Sales Order gets cancelled, the Internal Requisition gets cancelled as well.

Making Internal Requisition changes in iProcurement

If you have created an Internal Requisition and a corresponding Internal Sales Order, you can go to the iProcurement home page to make changes to the Internal Requisition. You can also initiate changes via the Requisitions Summary form in Oracle Purchasing using the Tools > Change menu option.

the picture is described in the document text

The Requistions page has a change link at the bottom of the page. If you click the To Change Internal Requisition Lines, Click Here link, the Change Order page is displayed.

The Requisitions > Requisitions tab displays the Change Order page. On this page, you can change the Need-By Date, Quantity or Cancel the line. For any changes you make, you must provide a Reason in the Reason text box on the same row.

the picture is described in the document text

After you have changed the Need-By Date, Quantity or cancelled the requisition line, click Next to view the Approvals.

the picture is described in the document text

In this example, no approvals are required; otherwise the approval details would be displayed on this page. Click Next to review the changed information on the requisition line. Approval logic is determined by Requester Change Order Approval workflow.

The changes are indicated by a green icon next to the changed value. Click Submit to confirm your changes, the following page displays on successful submission:

the picture is described in the document text

You can now view the status of the change request from the Requisition Status page. The changed quantity is also reflected in the Internal Sales Order. For more information on Internal Sales Orders, please refer to the Oracle Order Management Implementation Manual.

Oracle Services Procurement

Oracle Services Procurement is a separately licensed and implemented product. Oracle Purchasing includes the following line types that Oracle iProcurement uses:

When you license and implement Oracle Services Procurement, Oracle iProcurement supports the following additional line types:

Determination of line types is based on their Purchase Basis and Value Basis in the Line Types window in Oracle Purchasing. The following table shows the default line types, their respective purchase and value bases, and whether or not Oracle Services Procurement is required.

Purchase and Value Bases of Provided Line Types
Line Type Purchase Basis Value Basis Oracle Services Procurement Required?
Goods Goods Quantity No
Services (Amount-Based) Services Amount No
Fixed Price Services Services Fixed Price Yes
Rate-Based Temp Labor Temp Labor Rate Yes
Fixed Price Temp Labor Temp Labor Fixed Price Yes

Create Requests

Oracle iProcurement can requisition fixed price services by using a non-catalog request. Oracle iProcurement requisitions temporary labor by using a contractor request.

Note: Oracle iProcurement is the only application in which you can create a temporary labor request.

Requesters can use a non-catalog request to create requisitions for fixed price services line types. The Item Type field is used to select Goods or services billed by amount, which uses the line type selected in the POR: Amount Based Services Line Type profile option. (The Services billed by quantity item type corresponds to the line type selected in the POR: Rate Based Services Line Type profile option.)

The Create Contractor Request page is used to create requisitions for rate-based or fixed price temporary labor line types. Some of the fields you enter on a contractor request include a job and start date, and contact information.

The second step of contractor request creation is to provide supplier information. If an approved supplier list (ASL) has been set up in Oracle Purchasing, then the ASL suppliers also appear in a preferred supplier list, from which the requester can select a supplier.

Note: Oracle iProcurement prevents combining goods and temporary labor on the same requisition. If the requester tries to create a contractor request while goods are in the shopping cart, Oracle iProcurement advises the requester to keep these on separate requisitions.

Contractor Request Flow

Contractor requests use either of the following flows:

Note: For more information about the contractor requisitioning flow, contractor status, and contractor request fields, see the online Help in Oracle iProcurement.

The following figure shows the fast-track and full-track contractor status flows previously described. (If contractor assignment is not required, then it is a fast-track flow. If contractor assignment is required, then it is a full-track flow.)

The following diagram also shows the following integration points with Oracle Purchasing: during creation and checkout, Oracle iProcurement verifies whether approved supplier list (ASL) entries have been defined for the job or category. For more information, see Oracle iProcurement Setup. When the requisition is finished, Oracle Purchasing creates the purchase order.

Overview of Contractor Request Flow

the picture is described in the document text

The main points of receiving against Oracle Services Procurement items include:

Requesters can also enter contractor performance evaluations online in Oracle iProcurement. They can also view previously entered evaluations to help them select contractors. As shown in the preceding Contractor Assignment figure, the Contractors tab enables contractor assignment and performance evaluations.

Expense Lines

If the requester enters an amount for the contractor's expenses (such as air travel) on the contractor request, then Oracle iProcurement handles this amount as a separate line on the requisition. The following table shows the expense line numbering.

Line Number Description
1 Database administrator
1.1 Database administrator - expense
2 Executive assistant
3 Project manager
3.1 Project manager - expense

Notifications

Oracle iProcurement sends the following notifications in the contractor request flow, in addition to those sent in the standard requisition flow:

Setup Steps

Prerequisites

Note: For more information about Oracle Services Procurement, including supported features and product dependencies, see About Oracle Services Procurement in Oracle Supply Management, available on My Oracle Support forum.

Oracle Purchasing Setup (Required)

Before you can implement the services and temporary labor functionality in Oracle iProcurement, you must perform some setup in Oracle Purchasing. For more information, see the Oracle Services Procurement setup information in the Oracle Purchasing User's Guide.

Oracle iProcurement Setup (Required)

  1. Set the following profile options:

    • POR: Contractor Expense Line Type.

    • POR: Reapproval after Contractor Assignment

    • POR: Amount Based Services Line Types.

    You might have already set the following profile options when you performed the Oracle Purchasing setup:

    • PO: Enable Services Procurement

    • PO: UOM Class for Temp Labor Services

    For more information, see Set Profile Options.

  2. Assign the Contractor Request catalog to stores. (Optional)

    Requesters can always click Contractor Request on the Shop tab to create a contractor request. You can make contractor requests also accessible in one or more stores. For example, you can assign the Contractor Request catalog to a store that you created. When a requester clicks the store on the Shop page, all of the catalogs in that store appear. The requester can then click the Contractor Request catalog in the store and be taken to the contractor request entry page. (If you create a store that contains only the Contractor Request catalog, then clicking the store takes the requester directly to the contractor request entry page.)

    Log in using the iProcurement Catalog Administration responsibility and access the eContent Manager. For more information about adding catalogs to stores, see the online Help.

  3. Create non-catalog request templates for services. (Optional)

    You can create non-catalog request templates specifically for services. When requesters create a non-catalog request, they can select the desired template. You can also assign a non-catalog request template to a services-related store, so that the requester always selects the correct template when in that store. For example, for each service type, you can define default values for certain service attributes and optionally restrict the requester from overriding defaults.

    Log in using the iProcurement Catalog Administration responsibility and access the eContent Manager. For more information about creating non-catalog request templates, see the online Help.

  4. Define approved supplier list (ASL) entries. (Optional)

    If you have defined ASL entries for the job category selected on the contractor request, then the contractor request displays them as preferred suppliers. The requester can then choose one or more preferred suppliers. If global blanket agreements are associated with the ASL entries, then the pricing information from those documents also appears. If contract purchase agreements are associated with the ASL entries, then the contract number appears. See the previous figure, Contractor Request Preferred Suppliers.

    For instructions on setting up the ASL, see the Oracle Purchasing User's Guide.

  5. Set up supplier e-mail address for temporary labor suppliers. (Required)

    Provide an e-mail address for the Oracle iSupplier Portal user defined in the Users window for the supplier, supplier site, or supplier contact. For more information, see the supplier registration information in the Oracle iSupplier Portal Implementation Guide.

Source Document Setup (Optional)

Temporary labor (contractor) requests in Oracle iProcurement use global blanket agreements or contract purchase agreements (global or local) for source documents. Temporary labor jobs on requisition lines can source these documents that same as any other line.

  1. For instructions on setting up agreements as source documents, see Chapter 3 and the Oracle Purchasing User's Guide.

  2. You can include price differentials on your global blanket agreement, at the shipment or line level. Price (or rate) differentials are overtime or holiday rates.

  3. In the PO Create Documents workflow, set the following attributes to Yes, if you are using contracts as source documents:

    • Should Contract be used to autocreate doc?

    • Should temp labor request be autosourced from contracts? (By default, this attribute is set to Yes.)

    Note: You cannot use advanced pricing for fixed price services or temporary labor line types..

  4. To prevent the requester from changing the rate or amount on the contractor request, deselect the Price Override option on the global blanket agreement line, if you are using global blanket agreements as source documents.

Profile Options

Function Security

Workflow

Implementation Considerations