Using your own process and tool, import data from your source applications into the staging table. Next, using Oracle Fusion Incentive Compensation, collect
that data into the transaction table using various parameters such as start and end dates as well as transaction type. View the log for each collection run to see details such as how long the process took using the Oracle Data Integration Console.
Tip
The application treats any credits imported from a source application just like transactions, populating them in the staging table along with the participant information.
Important
Ensure that you select Override Credit Amount by default (if this is a unique situation) or select Override Crediting the business unit level for recurring situations.
De-duplication
During the Collection process, the application updates the transaction request ID with a unique value, so that it only collects those identified transactions from staging. This enables you to import transactions into the staging table while the application is collecting transactions into the transaction table. During the Collection process, if the application detects duplicate transactions, it checks each staging table record that has the same transaction number and transaction type (composite key) and collects only the record with the most recent last updated date. For credit transactions, the application uses the combination of transaction number, transaction type, and credited participant ID to identify duplicates.
After de-duplicating the data selected for collection, the application checks for duplicates between the staging table records and the transaction and credit table records (original transactions) by comparing the composite keys.
• If the application detects a duplicate transaction, then it sets the status for the original transaction to Obsolete, collects the new transaction into the appropriate table, and sets change transaction to Yes.
• If the Payment process included the original transaction, the Collection process sets the original transaction status to Obsolete and change
transaction to Yes, so that regular processes, such as Crediting and Rollup, do not include the obsolete original transaction before the Reversal process runs.
• If the original transaction has a status of Paid, then the application reverses the transaction, credit, and earning records are reversed and creates a negative offset for these transactions. During the next run, the application processes the reversal along with the new (changed) transaction.
Validation
When the application collects the transactions from the staging table, it validates the data and then uses the specified parameters to identify the uncollected
transactions. Validation ensures that the mandatory columns are available and reference integrity is maintained.
• If PARTICIPANT_ID is populated, is there a corresponding entry in CN_SRP_PARTICIPANTS_ALL? If not, set the transaction status as Error -
Invalid Participant.
Important
The application checks against participant ID, so if this value is populated in the Participant ID and Credited Participant ID columns, the corresponding participant ID must exist in the participants table within OFIC.
• Does CREDITED_PARTICIPANT_ID have a corresponding entry in CN_SRP_PARTICIPANTS_ALL? If not, set the transaction status to Error -
Invalid Participant.
• If the process date is not in the correct date format, set the transaction status as Error. If it does not exist within the open period, the set the transaction status to Error - Period Not Opened
• If the process date does not exist within the open period, then update the record to Error - Period Not Opened
• If there is no exchange rate and the transaction currency is other than operating currency, then set the transaction status to Error.
• If the transaction has a credit category, then does it have the correct ID? If not, set the transaction status to Error.
• If the following mandatory fields are not populated, set the transaction status to an error; these columns cannot be NULL:
• Business Unit • Process Date
• Transaction Amount • Transaction Currency Code • Transaction Type
• Source Transaction Number
Collection inserts the validated and identified transactions into the transaction table and updates transaction statuses.
• If CHANGED_TRX_FLAG is N, the application inserts the transaction to the transaction table and sets the OBJECT_STATUS to NEW.
• If CHANGED_TRX_FLAG is Y, the application:
• Finds the corresponding transaction in transaction table and updates that OBJECT_STATUS to OBSOLETE
• Inserts the modified transaction to the transaction table and sets that CHANGED_TRX_FLAG to Y
The application deletes all records from the staging table after the Collection process completes.
Tip
If there are errors during the Collection process (from staging table to transaction or credit tables), then the application sets OBJECT_STATUS to COLLECTION_ERROR in the transaction table and CREDIT_ERROR in the credit table, so that you can correct the error transactions in the application or using functional desktop integration.
During each collection run, the application automatically re-validates any transactions in the based transaction table, and any credit transactions in the base credit table, that have an error status. For example, the application imported a missing participant after the original collection run, so during the next collection run, the application changes the status from Collection error to
New or Credited for the relevant transactions. Currency Conversion
After the application collects data from the staging table into the transaction table, it converts transaction table source currency values to operating currency values. If a conversion rate is missing for the transaction event date, the
application sets the transaction status to Collection error. Next, if collecting credit transactions, the application updates all currencies in the credit table.
• If there is an error for the base transaction, then it updates the corresponding credit transaction statuses with credit error.
• If the transaction has no error and four out of five credits are OK, the application sets the statuses for those four credits to Credited and sets the status for the fifth credit to Credit error.