Archiving GL Data in PeopleSoft

April 2007

Summary
It is very critical to have consistent and integrated framework to archive transactional data for older and not so much needed transactions before your database increases to unmanageable sizes. PeopleSoft Archive Manager introduced for PeopleTools. 8.4 tries to achieve this objective by using archiving templates that can leverage existing PeopleSoft Query framework and using pre-defined application engine processes to better manage the archiving processes. The following white paper gives an example of simple basic steps needed to use this tool efficiently and effectively in a PeopleSoft financials environment.

Developing an Archiving strategy and Techniques

This is one of the most important steps. It mostly depends on how the archived data will be used. At a very high level the idea is to move data into the history tables which enable you to query the selected data for information and copy data from the online tables into the history tables. By definition, history tables are identical copies of the online tables. However, history records must include PSARCHIVE_SBR sub-record that contains the archive ID and batch number. The other idea is if you accidentally delete the data from the online tables, there is a process to restore the data back from the history tables. And finally when you no longer need to reference the data from the history tables, you can delete them completely from the system. General Ledger contains the greatest amount of data to be archived because it is the module where the majority of reporting is required. Suppose that you require only one year of transactional data to be retained in the system for online purposes, but three years to be retained for reporting purposes. Any data beyond the above time frames for balances and transactions can be archived and is only be accessed through reports. The data can be archived to history tables. If data were to be archived into history tables, the data would still be available online for reporting purposes. However, you could not view it through standard PeopleSoft Internet Architecture pages without special mechanism to view that data. In addition, reports would need to be modified to access the data in history tables. Moving archived data to secondary storage devices is generally used for long-term data retention. This option is preferred for data that is rarely retrieved, and secondary storage devices are usually used to satisfy legal requirements. So lets assume for the purpose of this discussion that we will be archiving JRNL_HEADER and JRNL_LN tables that are the main GL transactional tables using

this tool. Now lets see what steps are required to achieve the desired archiving strategy to work.

Define Archive Objects

For this step you need to open PeopleSoft Archive Manage Homepage that looks as follows:

The first step is to define the archive object. Here is the one that we will be using:

You can delete the records that we have not been using like JRNL_VAT or JRNL_IU_ANCHOR etc. The important thing to understand is the difference between a

base and a non-base table. A base table is a table that contains all the keys by which all other tables in the archive object is archived from. Each archive object can have one and only one base table. You can define the selection criteria to archive from the base table. Non-base tables are joined together by common keys. In each archive object, non-base tables are archived based on the archived data of the base tables. You don't need to define archive criteria for non-base tables.

Manage Archive Templates

The second step is to use this object to define the archiving template that the process will use.

The query that is used to archive the objects in this case is a simple Archive type query developed using PeopleSoft Query Manager and the SQL for this query is as follows:
SELECT A.JOURNAL_ID FROM PS_JRNL_HEADER A, PS_BUS_UNIT_TBL_GL B WHERE A.BUSINESS_UNIT_IU = B.BUSINESS_UNIT AND A.BUSINESS_UNIT_IU BETWEEN :1 AND :2 AND A.LEDGER_GROUP = :3 AND A.JOURNAL_DATE >= :7 AND (( :4 = 'S' AND A.JOURNAL_DATE <= DATEADD(DAY, 0 - :6, { fn CURDATE() })) OR ( :4 = 'A' AND A.JOURNAL_DATE <= DATEADD(DAY, 0 - :6, :5)) OR ( :4 = 'P' AND B.POST_DATE_OPTN = 'P' AND A.JOURNAL_DATE <= DATEADD(DAY, 0 - :6, B.PROCESS_DATE)) OR ( :4 = 'P' AND B.POST_DATE_OPTN = 'C' AND A.JOURNAL_DATE <= DATEADD(DAY, 0 - :6, { fn CURDATE() })))

Archiving Data to History

The third step is to run the archive process using this template.

The Bind Variables of the query are specified here in this step and are specified as below:

Run the process that will populate the history records. Once the process runs to success you can query the JRNL_HDR_H and JRNL_LN_H records and see if the data is archived appropriately. Then create reports to use these tables. Once satisfied you can run the process to delete the online data or re-run your archive selection if not satisfied with the results. The last optional step is to view the audit information of who ran the archive processes and when. This tool can be very helpful in managing the complexities and size of the database by archiving years of data that may not be needed to be kept on the online transactional system. And last but not the least this approach improves the performance of the online system as well. If you have any questions or need more information about this or any white papers published on this site please email us at info@virtuosityglobal.com