Using Staging Tables

There are two types of staging tables:

• Constituent staging records.

• Transaction-specific staging records.

The constituent staging records are reusable across all transactions and therefore delivered with your system as part of CTM. The transaction-specific staging records must be created based on the transaction you want to perform.

A staging record is modeled after the corresponding production record, but its structure varies slightly:

• It is keyed by Temporary ID (SCC_TEMP_ID) instead of ID (EMPLID).

• It is never effective-dated (even if the matching production record is effective-dated). This is because the data entered in staging records can be updated, modified many times prior to be posted to production. Only at that time, the data is current and therefore the production record gets set with the date the data is posted.

The constituent data is saved in the delivered constituent staging records (see the following list of delivered constituent staging records). The transaction-specific data is stored in the transaction staging records. These staging records are either delivered with your system in the case of fully implemented delivered CTM consumers transactions (such as the AAWS admission transaction) or created by you for the transaction of your choice.

See Developer Reference for Creating a New CTM Consumer, “Step 1: Creating or Extending Staging Tables.”