Centralized Procurement

Considering your example, you Invoice Customer/Requesting Org in US for Receivables and the Supplier/Shipping Org in AU for Payables. Once you have received the goods:

1) Run 'Create Intercompany AR Invoice' for the Shipping operating unit (AU)
2) Run ' AutoInovice Master' program for the internal order with Invoice Source as "Intercompany" in AU Receivables. This generates the
accounts receivable invoice for the Shipping Operating Unit.
3) Run "Create Intercompany AP Invoice" for the Requesting (US) Operating Unit in the receiving Inventory. This creates the Payable Invoice.
4) Run the Expense Import program with source "Intercompany" in the Requesting (US) Operating Unit.

Centralized Purchasing for Multiple Receiving Organizations

Purchasing provides complete centralized procurement support. You can leverage your purchasing power by consolidating the requirements from different plants, warehouses, and office sites; yet retain receiving support. You can define separate, autonomous receiving organizations for each of these sites.

Use the Change Organization window (See: Changing Your Organization) to choose your receiving organization. With the Receipts window, you can receive goods only for your current organization. The current organization code is displayed in the title bar of the Receipts window. (See: Entering Receipt Lines) For supplier shipments, you specify the receiving organization on the purchase order shipment. For intransit inventory shipments, you specify the receiving organization when you create the intransit shipment. For internal requisitions, you use the destination organization to specify the receiving organization.

All other receiving windows can access receiving only in your current organization. You also must deliver to the same organization in which you received the goods.

Use the Maintain Shipments window to update intransit information to provide accurate expected delivery date information to better plan your production processes. See: Maintaining Shipments.

Global Blanket Purchase Agreement in Oracle

How to create a Global Purchase Agreement that can then be accessed by other Organizations/ Operating Units also?

From Procurement Family Pack 'I', while creating a Blanket Agreement, Global checkbox at the header level can be checked to make the agreement global. This checkbox cannot be deselected once you have saved the document. The BPA can be enabled only for those organizations for which the supplier and the supplier site are defined to be the same as that of the global agreement. Note that you cannot enter an outside processing item in a global agreement, regardless of the item’s defining organization.

Navigation Steps:
==============
The Checkbox for making the Agreement Global comes at the header level for all the Blanket agreements. This has to be checked before we proceed onto the line level details, as one is not allowed to come back and update this checkbox at a later point in time once the line level details have been provided.

To enable the agreement for other organizations:
1. Create the Global agreement
2. Save the agreement
3. Go to Tools ----> Enable Organizations
4. Check the checkbox for all the organizations for which you want this Global Agreement Enabled. The Purchasing responsibility you are in will come as a default organization and cannot be deselected, but the other organizations for which the supplier and supplier site are defined will be allowed to be selected and deselected optionally, by the buyer.
5. Save again
6. Follow the Approval Process for getting this Global agreement approved.

Once this done and the BPA is approved, you can issue a standard purchase order against this global purchase agreement to place the actual order.



How to create a standard Purchase order referencing a Global Purchase Agreement and what is the relevance of the GLOBAL checkbox that we see at the PO Line Level?


You can only create a Standard Purchase Orders against a Global Purchase Agreement and not normal Blanket Releases. To have a Standard Purchase Order that references to the Global Purchase Agreement, it has to be done in the lines section of the Standard PO documents tab :

Navigation Details :
==============
1. Create a Global Purchase Agreement - BPA with the Global check box checked and enabled for other organizations. 
2. Purchasing: Purchase Orders 
3. Fill the headers section for a Standard PO with the same Supplier and Supplier Site as the global agreement
4. Go to the lines block. Enter the item details and click on the 'Catalog' button
5. In the 'Supplier Item Catalog' window, press find. You will find many source documents in the screen. Choose the Global Purchase Agreement (BPA) which you had created earlier
6. Now when you go to the reference documents tab you would find the Global check box checked and also the global source document details therein.

This standard PO line will now be sourced against the Global agreement that is referenced at the line level. 

Another option is to reference the global agreement in the Requisition itself and then autocreate it into a Standard Purchase Order.


How to find Global Blanket Purchase Agreements (BPAs) Source Documents from their Releases - Standard Purchase Orders (SPO:s) or Vice Versa?

Source Document: Global BPA: 5453
Resulting Document ( Releases): SPO 5458 AutoCreated from Purchase Requisition (PR): 13988

1. To find Global BPAs from their SPOs

PO Form

PO responsibility -> Purchase Orders -> Purchase Order Summary ->
Number = 5458 -> Find -> Reference Document section:
Type = Blanket Purchase Agreement, Document = 5453

Also,

Req form

PO responsibility -> Requisitions -> Requisition Summary ->
Requisition Number = 13988 -> Find -> Source Details section:
Document Type=Blanket Purchase Agreement, Document = 5453

2. To find the SPOs from Global BPAs.

PO Form

PO responsibility -> Purchase Orders -> Purchase Order Summary ->
Number = 5453 -> Find -> Reference Document section:
The Fields are protected ( greyed out).
It is a standard functionality. It is for the parent document as shown in step above.

PO Summary Form

PO responsibility -> Purchase Orders -> Purchase Order Summary -> Related Document tab -> Source Document section:
Type = Global Agreement, Number = 5453, Line = 1 or leave null
( All these 3 fields -- enter or choose from LOV)
Find button -> PO 5458 returns

Blanket and Planned PO Status Report

Output of this report shows the Global BPAs and their St PO under a €˜PO/Release €™ column.

PO responsibility -> Reports -> Run: €˜Blanket and Planned PO Status Report€™
With appropriate parameters:
 ( PO #s From: 5433, To:5478  Enter or choose PO#s in the ranges or 5453)


                      Blanket and Planned PO Status Report

PO Number: 5453                                                                                    Amount Agreed: 10,000.00
  Type: Blanket Purchase Agreement (Global)                                               Amount Limit: 10,000.00
                                                                                                            Amount Remaining: 9,980.00
                                                                                                              Amount Released: 20.00
          PO/Release
            5458

( Comment: This report also shows non-Global BPAs.)

How to Purge Sale Order Records in Order Management

Details

Purging old data creates space in your database and can improve performance of transactions and maintenance. Please check with your planner in regards to how much sales order history is needed for forecasting within your Company, before setting this up.

The Purge Orders concurrent program enables you to purge selected closed orders and their workflow history. You first determine which orders you wish to purge by creating a Purge Set. Once orders have been selected for purging within a purge set, you can then choose to purge the entire set, a subset of the Purge set, or to cancel the purge. Details for how to set this up are outlined below.

Purge Restrictions

Orders can only be purged if they meet the following conditions:

• Orders must be closed.
• No open demand exist for orders, open work orders, open invoices, open returns, and open requisitions.

Order Tables Purged by Order Purge Concurrent Program
The following Order Management tables are purged of selected order data,
dependent upon the input parameters and a successful submission of the Order
Purge concurrent program.

1. OE_HOLD_RELEASES
2. OE_HOLD_SOURCES
3. OE_LINE_SETS
4. OE_LOT_SERIAL_NUMBERS
5. OE_ORDER_HEADERS_ALL
6. OE_ORDER_HOLDS
7. OE_ORDER_LINES_ALL
8. OE_PRICE_ADJ_ATTRIBS
9. OE_PRICE_ADJ_ASSOCS
10. OE_PRICE_ADJUSTMENTS
11. OE_SETS
12. OE_SALES_CREDITS
13. Additionally, Oracle Foundations (FND) tables will be purged of any attachments for orders selected for purging by the Order Purge concurrent program.

Purge Set Creation

A purge set is a set which will contain orders to be purged based upon user specified criteria. Purge set can be created in the two following ways: 

• Purge Set Creation using the Create Purge Set Concurrent Program
• Multi-selection of orders within the Order Organizer window and then invoking the Create Purge Set Concurrent Program from the Tools Menu. Purge Set Creation using the Create Purge Set Concurrent Program

To create a purge set by specifying the where (selection) condition:

1. Navigate to the Order Purge Selection concurrent Program

OM > Orders, Returns > Purge > Order Purge Selection

2. Within the Purge Set name field, enter a unique name to identify the purge set.

3. Within the Purge Set Description, enter a description for your purge set.

4. Optionally, determine if you wish to purge a single order number or range of order numbers, by entering values for Order Number Low, Order Number High, or both input parameters. All orders created within the range entered will be selected for purging, provided other input parameters also enable purging.

5. Optionally, determine if you wish to purge orders for a specific Order Type by selecting a value in the Order Type input parameter. All orders created that utilize the Order Type selected will be purged, provided other input parameters also enable purging.

6. Optionally, determine if you wish to purge orders for a specific Order category by selecting a value in the Order Category input parameter. All orders created that utilize the Order Category selected will be purged, provided other input parameters also enable purging.

7. Optionally, determine if you wish to purge orders for a specific Customer Name by selecting a Customer Name in the Customer Name input parameter, provided other input parameters also enable purging.

8. Optionally, determine if you wish to purge orders created on a specific date or range of dates by selecting a value for the Creation Date Low, the Creation Date Order Purge / Order Purge Selection Concurrent Programs High, or both input parameters. All orders created for the date range specified are selected within the purge set, irrespective of the current order status.

9. Click Submit.

Purge Set Creation by multi-selection

Create a purge set by selecting multi-selecting orders within the Order Organizer, and then, from the menu, selecting Tools, Purge, Purge Set.

1. Enter the Purge Set name and a description for the purge set.

2. Click Submit to create a purge set with all the records (orders) you have selected within the Order Organizer.

To Submit the purge Request

Navigate to the Order Purge window

OM > Orders, Returns > Purge > Purge Set

Query by Purge Set name.

Purge sets can be submitted for purge, exclude certain orders within the set from being purged, or

completely deleted (provided the records have been previously purged).

To View Process Exceptions

If the selection criteria includes orders that do not meet the purge restrictions (order is not closed, outstanding reservations exist, etc.) or if the purge process encounters an issue, a process error occurs. These errors can be viewed by viewing the purge set within the Order Purge window. Navigate to the Order Purge window is:

OM > Orders, Returns > Purge > Purge Set

For example, suppose when submitting the Order Purge Selection concurrent program a user specified all orders for customer Business World. When you navigate to the Order Purge window, you may find certain orders were ineligible for purge, and have been marked as such (within error column, a note would display the order is not closed, and the Purge Eligible check box is not enabled).

Cross-validation Rule in Oracle

Defining Cross-validation Rule

Use this block to define the cross-validation rule elements that make up your cross-validation rule. You define a cross-validation rule element by specifying a value range that includes both a low and high value for each key segment. A cross-validation rule element applies to all segment values included in the value ranges you specify. You identify each cross-validation rule element as either Include or Exclude, where Include includes all values in the specified ranges, and Exclude excludes all values in the specified ranges. Every rule must have at least one Include rule element, since a rule automatically excludes all values unless you specifically include them. Exclude rule elements override Include rule elements.

Limitation of Cross Validation Rule

Your flexfield checks cross-validation rules while attempting to create a new combination of flexfield values (for example, a new Accounting Flexfield combination). Your cross-validation rules have no effect on flexfield combinations that already exist. If you want to disable an existing combination, you must disable that combination specifically using the appropriate window.

For example, you can disable an existing Accounting Flexfield combination using the Define Accounting Flexfield Combinations window.

Using Include and Exclude Ranges

Consider the following basics of cross-validation rules:

• Combinations must pass all cross-validation rules.

• Within each rule, combinations must be in at least one include range.

• Within each rule, combinations cannot be in any exclude ranges.

In summary, a key flexfield value must fall within at least one include range and outside all exclude ranges to pass your validation rule.

Include	Your user can enter any segment value combinations that fall in the following range.
Exclude	Your user cannot enter any segment value combinations that fall in the following range.

Oracle Applications provides many key flexfields, such as the Accounting Flexfield, Location Flexfield and System Items Flexfield. In this essay, we use the Accounting Flexfield to present suggestions for designing your cross-validation rules, but you can use cross-validation rules for any key flexfield structure that has cross-validation enabled.

Determine Your Error Messages

You can define your own error messages for your validation rules. Define error messages to explain errors to users. Your flexfield automatically places the cursor next to the value your user needs to change to correct the error. Define error messages based on the frequency with which key flexfields errors are made.

For example, if you use the Accounting Flexfield, an incorrect combination can result from the user entering an incorrect department or an incorrect account. Maybe you intended to enter 100-4500 instead of 000-4500. Or, maybe you intended to enter 000-3500.
If you expect that most of the time the department will be wrong, define an error message such as, "Enter departments other than 000 with revenue accounts." If you expect that either segment is just as likely to be incorrect, define an error message that does not imply a particular segment is in error.
For example, "You have entered an incompatible department/account combination. Please re-enter."

Determine Your Error Segment

Determine in which segment you want to place the cursor when a key flexfield combination fails a validation rule. Choose the segment you feel will most likely be in error. If you have defined a good error message, the message and the segment to which the cursor returns should correspond.

For example, if your account segment is most likely to be in error, define your error message to be, "Please enter only balance sheet accounts with department 000," and specify the cursor to return to the account segment.

Define Simple Rules

Avoid rules that control cross-validation across more than two segments, where possible.

For example, if you use the Accounting Flexfield, you may want to prevent using department 000 with accounts greater than 3999 for all balancing segment values except 99.

While you can define cross-validation rules that span two or more segments, keep in mind that it becomes more difficult to interpret cross-validation error messages and correct invalid key flexfield combinations as your rules encompass more segments.  

Difference between Cross Validation Rule and Security Rules

Security rule is applied at a responsibility/User level whereas Cross validation rule is applicable for the given accounting combination. Secondly, Cross Validation rules applicable on the whole combination whereas security rule works on a single segment.

Retroactive Price update of Orcle Purchasing documents

RETROACTIVE PRICING:-

  To use Retroactive Pricing feature set the following profile option to Yes.

PO: Allow Retroactive Pricing of POs

The profile can be set to the following options:
1. ALL RELEASES
2. NEVER
3. OPEN RELEASES

  To use this feature it should be set to ALL RELEASES. In 11.5.9, you only have the options as Never and Open Releases.

  The Retroactive Price Update on Purchasing Documents concurrent program (POXRPDP) is a Concurrent program run from the Purchasing responsibility which automatically updates purchase orders and blanket releases retroactively with price changes.
The parameters in this concurrent program can be the following:
1. Based on Supplier
2. Based on Blanket Agreement Number
3. Based on range of Items
4. Based on Date From ( Date starting from)

The accounting entries created are:-

For Inventory Destination type :
Debit      Retroactive Price Adjustment Account
    Credit         AP Accrual

For Expense Destination type :
Debit         Charge Account
    Credit            AP Accrual


For purchase orders with a destination type of Inventory/ Shopfloor, the adjustment account is posted to the Retroactive Price Adjustment account. This account is defined at the organization level in the Receiving Options window in Oracle Purchasing.

The following accounts and costs are not adjusted:-

1. Inventory and Work in Process valuation accounts
2. Costs are not recalculated in Average and LIFO/FIFO cost organizations.
3. Purchase price variance

For Inventory and Shop Floor destination types, Inventory and WIP valuation accounts are not adjusted. Instead, the balance is posted to Retroactive Price Adjustment Account.

Consider the following scenario:-

For an Item A
PO Created price = 10
Quantity = 10

Cost Price = 15.

Accounts hit:-

The accounts hit would be the following:-

Receiving:
Credit --  AP Accrual Account --  100
        Debit -- Receiving Account -- 100

Delivery:
Credit -- Receiving Account -- 100
       Debit -- Inventory Valuation Account -- 150
Credit -- Purchase price variance -- 50

This purchase price variance is because of the  difference in the PO price and the Item Cost.

Now the PO price is changed to 12.

The  accounts hit would be

Receiving:
Credit --  AP Accrual Account --  120
        Debit -- Receiving Account -- 120
       
Delivery:
Credit -- Receiving Account -- 100
       Debit -- Inventory Valuation Account -- 150
Credit -- Purchase price variance -- 50
Credit -- Receiving account -- 20
      Debit --  Retroactive price adjustment account --20

Technical Information:-

Important Table:-

RCV_ACCOUNTING_EVENTS
RCV_Accounting_Events stores accounting events for the Receiving Subledger.The corresponding accounting entries are stored in the RCV_Receving_Sub_Ledger table. Accounting entries may be generated when a receiving transaction is performed, when a retroactive price change is approved on a PO, and when Invoices are validated for period-end accruals in a Shared Services procurement scenario. You can only delete rows from this table using the Purge feature of Oracle Purchasing.

Forms Modified:-

RCVSTDRO.fmb à Purchasing à Setup à Organization à Receiving Options
CSTFDFCA.fmb à Cost à Periodic Costing à Setup à Periodic Cost Assignment

RELATED DOCUMENTS:-

Note 271655.1 - Price Changes Of A Contract Are Retroactive For Billed Periods

================================================================

Retroactive pricing allows buyers to adjust the price on blanket agreement lines and have the new pricing be updated on all release lines that have not been received against. Over the life of purchasing documents price changes, this functionality allows buyers to make sure that the
price on the blanket agreement is the agreed upon price.

‘The Retroactive Price Update on Purchasing Documents ‘ concurrent program automatically updates existing blanket releases and standard purchase orders retroactively with price changes from the parent blanket agreement or global purchase agreement. Other changes can
include updates to price breaks quantities, ship–to organization or location, new price breaks, and deletion of existing price breaks.

Take a note:

1. The Retroactive Price Update on Purchasing Documents concurrent program does not update the prices if purchase orders or releases have any accounting entries (receipt accruals, invoices, encumbrance) associated with them.
2. It does not process documents associated with blanket Agreement lines that are cumulatively priced.
3. It only considers price updates from lines of blanket agreements that are currently in the following statuses:
• Approved
• Closed
4. It updates the open Blanket Releases and Standard Purchase Orders against Global Agreements

‘The Retroactive Price Update on Purchasing Documents’ program uses Buyer entered parameter values to retrieve blanket agreement lines that have undergone price changes as well as the release shipments created against these lines. It then updates shipments with any new prices from the blanket agreement and update the timestamp information on release shipments with that of the blanket agreement line.

Purchasing documents that were in an approved status prior to the update can be automatically submitted for re–approval.

Profile option PO: Allow Retroactive Pricing of POs is need to be set, generally it has to be set to ‘Open Release Only’ to update only all open releases on that Blanket and that the PO Change Order Workflow has been configured to allow automatic re–approval of the updated releases and purchase orders. 

Please execute the following steps:-

1. Navigate to SetupàPurchasingàDocument Types.
2. Find in the Document Types the Standard Purchase Order type
3. Check the Archive on field : Is Archive set to 'Communicate' or set to 'Approve'
If the Archive is set to 'Communicate' you have to communicate the PO to the Supplier before you can use the Cancel Option. You can run the 'PO Output for Communicate' or 'Printed Purchase Order Report' (select 'Print Selection'-'All' and give the PO Number you want to communicate). This will create the Archive. Now you can cancel the PO.

If the Archive is set to 'Approve' you have to make the document authorization status ' Requires Reapproval' then REAPPROVE it before you can use the Cancel Option. You can update/enter the value in the field 'Note To Supplier'. (Navigation for the field is Lines block à Click on "More" tab.) This will change the revision number and status is set to 'REQUIRES REAPPROVAL'. Now APPROVE the Purchase Order. Archival process will takes place here.

 

fnd_global.apps_initialize 11i, R12 and SQL

fnd_global.apps_initialize

In Oracle E-Business Suite, it becomes necessary to do this call when an API is called or SQL Query is run from

SQL Plus/TOAD like tools. This ‘fnd_global’ API calls sets the environment properly so that SQL Queries specific to few key base tables return rows back.

This ‘fnd_global’ API call has 3 key parameters

fnd_global.apps_initialize (user_id, responsibility_id, responsibility_application_id)

******************************************************************************

For example, in SQL Plus, this can be called as shown below:

Exec fnd_global.apps_initialize(125,400,700);

Where,

125 – user_id from fnd_user table

400 – responsibility_id from fnd_responsibility table

700 – application_id from fnd_application table

******************************************************************************

Release 12

begin

fnd_global.apps_initialiase(user_id, responsibility_id, responsibility_application_id );

mo_global.set_org_context(81,NULL,'SQLAP');

end;

 ******************************************************************************

Oracle 11i

BEGIN

fnd_global.apps_initialize(user_id, responsibility_id, responsibility_application_id);

END;

 ******************************************************************************