oracle payables user's guide,EBS Archiving and Purging: You Know you need to详解-CSDN博客

A number of trends in the IT industry have contributed to the increasing size of ERP application databases and show no signs of abating. These include dramatic reductions over recent years in the cost of disk, such that it has often been easier to buy more disk than to embark on an archiving project. The trend towards replacing point solutions with an integrated application suite, such as Oracle Apps, results in large databases of transaction data – extrapolate it out for a few years and the subject of archiving becomes pertinent. Databases with high volumes of transactions, a defining characteristic of ERP applications, rapidly increase in size and memory requirements. This can have a detrimental impact on performance for both online and background processing, which becomes business critical when applications such as manufacturing or order management are part of the picture.

When the favorite approach of a business to an increasing volume of data is to throw more hardware at it in preference to archiving it, it increases the total cost of ownership for the application though the cost of performance tuning, additional disk, processors, controllers, support agreements and so forth.

It’s like cleaning out the garage - we all know we should, but somehow it’s difficult to get around to it. This discussion is the one-hour summary of the archiving and purging functionality available within Oracle Applications.

The discussion summarises archiving across Applications, how to submit the purge processes, criteria for records to be purged, what information does and does not get purged, the tables information is purged from and how to restore archived information. For the purpose of this discussion, any program which archives or purges information from the applications has been included, whether or not it is strictly an ‘Archive’ process.

Fixed Assets

Fixed Assets has two types of archive and purge processes:

1) Mass Additions

2) Depreciation and Adjustment Transaction records

Mass Additions

The Delete Mass Additions program archives mass additions to an archive table, where they are then able to be purged.

Criteria

The Delete Mass Additions program removes mass additions in the DELETE and POSTED queues. It also removes SPLIT parents if the split children have been posted or deleted. The program archives mass additions in the DELETE queue only to an audit trail table, FA_DELETED_MASS_ADDITIONS.

Instructions

To delete mass additions:

Responsibility: Fixed Assets Manager

(N) Mass Additions > Delete Mass Additions

To purge the audit trail for deleted mass additions:

Responsibility: Fixed Assets Administrator

(N) Purge > Mass Additions

Data Archive and Purge

Archive and purge transaction and depreciation data for the book and fiscal year you specify to release disk space for current data. If you do not need to run reports for previous fiscal years, you can copy the data onto tape or any storage device, and then delete it from your system. If you later need these records online, you can reload them into Oracle Assets.

Oracle Assets maintains an audit trail of which fiscal years you have archived, purged, and restored, and how many records were processed. If your system fails during a purge, you can safely resubmit it. Oracle Assets only processes those records which it has not yet processed.

You must purge fiscal years in chronological order. Before you purge a fiscal year, you must archive and purge all earlier fiscal years. You cannot purge periods in the current fiscal year. If your current period is the first period of a new fiscal year, you cannot purge the previous period. You can only restore the most recently purged fiscal year, so you must restore fiscal years in reverse chronological order. You cannot archive and purge the period prior to the current period.

Purge Security

You must allow purge for the depreciation book you want to purge in the Book Controls window. To prevent accidental purge, leave Allow Purge unchecked for your books, and check it only just before you perform a purge.

You submit archive, purge, and restore in the Archive and Purge window. Oracle Assets provides this window only under the standard Fixed Assets Administrator responsibility. You should limit access to this responsibility to only users who require it.

Resizing the Archive Tables

If you are archiving a large number of records for a fiscal year, you can update the FA:Archive Table Sizing Factor to specify the size of the temporary tables created by an archive. Specifically, if the number of rows Oracle Assets will archive multiplied by the average rowsize of that table for all three tables is very different from 100,000 bytes, you may want to adjust the FA: Archive Table Sizing Factor.

Criteria

The purge program removes the depreciation expense and adjustment transaction records for the book and year you specify. However, it does not remove the asset identification, financial, and assignment information for your assets, including assets you retired or that became fully reserved during that fiscal year.

Restoring Data

To restore records that you have purged from Oracle Assets, you must first import the tables from your archive, then perform the restore. You do not need to archive the records before you purge them again.

Since the archive number is part of the temporary table name, Oracle Assets restores only the records that were archived during that archive you specify.

Instructions

To archive and purge transaction and depreciation data:

Responsibility: Fixed Assets Administrator

(N) Archive and Purge Enter the Book and Fiscal Year (B) Archive Export the archive tables Requery the archive (B) Purge Drop temporary archive tables

To restore archived data:

Responsibility: Fixed Assets Administrator

Import the archive tables from your storage device (N) ??? > Archive and Purge Query the archive to be restored (B) Restore

When you perform the archive, Oracle Assets assigns a reference number to it and copies the depreciation expense and adjustment transaction records to three temporary tables:

• FA_ARCHIVE_SUMMARY_

• FA_ARCHIVE_DETAIL_

• FA_ARCHIVE_ADJUSTMENT_

You can export the temporary archive tables onto tape or any storage device. If you need these records again, you can restore them. You must archive records before you can purge them, and Oracle Assets prevents you from running purge if these tables do not exist. You should not drop the tables until after you have exported the tables and run purge.

Accounts Receivable

Depending on your business needs, you can archive records at one of three levels of detail: ’header– level’, ’header and line– level’, and ’header, line, and distribution– level’. Transactions are purged from the database based on the parameters you specify. The purge process will remove eligible transactions and all activities relating to these transactions such as adjustments, credits, reversals, calls, sales credits, and receipts.

Criteria

Transactions and all activities relating to the transactions such as adjustments, credits, reversals, calls, sales credits, and receipts must meet the following criteria:

All transactions must be posted to GL. Receivables considers a transaction to be posted if every record relating to the transaction has a GL Posted date (this does not apply to transactions not eligible for posting if the Postable Only parameter is set to No). Standard Archive and Purge program: Transactions applied to commitments are not eligible for purge until the commitment is closed. A commitment is considered closed when the commitment balance (or if it is a deposit the deposit balance) is zero. Call New Archive and Purge: Transactions applied to commitments are not eligible for purge. If the GL Date Type parameter is:

Invoice GL date – all invoice GL dates must be prior to the end date of the period specified.

Receipts GL date – all receipt GL dates must be prior to the end date of the period specified.

All GL dates – the GL dates of all selected transactions must be prior to the end date of the period specified.

Note: The GL Date Type parameter does not apply if you choose to include transactions not eligible for posting. In this case the transaction date will be used for date checking. This parameter applies only to the standard Archive and Purge program.

All transactions must be closed (for example, the payment schedules have no amount due). This does not apply if you choose to include transactions not open to receivables. These transactions do not have a payment schedule and therefore are not checked. If the transaction is a receipt, it must be related to transactions eligible for purge, unless it is a reversed unapplied receipt in which case it may not be related to any transaction. If the transaction is a receipt, it must be fully applied or unapplied and reversed. For example, the status of the latest AR_CASH_RECEIPT_HISTORY record must be ’Cleared’, ’Risk_Eliminated’, or ’Reversed’, or for Debit Memo reversals the reversal date must be not null. All transactions must meet the purge parameters you specify. Miscellaneous Transactions will not be Purged unless you run Archive/Purge for all customers, because they are not related to specific customers. The following are general rules transactions must meet to be considered closed:

Invoice - Invoice balance is reduced to zero by application of one or more of the following: Cash Receipts, Credit Memos, Approved Adjustments, or Deposits.

Debit Memo - Debit Memo balance is reduced to zero by application of one or more of the following: Cash Receipts, Credit Memos, or Approved Adjustments.

Credit Memo- Credit Memo balance is fully applied to one or more of the following: Invoices, Debit Memos, Chargebacks, or Cash Receipts.

Chargeback - Chargeback is fully applied to either a Cash Receipt, Credit Memo, or an Approved Adjustment.

Deposit - Deposit balance and commitment balance is fully applied to one or more invoices.

Commitment - Commitment balance is fully covered by one or more invoices.

Cash Receipt- Receipt balance is fully applied to one or more of the following: Invoice, Debit Memo, Credit Memo, Chargeback, Deposit. If the receipt was not applied but has been reversed, it is also eligible for purge. Adjustment - Approved and Applied to an Invoice, Debit Memo, or Credit Memo.

Attention: The Call New Archive and Purge program does not purge deposits, guarantees, miscellaneous receipts or any items linked to these transactions.

Cash Management

Cash Management has two areas which can be archive and/or purged:

1) Bank Statement Interface Tables

2) Bank Statements

After you import a bank statement into Cash Management, you can purge its information from the bank statement open interface tables. You can also archive the information before you purge it. Purge and archive can also be run against the bank statement tables.

Bank Statement Interface Tables

Two Cash Management system parameters are used to automatically archive and / or purge the interface tables after AutoReconciliation has run.

Purge: If you check this check box, the AutoReconciliation program will automatically purge all information from the bank statement open interface tables once the information has been successfully transferred to the bank statement tables.

Archive: If you check this check box, the AutoReconciliation program will automatically archive all information from the bank statement interface tables once the information has been successfully transferred to the bank statement tables.

You cannot archive transactions without also purging them. However, you can purge transactions without archiving. Also note, the purge and archive check boxes on the System Parameters window affect only the bank statement interface tables.

Bank Statement Purge

Unlike the Interface Tables, to purge or archive/purge bank statement tables, you must run the Archive/Purge program.

The purge process deletes all header and statement line information from either the open interface tables or the bank statement tables. When you purge a bank statement, you must also purge the relevant transaction data. You can purge bank statement information without archiving it first.

Warning: If you use Cash Management to reconcile journal entries in General Ledger, you should run the Cash Management Purge program before you purge journals in General Ledger.

With archiving, you can save copies of your bank statement information.

You cannot archive without also purging. When you archive, Cash Management copies all header and statement line information from either the open interface tables or the bank statement tables into special archive tables the system maintains. To save your archived information to a file you must use the ORACLE RDBMS Export utility. To restore information from a saved archive file, you must first use the ORACLE RDBMS Import utility to populate the special archive tables. Then, you must run a custom SQL*Loader script to transfer the information from the archive tables to the bank statement or open interface tables.

General Ledger

General Ledger has four areas which can be archive and/or purged:

Consolidation Audit Data

Move/Merge Tables

Journal Entries

Account Balances

Consolidation Audit Data

When you run a consolidation in audit mode, General Ledger maintains an audit trail for the Consolidation Audit Report, the Unmapped Subsidiary Accounts Report, and the Disabled Parent Accounts Report. After you run these reports, you can purge supporting source data from the GL_CONSOLIDATION_AUDIT table.

Once you purge your consolidation audit data, you can no longer run the consolidation audit reports. However, you can still review your consolidation journal batch in your parent set of books.

Prerequisites

Run a consolidation in audit mode

Ensure the consolidation completed successfully.

Run all necessary audit reports.

Instructions

To purge consolidation audit data:

(N) Navigate to the Purge Consolidation Audit Data window. Select a Consolidation Name and Period to purge. You can purge any consolidation run in audit mode. (B) Purge

Purging Move/Merge Tables

A move/merge operation populates two interim tables, GL_MOVEMERGE_BAL_ and GL_MOVEMERGE_DAILY_BAL_, with the balances being moved or merged. The information in these tables is retained after a successful move/merge because it is needed to reverse the move/merge.

When you are satisfied that the results of a move/merge are correct and that you want to retain the new balances, you should purge the tables. Do not purge the tables if you think you may want to reverse the move/merge later.

If you reverse a move/merge operation, the interim tables will be purged automatically.

Instructions

To purge the interim move/merge tables:

(N) Navigate to the Mass Maintenance Workbench window. Query the move/merge request whose interim tables you want to purge. (B) Purge.

Archiving Account Balances and Journal Detail

You can archive and purge account balances, as well as journal batches, entries, lines, and associated journal references for one or more accounting periods, provided the periods are permanently closed.

You can archive and purge actual, budget, or encumbrance balances. In addition, for translated actual and budget balances, you can purge them before you rerun your translation. Except for translated balances, you must archive balances or journals before you can purge them.

Note: If you have average balance processing enabled in your set of books, your average balances will be archived and/or purged automatically, at the same time that you archive and purge your standard balances.

Attention: When you rerun the Archive program, you overwrite the data in the archive tables. Therefore if you have previously run the archive process, be sure to export your archived data to an operating system file and to save the file to tape.

Prerequisites

Permanently close all periods that you want to archive or purge. You do not have to permanently close periods to purge only translated balances.

Run all of your standard accounting reports to maintain a printed record of the transactions you will archive and purge.

Create the appropriate tablespace and set your storage parameters to hold your archived data.

Ensure that you have exported any previously archived data to an operating system file and saved the file to tape.

After archiving account balances and journal detail, purge the data.

Except for translated balances, you can only purge data for accounting periods that have been archived. Translated balances cannot be archived; they can only be purged.

Choose Archive/Purge. General Ledger submits a concurrent request to delete the archived records from the GL_JE_BATCHES, GL_JE_HEADERS, GL_JE_LINES, and GL_IMPORT_REFERENCES tables.

Review the Archive and Purge Audit Report to ensure that the Purge process completed successfully. Compare the number of records purged to the number of records archived for each period.

Export, drop and reimport the new GL_JE_BATCHES, GL_JE_HEADERS, GL_JE_LINES, and GL_IMPORT_REFERENCES tables to shrink the size of these tables and reclaim disk space. You will also notice increased performance by reducing fragmentation.

Export the purged GL_JE_BATCHES, GL_JE_HEADERS, GL_JE_LINES, and GL_IMPORT_REFERENCES tables and verify the export.

Accounts Payable

Oracle Payables has four areas which can be archive and/or purged:

Invoices

Purchase Orders

Requisitions

Suppliers

You can delete Oracle Payables, Oracle Purchasing and Oracle Supplier Scheduling. You can purge invoices, purchase orders, suppliers and related records such as invoice payments, supplier schedules, and purchase receipts.

After a record is purged, it is no longer queryable and the record will no longer appear on standard reports. However, the system maintains summary information of deleted records to prevent you from entering duplicate invoices or purchase orders.

Criteria

Invoice Purge Criteria

If you are purging invoices, the Purge program purges related invoice distributions, invoice approvals, and invoice batches. You can purge invoices that meet the following criteria:

Last Update Dates of the invoice and its distributions, and the Invoice Date, are on or before the Last Activity Date

Invoice is fully paid or is a zero–amount invoice

Invoice is fully posted

Invoice does not have any 1099 distributions, and is not for a 1099 supplier

Invoice was not generated by a recurring invoice template

Invoice is not a prepayment, and no prepayments have been applied to the invoice

All of the invoice’s payments meet the Payment Purge Criteria

No open encumbrances are associated with the invoice

All purchase orders referencing the invoice meet the Purchase Order Purge Criteria (this condition applies only when you choose Matched Invoices and POs for the purge category)

If Oracle Assets is installed, all of the invoice’s distributions were tested by Mass Additions

Invoice is not Oracle Projects related

Payment Purge Criteria

If you are purging payments, the Purge program deletes related invoice scheduled payments. You can purge payments that meet the following criteria:

Unvoid payments have a Cleared Date that is on or before the Last Activity Date

Payment is posted

All of the invoices paid by the payment meet the Invoice Purge Criteria

Payments are not reconciled and referenced by Oracle Cash Management. If you do use Oracle Cash Management, then you have already purged related records in Cash Management.

Supplier Purge Criteria

You can purge suppliers that meet the following criteria:

Supplier is not an employee

Supplier is inactive, and the value in the Inactive On field for the supplier on or before the Last Activity Date you specify

Supplier is not a parent company or subsidiary of another supplier

Supplier is not referred to by records in Oracle Payables, Oracle Purchasing, or Oracle Assets tables

All invoices and payments for the supplier meet the Invoice and Payment Purge Criteria

If Oracle e–Commerce Gateway is installed, the Last Update Date of any e–Commerce Gateway control table row associated with the supplier must be on or before the Last Activity Date. Also, no EDI transactions can exist in any e–Commerce Gateway interface table for any of the supplier’s sites.

Supplier is not present on any active sourcing rule

Supplier is not referenced on any planning or shipping schedule

The RCV Open Interface tables can contain no rows referencing the supplier (intransit shipments through ASNs or barcoded receipts awaiting processing)

Requisition Purge Criteria

You can purge requisitions that meet the following criteria:

Requisition is cancelled

Requisition has no lines, all lines are cancelled, or all uncancelled lines are referenced on purchase orders that meet the Purchase Order Purge Criteria (this condition applies only when you choose Matched Invoices and POs or Simple Purchase Orders for the purge category)

Requisition must be supplier (rather than internally) sourced. Payables will not purge invoices sourced by Oracle Inventory.

If Oracle Supplier Scheduling is installed, the requisition cannot be referenced on a supplier schedule, nor can the approved supplier list or planning sourcing rules be impacted

Requisition is not Oracle Projects related

Purchase Order Purge Criteria

If you are purging purchase orders, the Purge program deletes related purchase requisitions, and receipts. You can purge purchase orders that meet the following criteria:

You have not updated the header, line, shipment, or distribution after the Last Activity Date. Note that Oracle Purchasing automatically updates some of your purchase order information even if you are not in a purchase order window. For example, when you receive items against a purchase order, Purchasing automatically updates your purchase order shipment to reflect the quantity received.

You have not updated any releases for a blanket agreement that meets the purge criteria after the Last Activity Date

Purchase order is approved

Purchase order is cancelled or closed

Purchase order is billed and received

Any contract referenced on a standard purchase order meets the purge criteria

All online requisitions and all receipts referencing the purchase order meet the purge criteria

All invoices referencing the purchase order meet the Invoice Purge Criteria (this condition applies only when you choose Matched Invoices and POs for the purge category)

No invoices match the purchase order (this condition must apply only when you choose Simple Purchase Orders for the purge category)

Purchase order is not referenced in Oracle Inventory or Oracle MRP

If Oracle Supplier Scheduling is installed, the blanket release is not referenced on a supplier schedule

Purchase order is not referenced on an ASL

Purchase Order is not Oracle Projects related

Supplier Schedules Criteria

If Oracle Supplier Scheduling is installed, you can purge supplier schedules that meet the following criteria:

The schedule must be for the organization specified in the Submit Purge window. For multi–org schedules, we purge the schedule line that meets the purge criteria. Once all lines associated with a schedule are purged, the whole schedule is purged.

The schedule header Last Update Date must be on or before the Last Activity Date

All releases of blanket purchase orders referenced on the schedule must be either closed or eligible for purging

For organizations in which CUM Management is enabled, schedules must have a horizon start date before the current defined CUM Period

The e–Commerce Gateway interface table does not contain the schedule

CUM Period Criteria

If Oracle Supplier Scheduling is installed, you can purge CUM Periods that meet the following criteria:

CUM Management is enabled for the organization specified in the Submit Purge window. For multi–org schedules, we purge the schedule line that meets the purge criteria. Once all lines associated with a schedule are purged, the whole schedule is purged.

The Last Activity Date must be after the CUM Period end date for the purge organization. All previous CUM Periods are purged.

The system date cannot be within the CUM Period

When a CUM Period is purged, all CUM Period items, all data for supplier planning and shipping schedules, CUM Period high authorizations, and CUM Period adjustments are also purged

Order Management

Oracle Order Management has three areas which can be archive and/or purged:

Purge Orders

Purge Imported Credit Exposure

Purge Messages

Purge Orders

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.

Criteria

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.

Instructions

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 following two 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

(N) Orders, Returns > Order Purge > Order Purge Selection

(N) Orders, Returns > Order Purge > Order Purge

Purge Set Creation by multi-selection

(N) Orders, Returns > Order Organizer

selecting multi-selecting orders

(M) Tools > Purge > Purge Set

(B) Submit

Purge Imported Credit Exposure

The Purge Imported Credit Exposure concurrent program enables you to purge imported external credit exposure records by operating unit and exposure source. If you have imported external credit exposure records for multiple operating units, in order to purge all external credit exposure records you will need to submit the concurrent program for each operating unit you have imported external credit exposure records for.

Instructions

(N) Reports, Requests > Run Requests (B) OK > Purge Imported Credit Exposure

(N) Other > Requests > Run

Select ‘Purge Imported Credit Exposure’

Message Purge

The Message Purge concurrent program purges Order Management messages that are generated during order processing. To keep the Oracle Order Managmenet Message tables at manageable sizes, you should submit the Message Purge concurrent program at periodic intervals. After the concurrent program has successfully completed, you can use the Process Messages window and to verify that the Order Management message tables have been purged as specified by the input selection criteria.

Instructions

(N) Orders,Returns >Purge Messages

Shipping

You must use the Resolve / Purge Exceptions Parameters window to resolve and purge shipping exceptions. You cannot select, resolve and purge shipping exception records from the View Exceptions window.

Instructions

To resolve and purge selected logged shipping exceptions:

1. (N) Shipping Transactions (M) Tools > Resolve Exceptions

Or (N) Shipping > Exceptions (M) Tools > Resolve / Purge Exceptions

Inventory

Oracle Inventory has three areas which can be archive and/or purged:

Transaction Purge and Global Transaction Purge Purge Standard Cost History Purge a Margin Analysis Load Run Purge Replenishment Count Purge Cost Information Purge ABC Information Delete Items Inventory Position Purge Purge Cycle Count Purge Physical Inventory

Global Transaction Purge

Use the Global Transaction Purge Report to purge inventory transactions across multiple organizations set up in an organization hierarchy.

Instructions (N) Other > Reports > Run

‘Global Transaction Purge’

Transaction Purge

Purge all transaction history and associated accounting information for your current organization, where the transaction date is before and including the purge date you enter and is in a closed period.

G Once an inventory period has been closed it cannot be reopened. As a result, many companies choose not to close any inventory periods until required to for purging, so it is likely that there are no closed inventory periods in the production database.

Note: You should be extremely cautious when purging transaction information. Once you commit the process, Oracle Inventory removes all related information from the database. You cannot view or report on this information once you purge it. For example, you can no longer report purged information with the Accrual Reconciliation Report, the Transaction Register, and so on.

Note: Since the Job/Lot Composition functionality in Oracle WIP depends on the material transaction history, you should not enter a purge date which purges material transactions that are part of a genealogy you want to retain.

Instructions

(N) Transactions > Purge

Purge Standard Cost History

When you update costs and choose to save details, information associated with the update is retained so that you can rerun adjustment reports. When you no longer need such information, purge it.

Instructions

(N) Costs > Standard Cost Update > Purge Cost Update History

Purge a Margin Analysis Load Run

You can purge only those previous margin analysis load runs which are not continuous. Margin Analysis Load Runs created with Oracle Order Management installed are continuous and cannot be purged.

(N) ???? Purge Margin Analysis Run

Purge Replenishment Count

You can purge replenishment information including the count name, counting methods and quantities.

(N) Counting > Replenishment Counts > Purge

Purge Cost Information

You can purge cost types and all costs within the cost type. Or you can purge only part of the cost information, such as make or buy items, resource and outside processing costs, overhead rates and amounts or resource and overhead associations.

You cannot purge frozen costs in standard costing or average costs in average costing

You can safeguard selected cost types from inadvertent purging by disabling the Allow Updates check box when defining cost types.

(N) Costs > Cost Mass Edits > Purge Cost Information

Oracle Cost Management

Purge ABC Information

You can submit a request to purge either ABC assignment group or ABC compile information.

Purging an ABC group deletes all item assignments to ABC classes for the assignment group you specify as well as the ABC group itself.

Purging an ABC compile deletes all item values and rankings for the ABC compile you specify as well as the ABC compile itself. You can purge an ABC compile if no ABC groups are using it.

Note: You delete an ABC class from the ABC Class window.

To Purge ABC Assignment Group:

(N) ABC Codes > ABC Group

Select the group you want to purge

(M) Tools > Purge Group

(B) OK

To Purge ABC Assignment Compiles:

(N) ABC Codes > ABC Compiles

Select the compile you want to purge

(M) Tools > Purge Compile

(B) OK

Delete Items

The major use of item delete is to correct data entry errors. Oracle Inventory checks all possible references to an item and does not allow it to be deleted until every reference is removed. This means that if you transact an item, for example, you must first purge the transactions before you can delete the item.

Note that deleted items are not archived.

Inventory Position Purge

You can delete unused inventory position data sets using flexible criteria.

(N) Other > Requests > Run ‘Inventory Position Purge’

Purge Cycle Count

To purge cycle count information:

(N) Counting > Cycle Counting > Cycle Counts

Select a cycle count

(M) Tools > Purge Cycle Count

Purge Cycle Count Entries Open Interface Data

This process allows you to purge all cycle count entries from the open interface.

(N) Other > Requests > Run

‘Purge Cycle Count Entries Open Interface Data’

Purge Physical Inventory

You can delete a physical inventory definition from the database. Oracle Inventory deletes all information associated with the physical definition. However, the purge does not affect any adjustments or adjustment transactions made using the physical definition. Those adjustments are not changed. You can also purge just tags if you made a mistake and want to start over.

(N) Counting > Physical Inventory > Physical Inventories

Select the physical inventory you want to use

(M) Tools > Perform Purge

Projects

Oracle Projects has three areas which can be archive and/or purged:

Purging Expense Reports

Purging Imported Transactions

Purging Project Information

Purging Expense Reports

After you create invoices in Payables and then tie them back, you can create more space in your database by prging imported Oracle Projects expense reports from the Payables interface tables. To do so, identify the date through which you want to purge expense reports when you submit Payables Invoice Import. Payables purges the expense reports during the import process.

For expense reports created in iExpenses, you can have the Payables Invoice Import program purge imported information. The pure occurs after the program creates invoices from expense report information and the tieback process is complete.

Purging Imported Transactions

You can purge imported transactions from the interface table either automatically or manually:

To purge imported transactions automatically, you specify that a particular transaction source is purgeable (transaction source has Purge After Import = Yes) To purge imported transactions manually use SQL*Plus to remove the records from the interface table

The Account Generator: Purge Runtime Data profile option indicates whether to purge the data used to build account combinations as soon as the account generator is completed.

For best performance, set this profile option to No and then purge the runtime data in a separate operation. Setting the profile option to No retains (in the Oracle Workflow tables) the data used by the account generator to generate code combinations. To purge the data, run the Purge Obsolete Workflow Runtime Data program after the account generator process has executed successfully.

Setting this profile option to Yes purges the Oracle Workflow data as soon as the account generator has completed but may slow the performance of the account generator.

Archive and Purge

Archive and Purge allows you to purge unwanted project data from your production database and optionally archive the data to a set of parallel tables. There are four categories of data that can be purged and archived.

Actual Data: The detailed expenditure, revenue and staffing transactions (such as assignments and requirements) that are scheduled on the project being purged. This category also includes cross charge transactions that are charged to the project being purged.

Summary Data: The summarised data used for the Project Status Inquiry features of Oracle Projects

Capital Data: The asset line details

Resource Unassigned Time: Resource capacity, availability and overcommitment.

The type of data you can purge (and archive) depends on the Project Type Class and Project Status.

The archive and purge function does not purge project setup information (such as work breakdown structure), budgets, status reports and team templates.

Instructions

Purging projects involves four steps:

Create a purge batch. A purge batch is a list of projects whose data you wan to purge and/or archive

Run a validation process that determines whether the projects in the purge batch are eligible for purging

Release the batch for purging

Run a process to purge the batch

Purchasing

Oracle Purchasing has three areas which can be archive and/or purged:

Purge a Sourcing Rule

Purchasing Database Administration

Purge Purchasing Open Interface Processed Data.

Oracle Purchasing transactions are purged using the Oracle Payables purge processes.

Purge a sourcing rule

Select the sourcing rule name

(B) Purge

To purge a sourcing rule or bill of distribution

Select an assignment set name

(B) Purge

Purchasing Database Administration

Use the Purchasing Database Administration process to initiate concurrent processes that purge obsolete records in Purchasing interface tables and other temporary tables. You need to run this process only once because the AutoSubmit process resubmits itself daily after you submit it the first time.

(N) Submit Requests

Select Requests in the first field

Select Purchasing Database Administration in the Name field

(B) Submit Request

Purge Purchasing Open Interface Processed Data

The Purge Purchasing Open Interface Processed Data process purges data in the Purchasing Documents Open Interface tables. You can purge this data after you have imported the data into Purchasing. This process purges only accepted or rejected data, not data that is still pending.

In the Submit Requests window, select Purge Purchasing Open Interface Processed Data

Workflow

To purge the workflow runtime tables use the standard concurrent program FNDWFPR ”Purge Obsolete Workflow Runtime Data”.

Instructions

Navigate to the Submit Requests form in Oracle Applications to submit the Purge Obsolete Workflow Runtime Data concurrent program.

You can supply the following parameters for the Purge Obsolete Workflow Runtime Data concurrent program:

Item Type—The item type to purge. Leaving this field blank defaults to purging the runtime data for all item types.

Item Key—The item key to purge. Leaving this field blank defaults to purging the runtime data for all item keys.

Age—Minimum age of data to purge, in days.

Persistence Type—The persistence type to be purged, either ’TEMP’ for Temporary or ’PERM’ for Permanent. The default is ’TEMP’.

Note: If you have implemented Oracle Applications Manager, you can use Oracle Workflow Manager to submit and manage the Purge Obsolete Workflow Runtime Data concurrent program..

Systems Administration

Archiving Audit Data

Disable auditing using the “Disable – Prepare for Archive” and running the Audit Trail Update Tables report.

Archive it

Set the Archive group to Disable Purge Table and running the Audit Trail Update tables report.

Purge Concurrent Request and/or Manager Data

Use this program to delete:

Request log files, concurrent manager log files, ad report output files from your product directories maintained by the operating system

Records (rows) from Application Object Library database tables that contain history information about concurrent requests and concurrent manager processes.

Use this program to compute performance statistics for each of the concurrent programs, if the Concurrent: Collect Request Statistics profile option is set to “Yes”.

Purge Signon Audit Data

Use this program to purge Sign-On Audit information created before a specified date.

The following data is deleted:

Data for who signs on and for how long

Data for who is selecting what responsibility and when they do it

Data for who uses which forms in an application and when

Purge Obsolete Generic File Manager Data

To purge uploaded files form the Generic File Manager, run the concurrent program, Purge Obsolete Generic File Manager Data.

This concurrent program should also be used to periodically delete obsolete data. It is recommended that you schedule this program to run every day or so, using the default parameter values.

Conclusion

Archiving and Purging within each of the applications involves several steps, some of which may be performed by the Systems Administrator or a key user, others by the Database Administrator:

Archive the transactions as per the Application User Guide.

Export temporary archive tables to storage device (Database Administrator).

Purge the transactions as per the Applications User Guide.

Drop temporary archive tables (Database Administrator).

Export current data from tables from which you purged (Database Administrator).

Drop tables from which you purged (Database Administrator).

Recreate tables from which you purged (Database Administrator).

Import current data into tables from which you purged (Database Administrator).

Verify tables and indexes (Database Administrator).

The discussion summarised archiving across Applications, how to submit the purge processes, criteria for records to be purged, what information does and does not get purged, the tables information is purged from and how to restore archived information.