When similar transactions are grouped together for a specified time for processing it is called Group Processing?

You can group transactions into physical batches to improve performance.

Use any of these methods for grouping transactions:

Tell the application to determine the most efficient way to process batches according to the number of credits to be processed.
Import batch information from the source application.
Set the Number of Batches parameters.
Specify the batch number by participant.

The application can intelligently determine the calculation batches based on the number of credits to be processed. It determines the optimal number of batches and batch sizes (number of participants) to be included in each calculation batch, based on the volume of credits to be processed and the number of included participants. Here's how to enable this method:

In the Setup and Maintenance work area, use the following:
- Offering: Sales
- Functional Area: Incentives
- Task: Manage Parameters
In the Manage Parameters page, select Use number of batches and batch size determined by application for the Calculation Batch Processing parameter.
Save your changes.

In the Manage Parameters UI, the Batch Processing Parameters region, select the Use batch information provided at the transaction level option for Classification and Crediting Batch Processing and for Rollup and Calculation Batch Processing. The application preserves the batch number as it moves each transaction from one entity to another, for example, from transaction to credit or credit to earning.

Note: Ensure that transactions belonging to the same participant all have the same batch number.

Use the Manage Parameters task in the Setup and Maintenance work area to set the Number of Batches parameters. Select the Use batch size determined by the application option for these parameters:

Classification and Crediting Batch Processing
Rollup and Calculation Batch Processing

To balance the processing of workloads, administrators can configure classification, crediting, rollup, and calculation processes to group participants by transaction volume into specific numbered batches. This feature maximizes processing performance even with skewed transaction data or large volumes of data. For example, you can put participants who receive hundreds of thousands of credit transactions every week into separate batches, one for each participant, for processing. You can then put other participants who receive fewer transactions together into another batch.

If you provide a batch number for a participant, then the application uses that batch number to group participants. All participants that have the same batch number are grouped together for processing. If you don't provide a batch number for all of the participants, then the application divides the transactions for the remaining unnumbered participants equally into different batches. The Number of Batches value determines the number of those batches.

Here's now to provide a batch number for a participant:

In the Setup and Maintenance work area, select the Manage Parameters task.
Select the option Use batch information provided for participant from the list for either or both of these parameters:
- Classification and Crediting Batch Processing
- Rollup and Calculation Batch Processing
Save your changes.
Navigate to Participant Assignments, Manage Participant Batch Groups.
You can use the search to find participants to be assigned to a batch.
For each participant, you can enter a batch number for any or all of the applicable processes:
- Calculation
- Classification
- Rollup
- Crediting
You can use any number for your batch number, as long as it's a positive integer.

Page 2

The application populates the Changed Events Log with all plan and plan assignment changes. Logging these change events lets you run the calculation process for only the participants that require it.

You can check the log to see the list of events and all participants affected by change events to get an idea of how long a calculation will take. This table shows the four levels the application can track changed events for with descriptions of each.

Level	Description
1. Participant	If an event causes recalculation for multiple periods, then the event creates an entry for the participant with a null period and specifies the date range.
2. Participant, Period	A participant usually has one entry per period with a status of Incomplete in the log. If the event causes a change to all participants, then the application adds a single, global entry that tracks all participants for a period.
3. Participant, Period, Start Date	If an event causes the change at a specific date within a period, then the log can track at that date range level. The application can then recalculate transactions falling within the specified date range, instead of calculating for the entire period.
4. Participant, Period, Start Date, Plan Component	This level is the most granular level that the application tracks and records, and it makes incremental calculation the most efficient. For the events that cause the REVERT_TO_STATE to skip to the Calculation phase, the calculation process has to run only the Calculation phase again. This makes sense if, for example, calculation is reprocessing the transaction only because of a change in the commission rate of a single plan component.

In the log table, the REVERT_TO_STATE column tells the calculation process what state it must revert transactions to.

For full calculations, the process completely deletes the earnings transactions and returns the classified credit transactions to the unprocessed state.
For incremental calculations, which are determined implicitly, the process can selectively skip various phases for individual transactions.

Page 3

When you create a calculation request, you specify process parameters including for which participant to calculate earnings. Make your request at a time when others aren't making changes to compensation plans to be calculated.

Use the Manage Calculation Processes task in the Credits and Earnings work area to create calculation requests. When you submit calculation, it implicitly decides whether to run calculation in incremental or full mode for a specific participant.

If you select calculation for all participants or for participants in a plan, then the calculation not only reverts and re-runs for the participants in the Change Events Log, but it also updates the earnings for the rest of the participants. This ensures that earnings are updated, even for participants who have changes affecting their earnings that aren't recorded in the change log. These two options are recommended as best practice selections. If you select calculation for all participants in notify log, then the calculation only runs for the participants in the Change Events Log.

Use the Calculate For parameter to specify the participants to include.

Selected Participants

Description

All participants

This default selection for full calculations is the best practice selection.

Include all of the defined participants for calculation.

Participants in notify log

Calculation processing automatically handles all dependencies among participants. It processes these participants:

Participants in the notify log.
Participants with new credits.
Participants with credits that have resulted in an error in a previous CALC run
Participants with a per interval plan component, where the CALC run period matches with the last period of the interval of the plan component

Specific participants

Select the participants using one of these methods.

Specific participants: Directly select and enter resources.
Participants in compensation plan: Select one or more plans to include all of the associated participants in the calculation. The dates for the selected plans must be equal to, or earlier and later than the specified calculation to and from dates, respectively.

The request includes only those plans that are valid for calculation.
Participants in pay group: Select one or more pay groups to include all of the associated participants in the calculation. The dates for the selected pay groups must be equal to, or earlier and later than the specified calculation to and from dates, respectively.

If you specify participants who are assigned to compensation plans or pay groups, then the calculation request includes only those participants who are active for the specified request date range.

This participant inclusion is a one-time filter. Changing the date range or plan and pay group assignments doesn't refresh the initial request participants for subsequent submissions of the request.

For any participant specified for calculation, you can select Include Reporting Participants. For participants with this option selected, the calculation request also includes all of the participants in the participant hierarchy that report up to the specified participant.

Page 4

Incremental calculation uses all of the change events for the Compensation Plans and Participant Assignments work areas logged in the CN_TP_NOTIFY_LOGS_ALL table.

This table lists the logged change events for the Compensation Plans work area, including the involved attributes, operation, and the revert status of the log entry.

Entity Name	Attributes Involved	Operation	Revert State
Compensation Plan	Allow Credit Category Overlap	UPDATE	Rollup
Compensation Plan	Target Incentive	UPDATE	Calculation
Compensation Plan and Plan Component Association	Start and end dates of the association	UPDATE	Rollup
Compensation Plan and Plan Component Association	Target Incentive	UPDATE	Calculation
Compensation Plan and Plan Component Association	Not applicable	ADD and DELETE	Rollup
Plan Component	Indirect Credit and Active End Date	UPDATE	Rollup
Plan Component	Calculation Phase	UPDATE	Rollup
Plan Component	Payment Made Through Third Party	UPDATE	Rollup
Performance Measure and Incentive Formula	Running Total, Split, True Up, Output Expression, Use external formula, and Formula Name	UPDATE	ELIGIBLE
Plan Component and Performance Measure Association	Measure Weight	UPDATE	Eligible
Plan Component and Performance Measure Association	Calculation Sequence	UPDATE	Eligible
Plan Component and Performance Measure Association	Not applicable	ADD and DELETE	Eligible
Performance Measure and Performance Category Association	Not applicable	ADD and DELETE	Rollup
Performance Category, Uplift Factors	Credit Factor, Earning Factor, Start Date, and End Date	UPDATE	Eligible
Performance Category, Uplift Factors	Not applicable	ADD and DELETE	Eligible
Performance Category, Transaction Factor (Event Factor)	Transaction Factor	UPDATE	Eligible
Performance Category, Transaction Factor (Event Factor)	Not applicable	ADD and DELETE	Eligible
Goal, Distribute By	Target columns	UPDATE	Calculation
Incentive formula and rate table association Measure formula and rate table association	Start Date and End Date	UPDATE	Calculation
Incentive formula and rate table association Measure formula and rate table association	Not applicable	ADD and DELETE	Calculation
Incentive formula and expression association Measure formula and expression association	Expression, Accumulate, and Split	UPDATE	Eligible

This table lists the logged change events for the Participant Assignments work area, including the involved attributes, operation, and the revert status of the log entry.

Entity Name	Attributes Involved	Operation	Revert State
Participant Plan	Not applicable	INSERT and DELETE	Rollup
Participant Plan	Start Date and End Date	UPDATE	Rollup
Participant Plan	Target Incentive	UPDATE	Calculation
Participant Plan, Plan Component	Target Incentive Weight	UPDATE	Calculation
Participant Plan, Performance Category, Uplift Factors	Credit Factor and Earning Factor	UPDATE	Eligible
Participant Plan, Goal	Target	UPDATE	Calculation
Participant Plan, Alternate Payee	Start Date and End Date	INSERT, UPDATE, and DELETE	Eligible
Participant Plan, Alternate Payee	Not applicable	INSERT and DELETE	Eligible

Page 5

The calculation process uses classified credit transactions and valid incentive compensation plans and plan components to calculate participant earnings transactions.

Compensation plan configurations, such as whether to true up earnings and to calculate incentives for each event or per interval, affect calculation processing. Configure compensation plans, including plan components and performance measures, in the Compensation Plans work area. Parameters that you set when creating the calculation request in the Credits and Earnings work area and transaction status constrain the classified credit transactions used during processing.

The calculation process consists of two phases, Eligibility and Calculation. Before beginning the Eligibility phase, the calculation process updates each entry in the Changed Events Log with these values:

A status of Incomplete
The scheduled process ID

The process only runs for the incomplete log records with the corresponding scheduled process ID, ensuring that it doesn't include any changes made during the current run.

The Eligibility phase performs these actions:

Identifies all of the credit transactions that meet the specified date range and have a credit receiver that's one of the selected participants
Populates the plan, plan component, and performance measure for each transaction based on the transaction credit categories

Eligibility uses the classification rule hierarchy to find any indirect matches. If a measure has a parent-level credit category, then that measure qualifies for the transaction.
References the Include Indirect Credit attribute to identify the eligible plan components
Sets the transaction status to one of these values:
- Eligible if it populated the transaction
- Not eligible if it fails to populate the transaction

The Eligibility phase doesn't identify the plan component and measure for any transactions where you elected to skip the Eligibility phase. The process assumes that you provide the plan component name.

The Calculation phase computes the measure attainments and plan component earnings for all eligible transactions. It stores the intermediary and final calculation results, such as formula output, attainment or earning, input achieved, rates and rate tiers, for each earnings transaction. This information is essential for transaction-to-payment audits and reporting purposes.

The Calculation phase does these actions:

Ignores any transaction with a status of Skip calculation, assuming that you already populated the commission attribute
Assumes that the transaction factor is 100 percent if the expression uses transaction factor and the factor for the transaction type isn't available for the credit category
Gets the credit and earning factor, if the expression uses them, from the specified date range

If the values aren't available for the date range, then the calculation assumes that they are 100 percent.
Uses the individualized values for a participant if the expression uses any goal target values, rate table rates, earning and credit factors, and target incentives

If they aren't available, then the calculation uses the default values of the relevant plan object.
Evaluates the plan component True Up check box

If selected, the process automatically subtracts previous earnings, which it included in the earnings calculated for the current transaction.
Uses the plan component sequence to calculate the interdependent plan components correctly
Sets the transaction status to Failed calculation for transactions that failed

This table lists the actions that the Calculation phase performs for plan components based on the Calculate Incentive selection.

Calculate Incentive Selection

Calculation Phase Actions

Per event

Sets the same credit category for the incentive formula as for measures of the type Individual

All of the plan component measures that evaluate transactions individually associated with a plan component must have the same credit category. Plan component measures that evaluate grouped transactions can have different credit categories.
Creates earning transactions for the credit transactions with the same credit category as any of the individual measures of the plan component

Per interval

Creates a summary record measures that evaluate grouped transactions with input and output values for the interval
Creates a record in the earnings table, at the end of the payout frequency (earning interval) with the interval amount

The payment module uses this record for payment processing.

Calculation doesn't maintain any direct link between earnings and credit transactions. Instead, you use the Earning Basis selections to edit the measures while associating them with the plan component.

The application links the earning and credit records using this logic:

Get the plan component from the earning record.
Get all plan component measures with Earning Basis set to Yes.
List all of the credit transactions associated with those measures.
Calculate the per interval plan components.

Even if the formula interval is Quarter, for example, the process calculates attainment for each period. It calculates interval earnings at the end of the last period.

When calculation processing completes, the process updates all of the log records with the corresponding concurrent request ID and the status to Complete.

Page 6

Alex Anders

25,000

Western Audio

1.00

250

Haley King

25,000

Western Audio

1.00

250

Robert Rivera

50,000

100

Western Audio

.25

1.25

Andrew Brown

25,000

100

Western Audio Video

Not applicable

Andrew Brown

25,000

100

Western Audio Video

Not applicable

Lily Cox

25,000

100

NA Audio Video

Not applicable

Lily Cox

25,000

100

NA Audio Video

Not applicable

Richard Barta

25,000

100

NA Audio Video

Not applicable

Richard Barta

25,000

100

NA Audio Video

Not applicable

Page 7

When you investigate a dispute, review earnings, or get questions about a credit, you require details.

You may have questions about an earning amount. How did it come about? Who was credited? Is the earning from a single transaction or a group of transactions? You can analyze each step of the calculation for an earning in the Calculation Detail UI, available from the Manage Earnings UI.

Here are some questions and where you can find answers.

Question	Calculation Detail Tab
Was the credit split with someone else?	Credits, and in the UI header
What input expression was used for the rate table?	Rate Inputs
Was the transaction changed?	History
Was the correct measure used for the time period?	Measure Details
How was this earning calculated?	Formula and Measure Results
What plan component is the earning from?	UI header
Is there an error in the expressions?	Formula and Measure Results
Did factors play a part in the calculation?	Measure Details
When was it credited and what was the currency conversion rate?	Credits

Calculation Detail shows the most recent calculation, not necessarily the calculation when it was paid.

Page 8

Here are examples of what you can look for if your calculation process runs too long.

You aren't calculating incrementally.
Other Calculation processes are running and blocking this process.
Your data volume increased.
You are processing a longer date range.
Your calculation system parameters settings aren't optimum.
You have expressions that include user-defined queries.
You have unnecessary credit categories assigned to measures which don't refer to transaction attributes in the formula.
You have too many performance measures to calculate per event.

Page 9

Ensure that you have at least three times the number of batches as workers (or processing threads) to keep all workers busy simultaneously, most of the time.

For Classification and Crediting Batch Processing, for Number of Batches, enter the results for this expression: 3 x Number of Workers. For Rollup and Calculation Batch Processing, the number of batches and batch size are determined by the application for optimum batching.
For Participant Batch Size for Payment, for Participant Batch Size, enter the result of this expression: (Number of Participants / (3 x Number of Workers))

Start with the recommended configuration and refine the parameters based on your testing results.

Page 10

You can add only valid plans when creating a calculation request. If a plan later becomes invalid due to changes, then when you submit the calculation request, the request status changes to Failed during validation.

The calculation request process log contains a list of the plans that failed validation, so that you can correct the issues and submit the request again.

Page 11

If the participant isn't the direct participant for a transaction, then the transaction isn't in the list in Manage Transactions.

For example, you see a transaction when viewing a participant in Snapshot, but that transaction is gone in Manage Transactions because it's filtered on the direct participant. A direct participant is listed directly on the transaction. Rules use other information on a transaction to credit a participant. That participant isn't a direct participant. Search for the participant under Manage Credits or Manage Earnings to see details on the base transactions where the credited participant isn't the direct participant.

Page 12

Calculation was run but the earnings you expect to see are missing.

In this scenario, the credits associated to the transaction were calculated. Then either a change was made to the same transaction or to its associated credits. If the Revert Transactions process is run, it either deletes the earning records if not paid, or moves the earnings to history if paid. Either way, the Revert Transactions process clears the earnings. The earnings are only recreated if Calculation is run again after the transaction is changed. If Calculation isn't run, the earnings remain missing for that transaction.

Page 13

The calculation process can fail for a variety of reasons during either the Eligibility or Calculation phase. The calculation process updates the transaction status based on the reason for the failure.

Before you submit a calculation request, ensure the following:

Participants are associated with valid compensation plans.
The calculation compensation period has a period status of Open.
The credit category, or any of its parent classification rules, is associated with a valid measure for that period.

Eligibility processing links classified credit transactions to the compensation plan components and performance measures assigned to the specified participants. The process tries to validate invalid plans. If it can't do this, then it does the following:

Sets the transaction status to Failed plan validation
Lists the invalid plans in the calculation request process log for you to review and correct

Here are some typical reasons for an Eligibility phase error:

The processed date of the transaction isn't within the range of the plan assignment date for the plan component.
The participant's plan component or performance measure doesn't include the credit category that's on the transaction.

If the Calculation process fails, then it changes the transaction status to Failed calculation. Check for any recent changes to the plan components or performance measures of the plan being calculated. Are the plan components and performance measures all valid? Fix what you find and then recalculate. Here are some reasons for a failed calculation:

An expression uses the wrong field or table.
A plan component references the result of another plan component, and the base component isn't valid for the entire range of the dependent plan component.
The rate table doesn't include the value passed to it from the input expression.

Tip: To prevent this problem, always ensure that the input to the rate dimension is compatible with the corresponding rate dimension type. For example, you can't pass a string value to the rate dimension of the type percent or number. Also, ensure that the rate dimension tiers cover all of the possible values.
A value in the formula (input or output expression of the measure formula or plan component incentive formula) is divided by zero.
All columns used in the formula for calculation aren't populated for the transaction. For example, the input expression uses quantity and the quantity field is empty.
Someone changed a plan component while calculation was running and happened to be processing that plan. There's nothing to fix. Rerun the calculation.

Page 14

Credit transactions can fail eligibility validation during processing. The research assistant provides an analysis of eligibility errors and the means to correct errors in the same UI. The Analyze icon in the search results table of the Manage Credits page opens the research assistant.

The transaction credit category doesn't match a performance measure for the transaction date
The transaction date doesn't fall within plan component effective dates
The credit receiver has no compensation plan for the transaction date
The transaction doesn't match the Include Indirect Credits attribute for the plan component

For example, you can change dates in the Compensation Plan and Plan Components tabs. Use the Performance Measures tab to identify the performance measure that matches the transaction credit category.

Page 15

The Calculate Incentive Earnings process creates measure attainment records and earnings records for participants. If the process ends with errors or incorrect data, you can follow these solutions to fix it.

Verify that you have these prerequisites to running Calculate Incentive Earnings:

The participant is assigned to a valid compensation plan
The credit category or its ancestor (any credit categories associated to parent classification rules) of the transaction is associated with the measure
You classified the credits by either running Classify Credits or by manually specifying the credit category of the credit
You ran Deploy Compensation Plans to denormalize the compensation plan data

Take these steps to resolve the error.

In the Manage Scheduled Processes page, check the log file and correct any listed errors.
Validate the parameters used to submit the process.
- The process name is unique in a particular business unit.
- You must have a from date and to date, and the from date must be earlier or equal to the to date.
- The from date and to date must be in open periods. If a period isn't open, you can open it in Manage Periods.
- If it's not an incremental calculation, then the valid values for the parameter Calculate For are All Participants and Specific Participants. For Specific Participants, the valid values for the parameter Select Participants By are Specific Participants, Participants in compensation plan, and Participants in pay group.
- If it's Incremental Calculation, then the valid values for the parameter Calculate For are Participants in Notify Log and Specific Participants. For Specific Participants, the valid values for the parameter Select Participants By are Specific Participants, Participants in compensation plan, and Participants in pay group.
- If you specify a value for the parameter Select Participants By, then make sure that at least one participant is selected. This can be verified in the Edit Calculation Process page.
Make sure that all of the compensation plans associated to the participants are valid. Check the status of compensation plans in the Manage Compensation Plans page.
In the Manage Scheduled Processes page, verify that the child workers Eligibility and Calculate are forked. If you can't see these workers, go to the Weblogic Server Administrator console and verify that ESS applications are up and running.
Run the Calculate Incentive Earnings process again with valid parameters. Check earnings records in the Manage Earnings page.

The process succeeded, but the credits are in a state other than Eligible.

Check the selections in the Manage Parameters page.
- If the value of the parameter Classify Transactions is After crediting and rollup and before calculation, then the process status of the credits should be either Classified or Eligibility Error. Check the process status of the credits in the Manage Credits page and if the status isn't Classified or Eligibility Error, then run the Classify Credits process first to classify the credits.
- If the value of the parameter Classify Transactions is After collection and before crediting and Enable Rollup Crediting is No, then the process status of the credits should be either Credited or Eligibility Error. Check the process status of the credits in the Manage Credits page and if the status isn't Credited or Eligibility Error, then run the Run Crediting process first to generate the credits.
- If the value of the parameter Classify Transactions is After collection and before crediting, Enable Rollup Crediting is Yes, and Rollup Using is Credit Hierarchy, then the process status of the credits should be either Rollup during Crediting or Roll up or Eligibility Error. Check the process status of the credits in the Manage Credits page and if the status isn't Rollup during Crediting or Roll up or Eligibility Error, then run the Run Crediting and Rollup process first to generate the indirect credits.
- If the value of the parameter Classify Transactions is After collection and before crediting, Enable Rollup Crediting is Yes, and Rollup Using is Rollup Hierarchy or Both, then the process status of the credits should be either Roll up or Eligibility Error. Check the process status of the credits in the Manage Credits page and if the status isn't Roll up or Eligibility Error, then run the Run Rollup process first to generate the indirect credits.
Check the parameters of the Calculate Incentive Earnings process.
- The source event date of the credit must fall between the From Date and To Date parameters of the process. If it isn't, then submit a new calculation process with the correct date range.
- The participants of the calculation job must include the credited participant of the credit. If it's not, then resubmit a new calculation process after including the correct participant.
In the Participant Snapshot work area, make sure that the participant is assigned to a compensation plan for the source event date of the credit. If not, then assign a compensation plan to the participant for the correct date range, run Deploy Compensation Plans and then run Calculate Incentive Earnings.
The status of all the compensation plans associated to the participant must be Complete. If not, then take the necessary action to make it complete in the Compensation Plans work area.
The credit category of the compensation plans must match one of these credit categories:
- The credit category on the credit
- A credit category that's a parent of the credit category on the credit
If it's not, then either change the credit category of the compensation plan or change the classification rules and reclassify the credits. You maintain the hierarchy of credit categories in Classification Rules.
In the Participant Snapshot work area, check the details of the compensation plans associated to the participant. If you observe any issue, then associate the compensation plan to the participant again after removing the association. Run Deploy Compensation Plans and then rerun the calculation process.
Run the Calculate Incentive Earnings process again with valid parameters. Check earnings records in the Manage Earnings page.

The status of the process request is Succeeded, but the earnings in the Manage Earnings page have the status Calculation Error.

In the Participant Snapshot work area, check the tiers of the rate table used in the compensation plan. Then make sure that the input achieved of the measure or the earning falls in one of those tiers. If not, then change the rate tiers so that a rate table rate can be applied to the credit.
In the Participant Snapshot work area, determine all the attributes of the transaction used in the expressions of the measure and plan component. Then go to the Manage Transactions page and make sure that these attributes of the transaction are populated correctly. If not, then update the transaction and then run the processes.
In the Participant Snapshot work area, check the expressions used in the measure and plan component and make sure that they're correct. If not, then define a new correct expression and replace the old expression with the new one.
In the Manage Earning page, query the earning record and check the data in the Measure tab. Verify that the column Output Achieved is what's expected and also the value of the column Process Status is Calculated. If not, then check the measure definition and take the necessary corrective steps.
In the Calculation Detail page, check the data in the tab Formula and Measure Results. If the data isn't correct, then check the measure and plan component definition.
In the Participant Snapshot work area, check the details of the compensation plans associated to the participant. If you observe any issue, then associate the compensation plan to the participant again after removing the association. Run Deploy Compensation Plans and then run the calculation process.
In the Compensation Plans work area, make sure that the plan component is associated to an earning type. If not, then update the plan component with a valid earning type and run calculation.
In the Participant Snapshot work area, make sure that the participant is assigned to a compensation plan for the source event date of the credit. If not, then assign a compensation plan to the participant for the correct date range, run Deploy Compensation Plans and then rerun Calculate Incentive Earnings.
Run the Calculate Incentive Earnings process again with valid parameters. Check earnings records in the Manage Earnings page.

The process succeeded and the earnings in the Manage Earnings page have the status Calculated. But your earnings amounts are incorrect.

In the Participant Snapshot work area, check the tiers of the rate table used in the compensation plan. Then make sure that the input achieved of the measure or the earning falls in the correct tier. If not, then change the rate tiers so that the correct rate table rate can be applied to the credit.
In the Participant Snapshot work area, determine all the attributes of the transaction used in the expressions of the measure and plan component. Then go to the Manage Transactions page and make sure that these attributes of the transaction are populated correctly. If not, then update the transaction and run the processes.
In the Participant Snapshot work area, check the expressions used in the measure and plan component and make sure that they're correct. If not, then define a new correct expression and replace the old expression with the new one.
In the Manage Earning page, query the earning record and check the data in the Measure tab. Verify that the columns Input Achieved and Output Achieved are what's expected. If not, then check the measure definition and take the necessary corrective steps.
In the Calculation Detail page, check the data in the tab Formula and Measure Results. If the data isn't correct, then check the measure and plan component definition.
In the Participant Snapshot work area, check the details of the compensation plans associated to the participant. If you observe any issue, then associate the compensation plan to the participant again after removing the association. Run Deploy Compensation Plans and then rerun calculation.
Run the Calculate Incentive Earnings process again with valid parameters. Check earnings records in the Manage Earnings page.

The process succeeded, but the earnings aren't calculated for a particular plan component.

The credit category of the compensation plans must match one of these credit categories:
- The credit category on the credit
- A credit category that's a parent of the credit category on the credit
If it's not, then either change the credit category of the compensation plan or change the classification rules and reclassify the credits. You maintain the hierarchy of credit categories in Classification Rules.
In the Participant Snapshot work area, make sure that the source event date of the credit falls within the date range of the plan component. If not, then change the date range of the plan component, run Deploy Compensation Plans, and then run calculation.
In the Participant Snapshot work area, make sure that the participant is assigned to a compensation plan for the source event date of the credit. If not, then assign a compensation plan to the participant for the correct date range, run Deploy Compensation Plans, and then run calculation.
The status of the compensation plan associated to the participant must be Complete. If not, then take the necessary action to make it complete in the Compensation Plans work area.
In the Participant Snapshot work area, check the details of the compensation plans associated to the participant. If you observe any issue, then associate the compensation plan to the participant again after removing the association. Run Deploy Compensation Plans and then rerun calculation.
Run the Calculate Incentive Earnings process again with valid parameters. Check earnings records in the Manage Earnings page.

Page 16

The Assign Incentive and Draw Plans task includes activities to create and manage pay groups and payment plans.

Compensation managers use the Participant Assignments work area to create and manage pay groups as well as define and assign rule-based incentive payment draw and recovery plans.
Compensation analysts are responsible for participant-specific plan configuration and processes and use the Participant Snapshot work area to individualize plans. Analysts also define other participant-specific attributes, including the participant's home currency, to support participant-specific incentive agreements.

This diagram shows that the Assign Draws and Incentives task comes after Model and Configure Incentive Plans and before transaction processing within the Manage Incentive Compensation business process flow.

Page 17

The payment business process controls how you pay salespeople, including these aspects.

Who is paid
When payment occurs
Which transactions and adjustments to pay
Approval and payment processing (if you use approvals)

This chart shows the Determine Incentive Payment business process entities and the relationships between them, whether one-to-many, many-to-one, or many-to-many.

Use pay groups to define the frequency of payments and gather participants who are on the same payment cycle and sent to the same application. For example, group monthly participant payments as Pay Group A for your payables application and Pay Group B for your payroll application.

You must assign participants to a pay group to include them in a payment batch when you run the payment process. You can assign multiple pay groups to a participant, but only one pay group assignment can be active at a time. You create and manage pay groups in the Participant Assignment work area.

You can assign a pay group to one or more payment batches, but a payment batch can have only one pay group assigned.

Payment batches define the compensation period for which the payment is valid.
Payment batches determine payment amounts for each eligible participant.

Paysheets are worksheets generated when you create a payment batch. A payment batch contains multiple paysheets, and each paysheet contains this information:

Multiple payable commissions or payment transactions
Draw and recovery adjustments
Payment adjustments for the paysheet participant

Payment plans contain rules regarding payment draw, draw recovery, and cap amounts to pay to assigned participants. The payment process uses these rules to populate participant paysheets with computed participant payment adjustment amounts against earnings for the period.

You can assign multiple participants with a payment plan. You can also assign multiple payment plans to a participant, but only one plan assignment can be active at a time.

Page 18

Incentive compensation managers and analysts create payment plans in the Participant Assignments work area to provide and recover participant draw payments against actual earnings.

Use payment plans to specify when and how much to pay and at what frequency. Prevent negative payments by using a zero minimum amount.

On the Create Payment Plan page, select the payment plan category.

The Payment Information page or tab for plan components has the same field. Payment processing applies the draw and cap configured in the payment plan to those plan components with the same category selected. Create and edit plan components in the Compensation Plans work area.

Set up multiple payment plans for a participant during a specific time period, as long as the payment plans have different categories.
Enter the flat minimum amount to pay the participant.

Payment processing calculates the difference between the draw and the actual earnings amount and automatically creates a payment adjustment, recoverable or nonrecoverable, as required.
Optionally, select when to end the draw, such as after 3, 6, 9, or 12 months.
Optionally, enter a maximum payment, or cap.
Specify whether to carry forward the maximum.

If you select Yes, then the payment processing issues a negative adjustment to level the final payment to the maximum amount. It also applies the adjustment to future earnings if the participant earns less than the maximum set on the payment plan.
Specify whether to recover the minimum, or draw, payment.

If you select Yes, then the payment processing recovers the minimum against all earnings over the minimum amount. Also, specify whether to start recovery immediately or delay it. If you delay recovery, then you can specify whether to start and end recovery after 3, 6, 9, or 12 months.
Assign participants using roles and direct assignment.

Tip: Individualize draw amount, recovery amount, cap amount, and assignment start or end dates for participants in the Participant Snapshot work area.