This chapter covers the following topics:
Calculation is a process used by Oracle Incentive Compensation to calculate commission and bonus plans for resources.
Oracle Incentive Compensation supports two types of compensation calculation--Commission and Bonus. The Commission type of plan element is the most often used in Incentive Compensation, because it is based on transactions generated by a resource's sales activity. It can be quota or nonquota based. A Bonus type plan element is used to pay an extra amount to a resource for performance, but it has no direct links or references to specific transactions.
Oracle Incentive Compensation performs calculation in two ways: Complete and Incremental.
Complete Calculation
Complete Calculation calculates all transactions in the interval, and it is the default setting. Complete calculation erases the previous result and reruns the entire calculation process. Because it completely recalculates everything, it takes more time to finish compared to Incremental calculation. The advantage of Complete calculation is faster setup change because the system does not need to keep track of these changes.
Using Incremental calculation, the calculation engine of Oracle Incentive Compensation processes only transactions that are affected by a change. When you run Incremental calculation, the application uses the Notify Log, which tracks all changes made in the system since the last calculation. See Using Incremental Calculation for more detail on this calculation method.
When you calculate a set of transactions, the application performs these actions:
Preprocessing: The application determines which resources are to be calculated and performs validation. For example, it checks the resources to be sure that their compensation plans are complete and determines if they have any transactions within the specified dates.
Revert: This feature restores the transactions within your specified parameters back to their original unprocessed state. When a complete calculation is performed, the application deletes any system-generated (rollup) transactions and reverts the status of transactions to Unprocessed. This way the new calculation starts with no data left over from a previous calculation.
Classification phase: The application checks the applicable classification rules against the affected transaction attribute values. If a match is found, a unique product is assigned for each transaction. The status of matched transactions is marked as CLS (Classified). The classification rules packages consist of nested if-then-else clauses. The process starts from the top most rule; if the conditions for a rule are met, it moves to the child rule. If the conditions of the child rule are not met, the transaction is classified to the product associated with the Parent Rule. Otherwise, the Transaction Attributes will be compared to the next rule at the same level. If no rule is matched, transaction is marked as XCLS (Failed Classification).
One possible reason for Failed Classification is if the date format in the Compensation Manager's profile does not match that of the rule flex attributes that were entered when the Plan Administrator created the rule. See Building a Rules Hierarchy for more information on using flex attributes to create rules.
Rollup phase: Oracle Incentive Compensation runs a process to determine all resources who should receive credit for a transaction based on the rollup date and the resource hierarchy effective on that date. For every credit receiver, the application creates a new system-generated transaction. The transactions are marked as Rolled Up. Transactions that fail rollup are marked XROLL.
Population phase: Oracle Incentive Compensation identifies the appropriate plan elements for every transaction by matching the products of the plan elements with the products of the transaction. The application updates each transaction with the plan element information. The status after this phase succeeds is Populated. Lines that fail to populate are marked XPOP.
Calculation Phase: Based on the information gathered, Oracle Incentive Compensation performs calculation on all transactions that have passed the Population phase for resources specified for the period. It evaluates the expressions defined on a given formula, looks up the rate from the rate table, calculates the compensation amount, and updates the transactions and balance tables with the results. The transaction status is then displayed as Calculated. Lines that fail calculation are marked XCALC.
The following statuses can occur when a transaction has not been processed or if there is a failure during one of the calculation phases.
Unprocessed: The transaction has not been processed or has been returned to unprocessed state after a revert phase. The application displays a status for unprocessed transactions in transaction status. If you receive an Unprocessed status, make sure that the Ruleset is synchronized. Or, if there are invalid classification rules packages, attempt to recompile them manually. The most common reason for a classification rules package to remain INVALID is because of the column_datatype of the attribute column being used to classify a transaction. For example, if an attribute column or a mapped column has a datatype of CHAR, (as defined in the Tables and Columns form) and a rule uses a number as its value, a conflict occurs. This conflict will allow the Classification Ruleset to Synchronize, but will prevent the classification rules package from compiling. If this is the case, the rule needs to be re-created using an attribute column with a column_datatype of VARCHAR2 or NUMBER.
Failed Classification: Transactions that do not match a predefined classification rule receive the Failed Classification status (XCLS). A primary cause of Failed Classification status is that the transaction attributes do not satisfy the very top classification rule in the hierarchy. Another cause of failed classification is that the processing date is outside the dates defined for the Classification Ruleset. Classification rules and transaction attributes are case sensitive, so check to be sure that they match.
Failed Rollup: If a resource is not in the hierarchy in a compensation group or has not been assigned Sales Compensation group usage, the rollup fails, and a transaction status of XROLL is displayed.
Failed Population: Population fails if a transaction does not match any plan element in the compensation plan for the credited resource. Transactions and plan elements are matched using products and the effective product hierarchy. Transactions that fail population are marked as XPOP.
Failed Calculation: Oracle Incentive Compensation indicates a failed status for transactions that have failed the calculation phase in the transaction status. Check your calculation rules, and be sure that your calculation expressions, rate tables (if applicable), plan elements, and compensation plans are all valid. Transactions that fail calculation are marked XCALC.
The process of calculation comprises three main sections, as follows.
The Rollup Phase
During the Rollup phase, Oracle Incentive Compensation runs a process to determine all resources who should receive credit for a transaction based on the rollup date, and the resource hierarchy effective for that date. For every credit receiver, Oracle Incentive Compensation creates a new system-generated transaction and the lines are marked as Rolled Up.
Multiple resources can receive credit for the same transaction. For example, a sales manager may receive sales credit for his subordinate's transactions. If you choose to compensate multiple resources for the same transaction, you must organize your compensation groups into a hierarchy to specify the relationships among the credit receivers in your sales force.
When transactions are processed with a hierarchy in effect, resources in parent positions automatically receive all of the sales credit applied toward resources in child positions that report to them, regardless of product. This roll-up credit is also called indirect credit.
When Oracle Incentive Compensation allocates sales credit to multiple credit receivers, each person receiving credit for the transaction receives 100% of the sales credit.
For example, in a hierarchy, three salespeople report to a manager; the manager reports to a director. The first resource receives $10,000 for an invoiced transaction, the second receives $5,000 for a different transaction, and the third resource receives $7,000 for another transaction. Each resource receives sales credit for the individual transaction that results from their work. However, if Managerial Rollup is checked for rollup, the salespeople's manager receives $22,000 in indirect rollup sales credit.
In addition to the three invoices mentioned, a fourth invoice gives the manager $15,000 in direct sales credit. The salespeople reporting to the manager do not receive any credit.
The manager's boss, the director, is at the top of the rollup hierarchy. The director receives a total of $37,000 in indirect rollup sales credit, including both the Manager's direct $15,000 credit and the $22,000 total for the three salespeople that rolls up to him through the manager.
What to Do if Rollup Fails
If Rollup fails, verify the following:
The resource on the transaction is assigned to a compensation group.
The group the resource is assigned to has the usage of Sales Compensation.
If the resource on the transaction belongs to more than one compensation group, the profile OIC: MULTI_ROLLUP_PATH is set to Y (not Yes or y).
During the Population phase, Oracle Incentive Compensation identifies the appropriate plan elements that are associated with the resource's compensation plan that have been allocated to the transactions. The application attempts to match transactions with the Plan Elements for the credited resources and if the match is successful, the transaction is populated.
The application performs the following checks during the Population phase. It
Identifies the compensation period
Identifies the plan element and assigned Sales Role and Compensation Plan (based on Plan Element to Product Mapping)
Uses the Product Hierarchy (traversing the hierarchy upwards to determine the most general product)
Handles revenue class overlap (The system generates a duplicate transaction line record for any transaction that is associated with more than one Plan Element due to revenue class overlap.)
Handles multiple roots (The system creates a system-generated duplicate transaction line record for any transaction that is associated with more than one sales role within a compensation group.)
Fails population. If the transaction does not find a matching revenue class in the compensation plan for the credited resource then no compensation can be calculated. Oracle Incentive Compensation displays a status of Failed Population (XPOP) in the transaction status column.
What to Do if Population Fails
Check if there is a role and in turn there is a compensation plan assigned to the resource on the date of the XPOP transaction. If there is no role or compensation plan assignment and this is not intended, then assign the appropriate role and compensation plan to the resource.
If there is a compensation plan assigned to the resource, check whether the compensation plan has a COMPLETE status.
If compensation plan is complete, then check whether any of its plan elements effective on the date of the transaction has a matching revenue class with the transaction's revenue class. Whether there is a revenue class match is determined by the revenue class hierarchy. If the revenue class on the plan element is a parent revenue class of the revenue class of the transaction, it is a match.
If there is a revenue class match, then check and make sure that the involved revenue classes exist in the revenue class hierarchy. If not, add them to the revenue class hierarchy.
Make sure that the Revenue Class that the transaction was assigned is assigned to at least one Plan Element that is included in the resource's compensation plan.
Make sure that the Sales Compensation role that is assigned to the resource has either the Member or Manager box checked.
Make sure the resource's Sales Compensation role is a Group Member role for the date of the transaction.
Make sure that the group the resource is assigned to has the usage of Sales Compensation.
After the above setup is validated, run calculation again.
During the Calculation Phase, Oracle Incentive Compensation performs the calculation on all transactions within the specified parameters. It evaluates the expressions defined on a given formula, looks up the rate from the rate table, calculates the compensation amount, and updates the transactions and balance tables with the results. Oracle Incentive Compensation displays a status for calculated transactions in the transaction status column.
The Calculation process calculates compensation based on the Calculation Rules (defined in Plan Elements). Calculation Rules include Commission Rate (defined in the Rate Table), Accelerators (earnings factor, multiplier, and transaction factors), Accumulation or Non-Accumulation, Split or Non-Split, Interval-to-Date Quota or Annual Quota, Individual or Group By. If the application is unable to calculate the compensation for the transaction, the transaction is marked as 'XCALC' (Failed Calculation).
What to Do if Calculation Fails
If transactions failed to be calculated, Oracle Incentive Compensation displays a status of XCALC for those transactions. Check the following things if calculation fails for a transaction:
The value passed to the Rate Table from the Input Expression is included in the Rate Table. (To prevent this problem always make the first tier of the rate dimension 0 to X instead of starting it as X to 10000, for example).
No values in the Formula are divided by zero.
All columns used in the formula to calculate are populated for the transaction.
The formula packages are valid (regenerated).
The number of inputs to the formula match the number of dimensions of the rate table.
The type of formula input matches the rate table dimension type.
Before you run a compensation calculation, you must make sure that calculation is possible for the salespeople chosen. You must verify the following things before attempting to calculate compensation payments:
Make sure that all salespeople to be compensated have a valid compensation plan assigned to them.
Make sure that the compensation period for which you are calculating has an Open period status. You can only open a period if the current compensation period status is Never Opened, Future Entry, or Closed. To open a period, navigate to Setup > Maintain Compensation Periods.
You must have defined your classification rules and synchronized your classification rule set.
The rollup summarized transactions process results in a significant reduction in the number of transactions that need to be processed, which improves performance substantially.
Without the rollup summarized transaction feature turned on, the collection process replicates base transactions to every resource in the rollup hierarchy. This means that in a rollup hierarchy that is five levels deep with five base reps all rolling up to the same set of managers, all transactions from the five base reps are replicated to every manager. As an example, if each of the five base reps has ten transactions, there is a total of 50 base transactions. After rollups, including all transactions for each resource to their manager, there are 250 transactions, as shown below:
10 transactions x 5 levels deep x 5 base reps = 250
However, if the Rollup Summarized Transactions feature is turned on, then the following occurs:
Before Rollup:
Total base transactions = 50 in CN_Commission_Headers (same as before)
Total summarized transactions = 5 in CN_Commission_Headers (one for each base resource)
After Rollup:
Total number of transactions = 5 x 5 = 25 (five summarized transactions are rolled up to each of the five managers)
You can summarize transactions if they share common definitions. The default set of definitions includes the following fields:
direct_salesrep_id
processed_period_id
processed_date
rollup_date
comp_group_id
revenue_class_id
trx_type
Any transactions that match in these seven fields will be aggregated and processed together. Therefore, it is very important to verify that your aggregated calculations create the same result as when they are calculated separately. Some formulas can generate different amounts of compensation if aggregated transactions are used.
The following examples show a situation where aggregation does not affect calculations and a situation where it does:
Example 1: Aggregation Yields same Result as Individual Transactions
The formula uses these settings:
Cumulative Flag: Yes
Non-proportional Flag: Yes
Apply Transactions Individually
Input: transaction_amount
Output: rate*transaction_amount
Rate Table below shows two columns and two rows, with 0-100 at 1% and 100-500 at 3%:
| Transaction Amount | Commission |
|---|---|
| 0-100 | 1% |
| 100-500 | 3% |
There are two transactions:
1. Transaction Amount of 90
2. Transaction Amount of 20
Without aggregation, the calculation proceeds as follows:
For the first transaction, the input of 90 falls into the first tier of the rate table, and is compensated at 1%. Commission is 90 * 1% = 0.9.
For the second transaction, the input is 90+20=110, because the cumulative flag is selected. This puts the transaction into the second tier. Because there is a non-proportional split, the commission is 10 * 1% + 10 * 3% = 0.4.
The total commission for both transactions is 0.9 + 0.4 = 1.3.
If the aggregation parameter is turned on, there will be one aggregated transaction with a transaction amount of 110. The calculation process proceeds like this:
The input is 110. Because there is a non-proportional split, the commission is 100 * 1% + 10 *3% = 1.3. The aggregated transactions yield the same result as the individual transactions.
Example 2: Aggregation Yields a Different Result
This example uses the same transactions, but the formula is not cumulative. Because of this, the calculation result of an aggregated transaction is different from the total of the individual transactions.
Commission is calculated as follows:
Transaction Amount is 90 * 1% = 0.9
Transaction Amount is 20 * 1% = 0.2
The total commission for both transactions is 0.9 + 0.2 = 1.1.
If aggregation is turned on for these non-cumulative transactions, there will be one aggregated transaction of 110. The calculations are as follows:
Aggregated Transaction 100 * 1% + 10 * 3% = 1.3 (with a non-proportional split).
In this case, the commission derived from the aggregated transaction is different from the commission derived from individual transactions.
Two Parameters
Two calculation parameters control how transactions are rolled up.
Navigation: Incentive Compensation Administrator > Calculation > Setup Calculation Parameters
Aggregate Transactions during Rollup: This parameter sets up the application to aggregate matching transactions. Set Yes or No; the default is No
Aggregate Transactions Based on Custom Criteria during Rollup: This parameter works only if Aggregate Transactions during Rollup is set to Yes. The parameter tells the application whether you are using default or customized summarization code. Set Yes or No; the default is no.
Note: After you change the setting of a profile option, you must bounce the server to reset it.
Under some circumstances, compensation must be derived from multiple aggregated values. One way to accomplish this is to use multiple aggregated values in a formula and to split rate tiers in multidimensional rate tables.
When you assign expressions to a cumulative formula, you can specify for each expression whether it is cumulative or not. If you want to split rate table tiers when calculating compensation, you can select one dimension upon which to perform the split.
There is no limit as to how many expressions can be cumulative, however you can specify only one dimension to be split in any formula that is used in a multidimensional rate table. Any more splits would render the calculation process meaningless.
Generic Example of Accumulation Along Multiple Dimensions
Suppose we have the following rate table.
| Quantity | 0-80% | 80-90% | 90-999% |
|---|---|---|---|
| 0-100 | 1% | 1.5% | 2% |
| 100-200 | 1.5% | 2% | 2.5% |
| 200-1000 | 2% | 2.5% | 3% |
The first dimension measures the total quantity of the sales and the second dimension measures the percentage achievement of the total transaction amount against the target.
Assume the following formula is used:
Name: Formula 1
Type: Commission/Apply individual transaction
Cumulative: Yes
ITD: No
Split: No split
Input1: quantity (cumulative: Yes)
Input2: transaction_amount/target (cumulative: Yes)
Output: RateResult * transaction_amount
Suppose you have the following transactions.
| Transaction ID | Quantity | Transaction Amount |
|---|---|---|
| 1 | 50 | 1000 |
| 2 | 100 | 2500 |
| 3 | 500 | 4000 |
The target for the example resource is 5000.
The compensation will be calculated in the following way. For the first transaction, the cumulative total from input1 is 50 and the cumulative total from input2 is 1000 / 5000 = 20%. Comparing the two cumulative values against the rate table, the rate is 1%. Now apply this rate to the current transaction's transaction amount and you get 1000 * 1% = 10.
For the second transaction, the cumulative total from input1 is 150 (adding 100 to the previous total of 50 from transaction1) and the cumulative total from input2 is 20% + 2500 / 5000 = 70%. Comparing these two cumulative values against the rate table, we find the rate to be 1.5%. Apply this rate to the current transaction's transaction amount and you get 2500 * 1.5% = 37.5.
For the third transaction, the cumulative total from input1 is 650 (adding 500 to the previous total of 150 from transaction1) and the cumulative total from input2 is 70% + 4000 / 5000 = 150%. Comparing these two cumulative values against the rate table, the rate is 3%. Apply this rate to the current transaction's transaction amount and you get 4000 * 3% = 120.
The total compensation for all these three transactions will be 10 + 37.5 + 120 = 167.5.
Note that both input values are accumulated and the cumulative totals are used to look up the rate from the rate table.
Generic Example of Split in a Multi-Dimensional Rate Table
Suppose we have the following rate table.
| Quantity | 0-80% | 80-90% | 90-999% |
|---|---|---|---|
| 0-100 | 1% | 1.5% | 2% |
| 100-200 | 1.5% | 2% | 2.5% |
| 200-1000 | 2% | 2.5% | 3% |
The first dimension measures the total quantity of the sales and the second dimension measures the percentage achievement of the total transaction amount against the target.
Assume the following formula is used:
Name: Formula 1
Type: Commission/Apply individual transaction
Cumulative: Yes
ITD: Yes
Split: Non-proportional split
Input1: quantity (cumulative: Yes/Split: Non-proportional split)
Input2: transaction_amount/target (cumulative: Yes)
Output: RateResult * quantity
Note that split is performed on the first dimension which corresponds to the first input. Suppose you have the following transactions.
| Transaction ID | Quantity | Transaction Amount |
|---|---|---|
| 1 | 50 | 1000 |
| 2 | 100 | 2500 |
| 3 | 500 | 4000 |
The target for the example resource is 5000.
The compensation is calculated in the following way. For the first transaction, the cumulative total from input1 is 50 and the cumulative total from input2 is 1000 / 5000 = 20%. Since 20% matches the first column in the rate table, you use the rates in the first column while splitting the quantity total along the first dimension. Since 50 is completely within the first tier of the first dimension, all of it is compensated at the rate of 1, thus yielding a commission of 50 * 1 = 50.
For the second transaction, the cumulative total from input1 is 150 (adding 100 to the previous total of 50 from transaction1) and the cumulative total from input2 is 20% + 2500 / 5000 = 70%. Since 70% still matches the first column in the rate table, you use the rates in the first column while splitting the quantity total along the first dimension. The first 100 out of the total of 150 is paid at the rate of 1 and the remaining 50 that falls in the second tier is compensated at a rate of 1.5. Therefore, the commission is 100 * 1 + 50 * 1.5 = 175. Since it is ITD calculation, we need to subtract the previous payout. So, the commission is 175 - 50 = 125.
For the third transaction, the cumulative total from input1 is 650 (adding 500 to the previous total of 150 from transaction1) and the cumulative total from input2 is 70% + 4000 / 5000 = 150%. Since 150% matches the third column in the rate table, you use the rates in the third column while splitting the quantity total along the first dimension. So, the first 100 gets paid at a rate of 2, the next 100 gets paid at a rate of 2.5 and the remaining 450 gets paid at a rate of 3. The total is 100 * 2 + 100 * 2.5 + 450 * 3 = 1800. Subtracting the previous payouts, the commission is 1800 - 125 - 50 = 1625.
Note that only the dimension marked to perform a split is traversed while splitting the total amount. The other dimension(s) is only used to determine which set of rates are used in computing the compensation.
You can calculate compensation for all resources who have valid compensation plans, for all resources in the notify log file, or for resources you specify. The Calculation Requests page displays a summary of all of the calculations that you have submitted. You can click the link in the Batch Name column or use the search parameters at the top to narrow your search to selected batch names. Or, click Calculate Compensation to create a new calculation submission.
You can click View Log to view the log messages generated during a given calculation run. You can navigate to the View Notification Log page to view the changes that have been made to the Oracle Incentive Compensation system that Incremental Calculation uses to speed up the calculation process.
It is recommended that you run calculation for all resources if you are running Complete Calculation. If you are running Incremental Calculation, you should specify For All Resources in Notify Log. This ensures that all dependencies among resources are handled automatically by the application. If you intend to run calculation for a small number of resources and want to specify the resources, be sure to include all resources having dependencies among them in your calculation submission. You can check the Include Hierarchy box to include resources below a specific resource.
The Request ID is stored as a column and a search parameter for any calculation request that is submitted concurrently. The Request ID is not recorded for calculation requests that are submitted as an online process.
Calculation can be run as often as necessary.
You can select commission calculation or bonus calculation. See Two Types of Calculation.
In the procedure below, to create a new batch, start at step 1. To use a previously defined batch, click the link in the Batch Name column and begin at step 8.
Navigation
Compensation Manager > Calculate Compensation
Prerequisites
Steps
Click Calculate Compensation.
Enter a name in the Name field.
Select the beginning and end dates of the transactions to be calculated.
Select the type of calculation to be submitted, either Commission or Bonus. At this stage, the calculation status is Incomplete.
For Bonus calculation, select an interval type.
Bonus calculation often uses a different interval than Commission calculation. For example, a bonus can be paid once a year while commission is calculated monthly. Therefore, you must select one of the seeded interval types: Period, Quarter, or Year. Commission calculation can use any interval types as defined separately by the Incentive Compensation Administrator using the Compensation Workbench.
Check the Incremental Calculation box if you want to run incremental calculation to process the pending changes made to the system.
Select one of two resource options. These options change depending on whether the Incremental Calculation box is checked or not. If the box is unchecked, these options appear:
All Resources: Calculates compensation for everyone
Specific Resources: Enables calculation of compensation only for resources you choose.
If the Incremental Calculation box is checked, these two resource options appear:
Resources in Notify Log: Calculates compensation for resources affected by recent changes to their compensation setup or newly loaded transactions, as recorded in the Notify Log.
Specific Resources
The following steps apply to batches that you have just created or previously created batches. For previously created batches, it is assumed that you have run a search for the batch.
Select a calculation method.
Run Calculation: Runs online, and is best for small jobs.
Schedule Calculation: Sets up a concurrent request, and is best for big jobs that can run in the background. See Restrictions for more information.
The process changes depending on a number of factors:
If you selected All Resources or Resources in Notify Log in the Resource Option field previously, and you selected Commission type, calculation runs if you click Run Calculation, or you are sent to the scheduling procedure if you selected Schedule Calculation.
For bonus calculation only, select the bonus plan elements that you want to use from the drop-down list. This finer granularity of choice for bonus calculation enables you to calculate bonus plan elements individually. After you select the bonus plan elements, click Run Calculation or Schedule Calculation
If you selected Specific Resources you must enter the specific resources for whom you want to submit a calculation.
To enter specific resources for calculation:
Click Add Resources.
Select a resource from the list of values. Create more blank rows as needed.
Check the Include Hierarchy box if you want to run calculations for the resource and all of that resource's subordinates.
When you have finished entering names, run or schedule the calculation.
If you are scheduling calculation, proceed through the six-step procedure. Click Next between steps, and after you have reviewed the submission, click Submit.
If calculation was successful, the Status field now displays Completed.
To verify that the calculation was processed correctly, you can go to the Year to Date Summary for the corresponding fiscal year. Search for the resource name and select the correct fiscal year.
After the calculation batch Information page displays, click OK to return to the Requests page.
Click the Details icon to see more information, including Diagnostics.
The Status field displays the status of the calculation using these values:
Incomplete: The calculation has not been submitted.
Complete: The calculation has completed successfully.
Failed: An error has occurred. You can run the calculation again, if necessary.
In progress: The calculation is still in the process of running.
Transactions with process dates that fall within the dates you specify are included in the calculation.
If you have made a change that affects the calculation, for example, to a rate table, then the application lists in the Notify Log all resources and periods that are affected by the change. Select Resources in Notify Log to calculate all the resources affected by the changes made.
You can use parameters to determine for whom calculation is performed:
Schedule Calculation: If the calculation is large, select this option to run the calculation as a background process in the Concurrent Manager. After you submit a concurrent process, you can proceed to do other things while it completes the calculation. You may want to make a note of the concurrent request ID number in case you want to check the status of the process later on. If a batch runner fails during concurrent calculation, the application automatically cancels other running and pending batch runners. If you deselect this option, then calculation is performed online.
Incremental Calculation: Use Incremental Calculation for most or all of your calculations. This option calculates only newly added transactions and transactions that are affected by the new transactions. This option also calculates the compensation for resources who are affected by events that happened since the previous calculation.
If calculation fails, you can resubmit and if calculation is run for all resources, the calculation process will try to pick up from the point of failure rather than having to start from the beginning. Calculation can fail at any phase in the process:
Revert
Classification
Rollup
Population, or
Calculation
Query for the batch by name or select Failed from the Calculation Status drop-down list to list all failed batches.
Transactions must be collected and loaded.
If you have a large volume of transactions to process, it can save time to process only those transactions that have been affected by some change. Incremental Calculation marks all predefined transaction events in a notification log table known as the Notify Log. By doing this, Oracle Incentive Compensation runs calculation only for the resources that require it.
In the Notify Log table, the REVERT_TO_STATE column tells the calculation engine to what state the transactions need to be reverted. In complete calculation, transactions are completely deleted and returned to the Unprocessed state. But in Incremental Calculation, the calculation engine can selectively skip various phases of calculation for individual transactions.
The Notify Log records changes related to five phases of calculation (see Phases of Calculation).
Revert
Classification
Rollup
Population
Calculation
Any changes occurring to the following elements could cause the need for recalculation:
System Parameters
Classification Rules
Product Hierarchy
Dimensions used in classification rules
Formulas
Rate Tables
Plan Elements
Start date, end date
Eligible Products
Transaction factors
Compensation Plans
Role plan assignment
Resource role assignment
Resource level plan element change
Interval number
New transactions
Salespeople hierarchy
Payee assignment
Team assignment to a resource
Pay group assignment to a resource
To use Incremental Calculation you must check the Incremental Calculation box on the Calculate Compensation page when running the calculation. To enable the Notify Log functionality you must set the profile option OIC: Enable Incremental Calculation to Y. Note: After you change the setting of a profile option, you must bounce the server to reset it.
If you normally use Incremental Calculation for every calculation you do not need to deselect the Incremental Calculation box. The Notify Log keeps track of changes and if a Complete Calculation is required it will do this automatically. You can check the Notify Log to see if it will run for all resources to get an indication of how long the calculation will take.
Oracle Incentive Compensation can track notifications to the following four levels:
Resource Level: If an event causes re-calculation for multiple periods, then the mark event creates an entry for a resource with a Null period and specifies the date range.
Resource/Period Level: A resource usually has one entry per period with a status of Incomplete in the Notify Log table. If the event causes a change to all resources, then instead of adding an entry for all the resources, there is a global entry, which tracks all resources for a period.
Resource/Period/Start Date Level: If an event causes the change at the specific date level within a period, notification can track at specific date range level. This allows recalculation to be done for transactions falling within the specified date range instead of calculating for the entire period.
Resource/Period/Start Date/Plan Element Level: This level is the most granular level that is captured, and it makes Incremental Calculation the most efficient. For the events that cause the REVERT_TO_STATE to go only to the Population phase, only the Calculation phase needs to be rerun. This makes sense if, for example, the transaction is being rerun only because of a change in the commission rate of a single plan element.
Incremental Calculation, compared to Complete Calculation, has an effect on calculation times because it calculates only for new transactions. However, if any new transactions have a dependency on previous transactions, this may result in a large number of recalculations, which can add to the time it takes Incremental Calculation to run. This scenario shows how a new transaction can cause other transactions to be recalculated.
Rate table:
| Transaction Amount | Rate (Percent) |
|---|---|
| 0-500 | 1% |
| 500-2000 | 2% |
| 2,000-9,999,999 | 5% |
Three transactions:
01-Jan-2007 100
05-Jan-2007 300
10-Jan-2007 1,000
A simple cumulative, no-split formula is used:
Input Expression: Transaction Amount
Output Expression: Rate * Transaction Amount
The commissions for these transactions are:
01-Jan-2007 100 100 * 1% = $1
05-Jan-2007 300 300 * 1% = $3
10-Jan-2007 1,000 1,000 * 3% = $30
A new transaction for $900 on 04-Jan-2007 is loaded into the system and commissions for all four transactions are follows:
01-Jan-2007 100 100 * 1% = $1
04-Jan-2007 900 900 * 3% = $27
05-Jan-2007 300 300 * 3% = $9
10-Jan-2007 1,000 1,000 * 5% = $50
The $900 transaction of 04-Jan-2007 has changed the rate for the 05-Jan-2007 and 10-Jan-2007 transactions, so when calculation is rerun, those transactions must be recalculated.
When you run Complete Calculation, the application redoes everything. Incremental Calculation does not redo classification and rollup, which has already been done in the loading process. In Incremental Calculation, the application goes through all of the calculation phases, in case there are pending setup changes to process. However, since the new transactions have already been classified and rolled up in the loading process, it goes through Classification and Rollup quickly. New transactions are populated in the Population phase. Therefore, much of the real time saving benefit of Incremental Calculation is seen in the other phases before calculation itself.
The Notify Log automatically records every change in the system that affects calculation. The Notify Log lists what part of the calculation is affected and therefore must be rerun as a result of an event.
You must turn the OIC: Enable Incremental Calculation profile option to Y for every transaction event to be put into the Notify Log so that it is included in the next calculation phase. Note: After you change the setting of a profile option, you must bounce the server to reset it. For more information see Using Incremental Calculation.
See the list of All Trigger Events following.
Navigation
Compensation Manager > Calculate Compensation > View Notification Log
Notes
Click Search to use the NotifyLogDefault parameters or any searches you have already saved.
To create a custom search, click Personalize (see Customizing the Notify Log Search below).
Click any of the table headers that are links to sort the log on that particular column.
Use Previous and Next to move from the displayed rows to the ones before or after them.
Because the Notify Log Summary page may contain hundreds of entries, it helps to be able to narrow down the search parameters. You can use the Search page to create a view that preserves a customized search.
Navigation
Calculation Requests > Notification Log > Save Search
Notes
Enter search parameters into any of the six fields in the Notify Log area that help you to narrow the range of displayed information.
In the Attribute Properties area, you can click a selection once in the Available Columns and then click the right arrow button in the center area to move the selection to the Displayed Columns list. You can also click an item in the Displayed Columns area and then click the left arrow to move it back to the Available Columns list. The double arrow buttons move the entire contents to the other side.
Ascending is the default setting for sort parameters.
Use the Number of Rows to select the number of rows to be displayed at a time.
If you are creating a new saved search, be sure to give a new name to your custom search. Don't change this field if you are making changes to an existing search. Check the Default box only if you want the new search to be the default that displays when you open the Notify Log page.
There are many triggering events that are displayed in the Notification log. Some triggering events correspond to changes that are made in Resource Manager, such as a change of resource's group or promotion from salesperson to manager. Most of the triggering events correspond to changes in Oracle Incentive Compensation, such as a revision to the product hierarchy or a revised date range in a compensation plan. Below is a table of all of the triggering events that cause a resource to be listed in the Notification Log for recalculation.
| Event Code | Meaning/Description |
|---|---|
| CHANGE_SYS_PARA_RC | Change revenue class hierarchy used |
| CHANGE_SYS_PARA_SRP | Change revenue class hierarchy and roll up flag |
| CHANGE_CLS_RULES_DATE | change classification ruleset date range |
| CHANGE_CLS_RULES | Change classification rules |
| CHANGE_RC_HIER | Change revenue class hierarchy |
| CHANGE_RC_HIER_DATE | Change product hierarchy date range |
| CHANGE_RC_HIER_DELETE | Delete revenue class hierarchy effective interval |
| CHANGE_CLS_HIER | Change a hierarchy used in classification |
| CHANGE_CLS_HIER_DATE | Change a hierarchy date range used in classification |
| CHANGE_CLS_HIER_DELETE | Delete a hierarchy effective interval used in classification |
| CHANGE_CP_HIER_ADD | Add an edge to compensation group hierarchy |
| CHANGE_CP_HIER_DELETE | Delete an edge from compensation group hierarchy |
| CHANGE_CP_HIER_DATE | Change date range of a compensation group hierarchy edge |
| CHANGE_CP_ADD_SRP | Add a salesperson to a compensation group |
| CHANGE_CP_ADD_MGR | Add a manager to a compensation group |
| CHANGE_CP_DELETE_SRP | Delete a salesperson from a compensation group |
| CHANGE_CP_DELETE_MGR | Delete a manager from a compensation group |
| CHANGE_CP_SRP_DATE | Change date range of a salesperson |
| CHANGE_CP_MGR_DATE | Change date range of a manager |
| CHANGE_FORMULA | Change a formula |
| CHANGE_RT_TIERS | Change rate table tiers |
| CHANGE_RT_INS_DEL | Insert or delete rate tiers |
| CHANGE_QUOTA_DATE | Change plan element date range |
| CHANGE_QUOTA_POP | Change plan element revenue class factors |
| CHANGE_QUOTA_UPLIFT_DATE | Change plan element uplift factors date range |
| CHANGE_QUOTA_CALC | Change plan element |
| CHANGE_QUOTA_ROLL | Change plan element revenue class |
| CHANGE_COMP_PLAN | Change compensation plan |
| CHANGE_COMP_PLAN_OVER_LAP_FLAG | Change compensation plan overlap flag |
| CHANGE_SRP_ROLE_PLAN | Change role/plan or role/salesperson assignment |
| CHANGE_SRP_ROLE_PLAN_DATE | Change date range role/plan/salesperson assignment |
| CHANGE_SRP_QUOTA_PAYEE_DATE | Change date range of payee assignment |
| CHANGE_SRP_QUOTA_POP | Change salesperson's uplift factors or payee assignment |
| CHANGE_SRP_QUOTA_CALC | Change salesperson's plan element |
| CHANGE_PERIOD_INTERVAL_NUMBER | Change a period's interval number |
| CHANGE_INSERT_TRX | Insert new transaction -- need recalculation |
| CHANGE_SRP_PAY_GROUP | Change pay group/salesperson assignment |
| CHANGE_SRP_PAY_GROUP_DATE | Change date range of pay group/salesperson assignment |
| CHANGE_TEAM_ADD_REP | Add a salesperson to a team |
| CHANGE_TEAM_DEL_REP | Delete a salesperson from a team |