The previous section stated that the end result of Candidate Generation is a "list of transactions that can be archived and purged". First, what is a transaction? A transaction is a functional business object like an Invoice or a Payment or a Sales Order. In a relational database, the transaction is represented as a series of tables. If we think of a database entity relationship diagram, there is a table at the "top" of the model. This is the driving table. In a relational database, "children" tables are related to the driving table through "foreign key" relationships.

The diagram below illustrates how a transaction may be represented in a relational database:

Second, the list of candidate transactions is actually a table in the database. This table is called an "interim table". The table contains the primary key (PK) of the driving table. Using the PK, Data Archive can identify the related pieces of the transaction (e.g., the Lines, Notes and Attachments in the diagram above). Data Archive uses the interim table to perform the archive and purge of all the transaction tables.

Finally, candidate generation also tells why transactions cannot be archived and purged. This information is also stored in the interim table. For each transaction the interim table tracks what business rules a transaction has passed or failed. The results of the business enforcement are tracked as columns in the interim table.

An interim table may be constructed as follows:

HEADER_ID	PURGEABLE_FLAGHAS_INVALID_PAY_STATUS	HAS_NEGOTIABLE_CHECKS