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.