Archival Purging

Published on January 2017 | Categories: Documents | Downloads: 44 | Comments: 0 | Views: 562
of 14
Download PDF   Embed   Report

Comments

Content

Archival & Purging Document For

Submitted By

Private & Confidential

1

Standard Purge Programs in Oracle Applications                           Purge Concurrent Request and/or Manager Data Purges Concurrent requests and/or GL Archive and Purge Archive and Purge Program Mass Additions Purge Report Mass Additions Purge Report AP/PO Purge Abort Routine AP/PO Purge Abort Routine AP/PO Purge Deletion Routine AP/PO Purge Deletion Routine AP/PO Purge Confirmation Routine AP/PO Purge Confirmation Routine AP/PO Purge Initiation (Selection) Routine AP/PO Purge Initiation (Selection) Routine AP/PO Purge Summarization Routine AP/PO Purge Summarization Routine Auto invoice Purge Program Purge processed transactions in the Auto Invoice Interface tables Purge transaction history Purge transaction history Purge physical inventory information Purge physical inventory information Purge Standard Cost History Purge Standard Cost History Purge Cost Information Purge Cost Information Purge Configurations Purge Configuration Items Purge Standard Cost History from SRS Purge Standard Cost History from SRS Purge Standard Cost Update History Purge Standard Cost Update History Engineering Change Order Purge program Engineering Change Order Purge Program CRP Purge Bill of Resources Purge Capacity Bill of Resources Purge Simulation Sets Purge Simulation Sets Purge Sales Orders Purge Sales Orders Order Purge Selection Order Purge Selection Order Purge Order Purge Purge Margin Analysis Run Purge Margin Analysis Run WIP Purge WIP Purge Payables Open Interface Purge Payables Open Interface Purge Purge Demand Interface Data Purge Demand Interface Data Purge Purchasing Open Interface Processed Data Purge Purchasing Open Interface New Archive and Purge New Archive and Purge

Auto Invoice Purge Program: Deletes records from interface tables. If you set the Purge Interface Table system option to No in Define System Option window, Auto Invoice does not delete processed records from the interface tables after each run, and we must submit Auto Invoice Purge Program periodically to clean up the interface tables. This program only deletes transaction lines that have been successfully imported

Private & Confidential

2

Payables Open Interface Purge Program Use the Payables Open Interface Purge Program after you have submitted Payables Open Interface Import program. This program purges records from the Payables Open Interface tables (AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE). You can either purge only invoices that you have successfully imported, or you can enter Yes for Purge All to purge all records in the table that match the Source and Group parameters you enter. Selected Report Parameters Source. Choose the source of the invoices you want to purge from the list of values. Use EDI Gateway, or a Source type Quick Code you defined in the Payables Quick Codes window. The source must exactly match the Source in the Payables Open Interface tables. This parameter is required. Group. (Optional) To limit the purge to invoices with a particular group, enter the GROUP_ID. The Group must exactly match the GROUP_ID in the Payables Open Interface tables. You can purge data in concurrent processes for the same source by specifying a unique Group for each request. This will reduce the time of your purge process. The Payables Open Interface Purge Program purges data with the source and group combination you specify. Purge All. Enter yes if you want to purge all records in the Payables Open Interface tables that match the Source and Group you enter above. These records include successfully imported records, records rejected during import, and records that you have not tried to import yet. Enter No if you want to purge only records that have been successfully imported. Submitting Purges Use the Submit Purge window to delete records you no longer need to access online. Suggestions for Purging Efficiently To purge the most complete set of records, choose the Matched Invoices and POs category first, then initiate a second purge for the Suppliers category. o Submit a purge when users are least likely to update records in the database. o The purge process can take several hours to complete, depending on the number of records in the purge and the resource capacity of your system. You can more efficiently purge a large number of records by submitting several smaller purges. On your first purge, set a Last Activity Date that is far in the past, and gradually increase the date with each purge. o Make sure that the database rollback segments you create are large enough so that you have sufficient memory to perform the purge. See your database administrator for assistance. See: Oracle8 Server Utilities Guide, Oracle8 Server Administrator's Guide. Prerequisites o Back up and archive the database. See: Backing up the Database (Oracle7 Server Utilities Guide). Confirm the integrity of the database backup. Create rollback segments to prepare the database. Log in as the Purge Administrator.

Private & Confidential

3

To complete the purge process: 1. In the Submit Purge Window, enter your purge parameters: Name. Unique name for the purge. Category. The category of documents you want to delete. o Matched Invoices and POs. Invoices matched to purchase orders, and purchase orders. o Schedules by CUM Period. CUM Periods and associated planning and shipping schedules. o Schedules by Organization. Planning and shipping schedules for the specified organization. o Simple Invoices. Invoices that are not matched to purchase orders. o Simple Purchase Orders. Purchase orders that are not matched to invoices. o Simple Requisitions. Cancelled purchase requisitions. o Suppliers. Suppliers that are inactive and have no active records associated with them. Last Activity Date. The purge program will delete records that have not been updated since the Last Activity Date you enter. Organization Code. For document categories Schedules by CUM Period and Schedules by Organization, you must select the organization. 2. Choose Initiate. The purge program identifies all records that match your criteria and system criteria. The purge program automatically prints the Preliminary Purged Listings Report, which lists all purge candidates. 3. Review the Preliminary Purged Listings report and identify any purge candidates that you do not want to purge. Update each purge candidate you do not want to purge by slightly modifying the record. For example, if you add a period at the end of an Invoice Description in the Invoices window, when you save the record, you will update the record's Last Update Date to today's date, thereby disqualifying it from the purge candidate list. 4. Confirm the Purge by querying the purge in the Submit Purge window and choosing Confirm. The Purge program revalidates the list of purge candidates and omits from the list any records that no longer meet your criteria or system criteria. The Purge program deletes all remaining, valid purge candidates and their related records. The Purge program then automatically submits a concurrent request to print the following reports: o Final Purged Listings Report. Lists all purged records. o Rejected Purged Listings Report. Lists any records that were listed as purge candidates on the Preliminary Purge Report, but that were not purged. For example, records you updated. o Final Purge Statistics Report. Lists summary statistics on the number of records you purge from each table in Oracle Payables and Oracle Purchasing. 5. Give your database administrator the Purge Statistics Report, and ask your database administrator to export and import the database tables and indexes from which you purged data. Purging Records You can delete Oracle Payables, Oracle Purchasing, and Oracle Supplier Scheduling records that you no longer need to access online to free up space in your database. You can purge invoices, purchase orders, suppliers, and related records such as invoice payments, supplier schedules, and purchase receipts.

Private & Confidential

4

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. Suggestion: You should create a special responsibility for purging information from Oracle Payables and Oracle Purchasing and assign this responsibility only to the person responsible for purging information from your database.

Criteria for Purging Records In addition to meeting the Record Category and Last Activity Date criteria that you select, records must meet other system criteria before the Purge program will delete them. This ensures that you do not inadvertently purge active records or records you need to keep for other reasons. 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: o Last Update Dates of the invoice and its distributions, and the Invoice Date, is less than or equal to the Last Activity Date o Invoice is fully paid or is a zero-amount invoice o Invoice is fully posted o Invoice does not have any 1099 distributions, and is not for a 1099 supplier o Invoice was not generated by a recurring invoice template o Invoice is not a prepayment, and no prepayments have been applied to the invoice o All of the invoice's payments meet the Payment Purge Criteria o No open encumbrances are associated with the invoice o Invoice is not Oracle Projects related o 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) o If Oracle Assets is installed, all of the invoice's distributions were tested by Mass Additions 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: o Unvoid payments have a Cleared Date that is less than or equal to the Last Activity Date o Payment is posted o All of the invoices paid by the payment meet the Invoice Purge Criteria o Payments are not reconciled and referenced by Oracle Cash Management Supplier Purge Criteria You can purge suppliers that meet the following criteria: o Supplier is not an employee o Supplier is inactive, and supplier's inactive date is less than or equal to the Last Activity Date you specify o Supplier is not a parent company or subsidiary of another supplier

Private & Confidential

5

o o o

o o o

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 EDI Gateway is installed, the Last Update Date of any EDI 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 EDI 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: o Requisition is cancelled o Requisition is not Oracle Projects related o 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) o Requisition must be supplier (rather than internally) sourced o 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 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: o 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 of 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. o You have not updated any releases for a blanket agreement that meets the purge criteria after the Last Activity Date o Purchase order is approved o Purchase order is cancelled or closed o Purchase order is billed and received o Any contract referenced on a standard purchase order meets the purge criteria o All online requisitions and all receipts referencing the purchase order meet the purge criteria o 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) o No invoices match the purchase order (this condition must apply only when you choose Simple Purchase Orders for the purge category) o Purchase order is not referenced in Oracle Inventory or Oracle MRP o Purchase order is not Oracle Projects related

Private & Confidential

6

o o

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

Supplier Schedule Purge Criteria If Oracle Supplier Scheduling is installed, you can purge supplier schedules that meet the following criteria: o 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. o The schedule header Last Update Date must be on or before the Last Activity Date o All releases of blanket purchase orders referenced on the schedule must be either closed or eligible for purging o For organizations in which CUM Management is enabled, schedules must have a horizon start date before the current defined CUM Period o The EDI Gateway interface table does not contain the schedule CUM Period Purge Criteria If Oracle Supplier Scheduling is installed, you can purge CUM Periods that meet the following criteria: o 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. o The Last Activity Date must be after the CUM Period end date for the purge organization. All previous CUM Periods are purged. o The system date cannot be within the CUM Period o 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 Purge Criteria Transactions: Transactions and all activities relating to the transactions such as adjustments, credits, reversals, calls, sales credits, and receipts must meet the following criteria: o 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). o 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. o 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.

Private & Confidential

7

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. o 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. o 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. o 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. o All transactions must meet the purge parameters you specify. o 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 Guarantee Cash Receipt Deposit balance and commitment balance is fully applied to one or more invoices. Commitment balance is fully covered by one or more invoices. 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. Batches A batch is not considered to be part of a transaction chain, therefore transactions that are part of a batch may be purged even if all transactions in the batch are not purgeable. The batch will be eligible for purge when all of the transactions associated to it are purged. Prior to a batch being purged you can review a batch with some of the transactions deleted. In this case the batch the Partially Purged check box will be checked and the Control Totals fields in the batch will appear to be out of balance. This is because the Actual Count and Amount fields in the Control Totals section do not include purged transaction data. Transactions Related to Projects Transactions related to Oracle Projects are not purged by default. However, you can override this default by adding your own criteria of what project-related transactions are to be purged.

Private & Confidential

8

For example, you may wish to purge project-related transactions originating from a project that has since been closed and that will not be reopened for additional activity.

Note: No transactions in Oracle Projects are purged. You specify your own criteria of what invoices to purge by adding your logic to the Receivables Invoice Purge client extension provided by Oracle Project Accounting. You first determine the logic that you want to include in the client extension. You then add and test your logic in the PL/SQL function client_purgeable in the package pa_ar_trx_purge. This function exists in the file PAXARPGB.pls located in the Oracle Project Accounting install/sql/ directory. Oracle Project Accounting provides the parameter of customer_trx_id to the client_purgeable function. For more information on implementing your own logic using a client extension, refer to the Client Extensions and AutoApprove Profile Options chapter in the Oracle Personal Time and Expense System Administrator's Guide. Transaction Related to Orders Transactions will not be purged if they are referenced by open return lines in Oracle Order Entry. In addition, commitments that are referenced by open order lines within Oracle Order Entry are not purgeable. To do this, the Archive/Purge process uses the view SO_OPEN_ORDER_INVOICE_REF_V and the table AR_PURGE_OE_EXCEPTIONS which hold transaction Ids of open orders. The purge program uses these as criteria for eliminating transactions from the purge process. For more information Client Extension Receivables provides a client extension to enable you to integrate with third party applications or choose to exclude or include transactions from purge selection based on criteria that you define. You specify your criteria by customizing the PL/SQL function trx_purgeable in the package arp_trx_purge. This function exists in the file ARPUPRGB.pls located in the Receivables install/sql/ directory. Receivables provides the parameter customer_trx_id to the trx_purgeable function which by default returns a true value. You need to add your logic to return a value of false for the customer_trx_id of the transactions you do not want to purge. The Archive and Purge programs delete transaction data from the following tables: o AR_ACTION_NOTIFICATIONS o AR_ADJUSTMENTS o AR_BATCHES o AR_CALL_ACTIONS o AR_CASH_BASIS_DISTRIBUTIONS o AR_CASH_RECEIPTS o AR_CASH_RECEIPT_HISTORY o AR_CORRESPONDENCE_PAY_SCHED o AR_CUSTOMER_CALL_TOPICS o AR_MISC_CASH_DISTRIBUTIONS o AR_NOTES o AR_PAYMENT_SCHEDULES o AR_RATE_ADJUSTMENTS o AR_RECEIVABLE_APPLICATIONS o RA_BATCHES

Private & Confidential

9

o o o o o o

RA_CUSTOMER_TRX RA_CUSTOMER_TRX_LINES RA_CUST_TRX_LINE_GL_DIST RA_CUST_TRX_LINE_SALESREPS AR_CORRESPONDENCES AR_DISTRIBUTIONS Archive and Purge Cycle

The Archive and Purge cycle is divided into four separate processes, Selection and Validation, Archive, Purge, and optionally Copying to a file. The Selection and Validation and Archive processes form the Archive-Preview program. This program selects eligible transaction using criteria you specified, validates the data to identify the transaction chains, then stores this information in the archive tables. The Purge program uses the information in the archive tables to delete eligible transactions from the database tables. Alternatively, you can run the Selection and Validation, Archive, and Purge processes together using the Archive and Purge program. The final process is to transfer the archive data to a separate storage medium. Using the Archive to File program enables you to write the archive information to a flat file. Alternatively, you can export the AR_ARCHIVE_HEADER and AR_ARCHIVE_DETAIL tables and import them into your own archive tables. Once you have completed all of the preparation steps, you can run the following programs from the Submit Requests window: Archive-Preview, Purge, Archive and Purge, and Archive to File. Each of these programs can be run as a separate process, however the Purge and Archive to File programs cannot be run until the Archive tables are populated by either the ArchivePreview or the Archive and Purge programs. Additionally, you can run the Archive-Restart program and Archive Reports from the Submit Requests window. Archive- The Archive-Preview program selects and validates transactions that meet the Preview purge parameters and copies the transaction information into the archive tables. A report is automatically generated after the archive tables are populated. The level of detail of this report is determined by the parameter you select when you start the Archive-Preview program. Purge The purge process purges eligible transaction data. To run this program you must first run the Archive-Preview program as this identifies eligible transactions and stores the Ids in AR_ARCHIVE_PURGE_INTERIM. Warning: You should only run the Purge program if no users have been on the system since you started the Archive-Preview, as this process does not revalidate the id's stored in AR_ARCHIVE_PURGE_INTERIM. Archive and The Archive and Purge populates the archive tables and purges transaction Purge information in one step. This can also be run after Archive-Preview if you cannot be sure that no users have been on the system since you started the ArchivePreview. Archive to File ArchiveRestart This is an optional program which can be used to copy the archive tables to a flat file if this is the desired method of storage. This program is used for error handling when the Archive-Preview or Archive and Purge fails. It can be used to save the system from having to revalidate all purge candidates, if Archive/Purge has completed the selection and validation phase, then fails during the archive phase. Archive-Restart clears the Archive Header and Detail tables and submits the archive report. When submitting the Archive-

Private & Confidential

10

Restart program you must provide the following parameters: Archive Level, Summary Report Only, Number of Workers, Commit Size, and Archive Id. Archive Summary Report Submit this report manually from the Run Reports screen if the report fails when submitted by the Archive and Purge or the Archive-Preview program. You can also submit this report to review summary information for previous Archive/Purge runs. The Archive Summary Report includes the amount and count of transactions selected for purge based on the AR_ARCHIVE_CONTROL table. When submitting the Archive Summary Report program, you must provide the Archive Id.

Archive Detail Report

Submit this report manually from the Run Reports screen if the report fails when submitted by the Archive and Purge or the Archive-Preview program. The Archive Detail Report includes a breakdown of the above summary information by customer. This report is based on the AR_ARCHIVE_HEADER table. When submitting the Archive Detail Report program, you must provide the Archive Id. A typical Archive/Purge process might include the following steps: 1. Change user responsibility. The Archive/Purge programs are only available to users with the AR Archive Purge User responsibility. 2. Run Archive-Preview In the Run Archive and Purge form, select the Archive-Preview program. When running the Archive-Preview program you must provide values for the following parameters: o GL Date Type (Required, Default) o Archive Period (Required) o Open Receivables Only (Required, Default) o Postable Items Only (Required, Default) o Customer Name (Optional) o Archive Level (Required) o Summary Report Only (Required, Default) o Number of Workers (Required, Default) o Commit Size (Required, Default) 3. Review Archive Report Use the Archive Report(s) generated during the Archive-Preview program to review transaction counts and amounts. The Grand Total of the report should equal zero. This report is based on the transactions selected for purge and stored in the AR_ARCHIVE_PURGE_INTERIM table. 4. Purge Database Tables Return to the Run Archive and Purge form to start the purge program by entering Purge in the Name field. The Purge removes transaction information from the database based on the data in table AR_ARCHIVE_PURGE_INTERIM. The Purge program provides the following parameters: o Number of Workers (Required, Default) o Archive Id (Required) The purge program does not generate a report as it would use the same archive table information as the archive report, so the two reports would be identical. Attention: If you wish to ensure consistency between the Archive-Preview and the Purge, no users should be on the system in the interim.

Private & Confidential

11

You can run the Archive and Purge instead of the Purge if you cannot be sure that no users have been on the system since you started the Archive-Preview. You must clear the archive tables before running this program. The parameters for this program combine the parameters of the Archive-Preview and Purge programs.

5. Move Archive Data to Storage From the Run Archive and Purge form, select the Archive to File program to move your archive data to a file in the standard output directory (AR_TOP/out) with the file name <user id.request id>. Warning: Ensure that you move your archive output from the AR_TOP/out directory to an appropriate storage area. Otherwise, it will be deleted when your system administrator clears the output directories. 6. Clear Archive Tables Once archive data has been stored the archive tables must be cleared before the next purge run. To clear the archive tables use the TRUNCATE command in SQL with the following tables: o AR_ARCHIVE_HEADER o AR_ARCHIVE_DETAIL The following tables will be cleared automatically the next time you run the Archive/Purge programs. However, you may wish to TRUNCATE these tables now. The TRUNCATE command is a more efficient way of clearing these tables and will save time during the next Archive/Purge process. o AR_PURGE_TRX_AUX o AR_PURGE_REC_AUX o AR_ARCHIVE_PURGE_LOG o AR_ARCHIVE_PURGE_INTERIM o AR_PURGE_OE_EXCEPTIONS The truncate command removes all of the rows from the tables. Warning: You cannot rollback a TRUNCATE statement. 7. Reorganize the Database After you purge your database, you should contact your Database Administrator (DBA) so that he can export and import the tables and indexes from which you purged data. By recreating these objects, you can reduce the memory each object occupies in your tablespace and increase the performance of your system. Assets 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.

Private & Confidential

12

What the Purge Program Removes 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. Maintain Audit Trail of Purge Transactions 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. Purge Fiscal Years in Chronological Order 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. Archiving and Purging Transaction and Depreciation Data If you no longer need to run reports for previous fiscal years, you can archive and purge historical data to free hardware resources. You can only restore the most recently purged fiscal year, so you must restore fiscal years in reverse chronological order. To archive and purge transaction and depreciation data: 1. Change Responsibilities to Fixed Assets Administrator. 2. Open the Archive and Purge window. 3. Enter the Book and Fiscal Year you want to archive. You must archive and purge in chronological order. 4. Choose Archive to submit a concurrent request that changes the status from New to Archived and creates temporary archive tables with the data to be purged. Oracle Assets automatically assigns an Archive Number when you save your work. Note: The temporary table name includes a five-digit archive number. 5. Export the archive tables to a storage device. 6. Return to the Archive and Purge window and use the Archive Number to find the archive you want to purge. 7. Choose Purge to submit a concurrent request that changes the status from Archived to Purged and removes the archived data from Oracle Assets tables. Now your database administrator can drop the temporary archive tables. You can only purge definitions with a status of Archived or Restored.

Private & Confidential

13

To restore archived data to Oracle Assets: 1. Import the archive tables from your storage device. 2. Open the Archive and Purge window under the standard Fixed Assets Administrator responsibility. 3. Use the Archive Number to query the archive you want to restore. 4. Choose Restore to submit a concurrent process that changes the status from Purged to Restored and inserts the previously purged data into Oracle Assets tables. You can purge the restored data again if necessary.

Private & Confidential

14

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close