Examples of Collecting Transactions and Credits
These two examples use a subset of transaction data to show the results when transactions are imported into the staging table and then collected into the transaction table in two different conditions.
- Condition 1 starts with a transaction that was created in the source application.
- Condition 2 starts with an adjusted version of the same source transaction.
Condition 1: New Transaction Created in a Source Application
This table shows a simplified transaction record created in the source application.
|
Source Order ID |
Source Transaction Line ID |
Source Order Date |
Source Transaction Amount |
Source Item ID |
|---|---|---|---|---|
|
1001 |
301 |
01-01-2015 |
10,000 |
Sentinel Desktop |
Import into Staging Table
When you import the transaction to the staging table, you must provide a unique source transaction number and transaction type. The combination of the source transaction number and transaction type is what a transaction is uniquely identified by in Incentive Compensation. You can also select which fields to bring into Incentive Compensation. Here’s an example of the transaction in the staging table.
|
Source Transaction Number |
Transaction Type |
Event Date |
Source Transaction Amount |
Source Item ID |
|---|---|---|---|---|
|
1001-301 |
ORDER |
01-01-2015 |
10,000 |
Sentinel Desktop |
Collect into Transaction Table
After you run the collect process, the transaction from the staging table gets deleted and then gets inserted with New status into the transaction table, which is very similar to the staging table. Here’s how your record would then be in the transaction table.
|
Source Transaction Number |
Transaction Type |
Event Date |
Source Transaction Amount |
Source Item ID |
Object Status |
|---|---|---|---|---|---|
|
1001-301 |
ORDER |
01-01-2015 |
10,000 |
Sentinel Desktop |
NEW |
Condition 2: After the Transaction is Modified in the Source Application
This table shows the same transaction in the source application, after the amount is modified from 10,000 to 12,000.
|
Source Order ID |
Source Transaction Line ID |
Source Order Date |
Source Transaction Amount |
Source Item ID |
|---|---|---|---|---|
|
1001 |
301 |
01-01-2015 |
12,000 |
Sentinel Desktop |
Import into Staging Table
When you import the transaction to the staging table, you must provide the same source transaction number and transaction type that was provided before because you’re updating the transaction. Here’s how your transaction would then be in the staging table.
|
Source Transaction Number |
Transaction Type |
Event Date |
Source Transaction Amount |
Source Item ID |
|---|---|---|---|---|
|
1001-301 |
ORDER |
01-01-2015 |
12,000 |
Sentinel Desktop |
Collect into Transaction Table
After you run the collect process, the transaction from the staging table gets deleted as before. But because the record has the same source transaction number and type, the collect process identifies that this is an update. So, the older transaction in the transaction table gets updated to Obsolete status and this latest transaction gets inserted with New status into the transaction table. Here’s how this transaction in the transaction table would then be.
|
Source Transaction Number |
Transaction Type |
Event Date |
Source Transaction Amount |
Source Item ID |
Object Status |
|---|---|---|---|---|---|
|
1001-301 |
ORDER |
01-01-2015 |
10,000 |
Sentinel Desktop |
OBSOLETE |
|
1001-301 |
ORDER |
01-01-2015 |
12,000 |
Sentinel Desktop |
NEW |
After Reversal
When you run the Revert process, obsolete records get moved to the transaction history table and get deleted from the transaction table. Here’s how this transaction would then be in the transaction table.
|
Source Transaction Number |
Transaction Type |
Event Date |
Source Transaction Amount |
Source Item ID |
Object Status |
|---|---|---|---|---|---|
|
1001-301 |
ORDER |
01-01-2015 |
12,000 |
Sentinel Desktop |
NEW |