Global BPA doesn't support Cumulative Pricing

Cumulative Pricing can not be used with global blanket agreements It is mentioned in the PO User guide.

Encumbrance is not supported for centralized procurement

The following are the metalink notes which show that encumbrance is not supported for centralized procurement.
1.        1086669.1 (Question 25)
2.       1158423.1 (Question 7)
3.       296364.1

Auction Types

English Reverse Auction - This sales term describes an auction with one buyer and multiple sellers whereby the bidders offer decreasing prices to sell an item

Dutch Reverse Auction - This sales term describes an auction with one buyer and multiple sellers whereby the auctioneer raises the price from a low starting point until a bidder agrees to sell at that price

Japanese Reverse Auction - This sales term refers to an auction with one buyer and multiple sellers whereby the auctioneer reduces the price from a high starting point and sellers are forced to bid at each price to remain in the auction.

Sealed Bid Reverse Auction

Sealed Bid Reverse Auction with Schedules

Difference about MRP and DRP

Essentially, the MRP plan considers supply & demand in one Inventory Org.  If you have multiple Orgs it will consider the demands from and supplies to the other orgs but you would have to run the plan at least twice to get all of the interactions between Org. 

DRP plan considers all of the links in the distribution chain within one plan so only one planning run is required to get all of the interactions included in the planning run. 

Company may want to treat each plan independently or may want to plan combinations of orgs together, or some mixture of these. 

Mixing MRP & DRP plans allows this to happen.

Ref: Supply Chain Planning in the Master Scheduling MRP & Supply Chain Planning User Guide

Defaulting in the Receipt Routing

Defaulting in the Receipt Routing is based on the precedence(Low to High)
1.       Receiving Options
2.       Supplier/Site
3.       Item

Defaulting in the Invoice Matching

Defaulting in the Invoice Matching is based on the precedence(Low to High)
1.       Purchasing Options
2.       Supplier/Site
3.       Line Type
4.       Item(Validation Org)
5.       Item(Ship To Org)

Defaulting in the procure to pay

Defaulting in the procure to pay is based on the precedence(Low to High)
1.       Financial Options
2.       Purchasing Options
3.       Receiving Options
4.       Supplier
5.       Supplier Site
6.       Purchasing Documents
7.       Item

RFQ, RFI and Auction Numbering Generation

ID# 414531.1
Currently Sourcing. does not provide separate numbering scheme for difference sourcing documents.
They all share the same sequential numbering scheme.
The numbering is based on an internal sequence (oracle sequence) pon_auction_headers_all_s.
This Sequence is setup when the Sourcing product is installed.
For multi round and amended negotiation, the original auction header id is used with the round number/amendment number
to derive the auction/document number.
ID# 464875.1
Use this query to see the sequence generator used for assigning an AUCTION_HEADER_ID (and
DOCUMENT_NUMBER) to sourcing documents.
SQL> select * from dba_sequences
where sequence_name = 'PON_AUCTION_HEADERS_ALL_S';
Notice that the cache_size is set to 1000. This causes the sequence to increase by 1000 each time
a new session is used for creating auctions.

A) To reduce the increment, reduce the cache_size value in dba_sequences for sequence_name
PON_AUCTION_HEADERS_ALL_S to a number less than 1000.
OR
B) Consider the following and commit the change to the database to eliminate the cached values and
just increment the counter by 1 each time.
SQL> ALTER SEQUENCE PON.PON_AUCTION_HEADERS_ALL_S INCREMENT BY 1 NOCACHE;

PO Receiving with an iPad

All iProcurement pages are in HTML and reachable with any internet browser, including Safari which is the most often used one on iPad.
You can perform direct receipts on non serialized/non lot control purchase requisition lines.
You can also perform purchase and internal requisition in iProc with iPad.
Your customer must be aware that this is only possible if there is a 3G/Wifi connection, and a VPN to go to their intranet and connect to the applications.

Whitepaper on Upgrading Customizations from Release 11i to 12.1

Upgrading your Customizations to Oracle E-Business Suite Release 12.1 (Note 1435894.1)
---------------------------------------------------------------------------------------------
This white paper provides an overview of to manage and upgrade existing Release 11i customizations to Release 12.1. It covers identifying the various types of customizations customers might have--such as personalizations, Oracle Forms, Web ADI, and mod_plsql--and how to handle them during your upgrade.
The document discusses upgrading Oracle E-Business Suite customizations in the context of the following cycle:
    Creating an inventory of your existing customizations
    Comparing customizations to standard Release 12 functionality
    Upgrading customizations
    Reimplementing customizations
    Creating future customizations
The paper also provides recommendations on customization technologies such as Oracle Application Framework (OAF), Oracle Application Express (APEX), and Oracle Application Development Framework (ADF).

Query for checking whether patch is applied or not

select * from jai_applied_patches where patch_number = 7530017
select * from ad_applied_patches where patch_name =

RICE

Reports, Interfaces, Conversions and Extensions (Enhancements)

CEMLI

Configurations/Customization, Extension, Modification, Internationalization and localization,
and Integration.

ALORE

A: ASSET
L: LIABILITY
O: OWNER'S EQUITY
R: REVENUE
E: EXPENSE

Receipt form do not support Receipt / delivery of ASN's with lot/serial information

Purchasing forms do not support Receipt/Direct delivery of ASN's with lot/serial information using the Enter Receipts form. An ASN entered via Receiving Open Interface or iSupplier Portal with lot/serial information can only be received and delivered via Receiving Open Interface.
Purchasing forms do not support delivery if there is some receiving supply with corresponding lot/serial entries. This is only supported through the Receiving Open Interface. Since Mobile uses the Receiving Open Interface it is possible to create a receipt with lot/serial info. When trying to deliver this using forms, it is checked whether there are any rows with lot/serial info corresponding to receiving supply. In this case these rows will exist and hence the error will occur.
The following message will be shown on Receiving Transaction form:


----------------
If a lot or serial controlled item is received using receiving open interface
or using mobile forms interfaces in WMS and MSCA , then the subsequent
transactions are supported only either through receiving open interface, or
through the mobile forms interfaces in WMS and MSCA.
------------------

Cause

This is expected functionality.

In Bug 5581629 the developer explains the process:

When an ASN is created with lot/serial info, the following tables will get populated:

1. rcv_shipment_headers (RSH)
2. rcv_shipment_lines(RSL)
3. rcv_serials_supply(RSS) ( for serials )
4. rcv_lots_supply(RLS) ( for lots )

After creation of an ASN, a custom program is required which will look into these tables and then populate the ROI tables for a particular shipment_num entered while creating an ASN.

The following ROI tables need to be populated:

1. rcv_headers_interface (RHI)
The source for this table would be data from RSH.

2. rcv_transactions_interface(RTI)
The source for this would be RSL.

3. mtl_serial_numbers_interface(MSNI)
The source for this would be RSS.

4. mtl_transaction_lots_interface(MTLI)
The source for this would be RLS.

After populating these ROI tables, the Receiving Transaction Processor (RVCTP) should be run in batch mode where the transaction will be processed.
ER
===
Bug 5581629 - Unable To View Serial Number In Receiving Form For ASN Created Via iSupplier.
status 22:Approved for future releases

Supplier Status

1.    The supplier status that is displayed as part of the ASL screen is defaulted based on the default status set in “Supplier Statuses” screen. In your case, the default value might be set as “New” and that is the reason why auto generation of ASL takes the supplier status as “New”. If the default value is set as “Approved” then auto generation of ASL will happen with supplier status as “Approved”

2.    Even if the supplier status is “New” you will be in a position to source the BPA in requisition document provided the business rule definition as part of “Supplier Statuses” screen is set accordingly. Please ensure whether the business rules related to sourcing and document approval can be allowed for supplier with status as “New” before making changes

What does Check box on Price Break Form do

Toggle Query Coordination in the Lines

This feature enables you to control how the lines are refreshed during the process of creation, update, or deletion of lines. Creating, updating, or deleting of lines can result in cascading changes. There can be two types of cascading changes that can occur. Changing a field on a line can trigger changes on other lines as well. Adding a service line to a model can result in cascading of service lines to options/classes. These are cascading across lines. Cascading can happen on the same line also. A change in one field can result in other fields being changed, this is treated as cascading on the same line. The Toggle Query Coordination check box controls whether the cascaded changes are refreshed and displayed immediately in the lines block after the save operation is performed or upon navigating to lines block.

This is like more technical and data handling.

BPA Line Level Amount Agreed Entered Does Not Add Into Header Automatically

The amount and quantity limit columns at the line level  for the BPA are for "guidelines" only. There is no validation in the code or extra functionality.

Bug 5195819

PURCHASE RELEASE DOES NOT VALIDATE BLANKET'S 'AMOUNT AGREED' LINE LIMIT

BUG:4439005 There is no validation in Line level amount agreed. Releases always take price from header level
not from line level.

What Is The Defaulting Rule For Requisition/Release Referencing BPA With Multiple Overlapping Price Breaks ?

Metalink Note id: 796606.1

Goal

What is the defaulting rule for Requisition or Release referencing BPA with multiple overlapping price breaks ?

For example:
1. Create a global agreement GBPA
2. Add a description_based item
3. Add price break line for quantity 4, for example 10
4. Submit and approve agreement.
5. Add a new price break line for the same quantity 4 at a lower price 9
6. Submit and approve agreement.
7. Add another price break line for the same quantity 4 at a higher price 12
8. Submit and approve agreement.
9. Use the GBPA to source into requisition.

In this example, there are overlapping price breaks for the same quantity 4.

Solution

By design, when there are multiple overlapping price breaks, the system compares price breaks by creation dates, then by prices, following this defaulting rule:

· Use price from the most recently created price break record.
· Use lowest price from amongst the matching price break records.

For price break records created in the same days, they will all be used to determine the lowest price.

If there is a business need outside of the above defaulting rules, customizing pricing logic using custom hooks can be used.

Reference notes for Custom Hooks:

Note 360121.1 Custom Hooks in Oracle Purchasing
Note 360122.1 How To Create Custom Pricing Hook in 11.5.9 and onwards

References

BUG:5176035 - REQS DO NOT DERIVE CORRECT ITEM PRICING FROM PRICE BREAK WITH EFF. DATES ON BPA
BUG:8363413 - REQUISITION NOT TAKING LATEST PRICE BREAK ENTERED ON THE SAME DAY
NOTE:360121.1 - Custom Pricing Hooks in Oracle Purchasing
NOTE:360122.1 - How To Create Custom Pricing Hook in 11.5.9 and Onwards

Set the site profile Concurrent: TM Transport Type to QUEUE if using the RAC system

Receiving Transaction Manager Not Active - Unable To Perform Receipt [ID 1284918.1]

Applies to:

Oracle iProcurement - Version: 12.1.3 and later   [Release: 12.1 and later ]
Information in this document applies to any platform.

Symptoms

On : 12.1.3 version, Desktop Rcv/Returns/Correction

Trying to submit receipts, corrections or returns from iProcurement but get the following error message:Receiving transaction manager not active

EXPECTED BEHAVIOR
---------------------------
Expect the Receipt to be completed and Receiving Transaction Processor has completed successfully

STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. In Iprocurement select requisition to receive
2. Enter required data and press submit
3. on screen receive Items: review and submit get foolowing error message
4. 'Receiving transaction manager for receipt, return and correct items are not active'

Cause

The issue appears to be caused by the Receiving Transaction Manger not operating correctly

Solution

To implement the solution, please execute the following steps:

  Execute the below steps

  1. Relink receiving executables.
      cd $PO_TOP/bin
      $ adrelink force=y ranlib=y "PO RCVOLTM"
      $ adrelink force=y ranlib=y "PO RVCTP"

2. Bounce the Receiving Transaction Manager.

3. Retest the issue.
If using a RAC system, set the site profile Concurrent: TM Transport Type to QUEUE, bounce the middle tier and then retest

Please review Note 458453.1
What is the Difference Between PIPE and QUEUE for Profile Concurrent:TM Transport Type ?
and
Note 823587.1
Using Oracle 11g Release 2 Real Application Clusters with Oracle E-Business Suite Release 12
for more information on this profile

Price breaks effective dates

In Oracle Purchasing, on a blanket agreement , the price breaks effective dates are available only
if not using cumulative pricing. Logged Enhancement Request 3891628

Cumulative Pricing can not be used with global agreements.

Cumulative Pricing can not be used with global agreements.
Ref: P4-56 PO User Guide